The layout for this article will be quite straightforward. I will create a table for each setting-menu and list the settings I would change. I will also provide a short explanation for why I would change the setting, as well as what the setting is by default.

Table of Contents

• User settings
  • Default user role permissions
  • Guest user access
  • Administration center
  • LinkedIn account connections
  • Show keep user signed in
• External users
  • Guest invite settings
  • External user leave settings
  • Collaboration restrictions
  • User features
• External Identities - Cross-tenant access settings
• Enterprise applications
  • Consent and permissions - User consent settings
  • Admin consent requests
  • Consent and permissions - Permission classifications
• Protection - Identity Protection
  • Identity Protection - Conditional Access
  • Identity Protection - User risk policy
  • Identity Protection - Sign-in risk policy
  • Identity Protection - Multifactor authentication registration policy
  • Security - Named locations
  • Security - Authentication methods - Policies
  • Security - Authentication methods - Password protection
  • Security - Authentication methods - Registration campaign
  • Security - Authentication methods - Authentication strengths

Introduction

In this post you’ll find some guidance on settings in Entra ID or Azure that will enhance your security. There is an important note here, however:

Context is key.

What you are using your Azure tenant for will impact what level of security you go for. The settings I advocate are mainly for those who use their tenants to deliver either a managed service, or if they host a platform/service in Azure that customers access. That being said, I’ve also added some assumptions for some of the settings I’m recommending that gives a bit more context to why I’m recommending them.

User settings

You can find the user settings here and an overview over default user permissions on Microsoft Learn

Default user role permissions

I find these settings to be the most important to change in small companies. We want to restrict the ability to create applications, tenants and security groups to a select few people. This is to ensure that we have control over what is created in the tenant. For larger companies, I would add the ability to create security groups to more people, but would still do it on a need-to basis.

Guest user access

This setting is important to restrict what guest users can see in the tenant. For this setting, I think context is important:

• Allowing guest users in a tenant usually result in stale accounts
• When someone changes jobs, or teams, who is responsible for removing the guest user?

I prefer to use identity governance for this, and create access packages. With this you can scope the access to a certain level and limit the people who can apply for it only to a certain company (tenant). You can also configure the life cycle of the users here - so this saves you a lot of job in the long run, as it will handle removal of the guest users for you and also make sure that access is removed if it’s not needed anymore.

Administration center

This setting still only works for the user interface of the admin center, but it’s a good setting to have in place. It restricts access to the admin center to a select few people. Tools like AzureHound can still be used to gather information about the tenant.

From Microsoft Learn:

When should I not use this switch? Don’t use this switch as a security measure. Instead, create a Conditional Access policy that targets Windows Azure Service Management API that blocks nonadministrators access to Windows Azure Service Management API.

LinkedIn account connections

You can read more about data sharing with LinkedIn on Microsoft Learn. I think this setting depends on what you are using the tenant for. If it’s a company tenant for collaboration, leave this on. If it’s a management tenant for a managed services, turn it off.

Show keep user signed in

I would turn this off. If you want to read more about what the KMSI setting does you can read more on StackOverflow, but the general idea is that we want to remove the option to keep users signed in and have persistent sessions.

We can manage this with Conditional Access and other settings, but disabling this setting is also an idea. We also did some testing trying to capture tokens using Evilginx2, and we found that turning the KMSI setting on was the only way to actually capture tokens in our tenant. I didn’t to any actual testing to verify this, but since then I’ve just always turned it off. If someone has more information on this, please let me know.

External users

You can find the external collaboration settings here..

It’s start out with the same guest access setting we had in the user settings, then moves on to Guest invite settings.

Guest invite settings

Restricting who can invite guest users is important to prevent unauthorized access and persistent access to the tenant.

External user leave settings

I would not change any of these settings for security purposes, so this section is blank.

Collaboration restrictions

This setting is important to restrict who can be invited to the tenant. I would set this to the most restrictive setting, which is to only allow invitations to the specified domains. This is to ensure that we have control over who can be invited to the tenant. This goes no matter how small or big the tenant is in my eyes, this is a setting that should be changed and you should have control over.

User features

You can find the user features settings here..

I would not change any of these settings for security purposes, so this section is blank.

External Identities | Cross-tenant access settings

Moving on from external user settings, let’s take a look at the cross-tenant access settings. You can find the cross-tenant access settings here.

Default settings

I would not necesarilly change any of these default settings, but it’s important to know what they are. This section is blank. By default b2b collaboration is turned on and b2b direct access is blocked. Trust settings, which might be most important, are all turned off. These settings are as follows:

1. Trust multifactor authentication from other Entra ID tenants
2. Trust compliant devices
3. Trust Microsoft Entra hybrid joined devices

I would not change these default settings, but 1. and 2. might be changed for security purposes when working with partners. The reason for this is, for example if you’re using a service provider for something in Azure. The default flow for the service provider will look something like this by default:

graph TD
User --- Device
User --> A[Azure Portal]
A --- CA[Conditional Access]
CA -.-> |Prompt for MFA| User 
CA -.-> |Check for Device Compliance| User 
CA -..-> Device

Now, this is just for accessing resources in their own tenant, given the fact that they use conditional access (they should). If they try to change to the customers tenant, this flow will happen again:

graph TD
User --- Device
User --> A["Azure Portal (Customer Tenant)"]
A --- CA[Conditional Access]
CA -.-> |Prompt for MFA| User 
CA -.-> |Check for Device Compliance| User 
CA -..-> Device

Important to note; the device compliance check will fail. This is because the setting is to not trust compliant devices from other tenants. You have two options for this, either you add an exception to users from that service provider (tenant, domain) or you trust compliant devices from that tenant.

As for MFA, currently the service provider would have to prompt for MFA twice. Once for their own tenant, and once for the customer tenant. This quickly leads to MFA fatigue, and might be a reason to trust MFA from other tenants. If you have a conditional access policy in place that requires a certain level of MFA strength, that should still be respected as far as I can tell from reading Microsoft Learn - the only thing that changes is that you don’t have to prompt for MFA twice.

Important to also know that if you use granular delegated admin privileges (GDAP), this is like trusting MFA as well:

When an external user signs in using GDAP, MFA is always required in the user’s home tenant, and always trusted in the resource tenant

Enterprise applications

Consent and permissions | User consent settings

This setting is important to restrict what users can consent to. I would change this setting to require an administrator for all apps. This is to ensure that we have control over what is consented to in the tenant. Usually I have seen some malicious apps being consented to, and this is a good way to prevent that. What I have also seen, which prompts me to put do not allow consent, is legitimate apps that have been consented to by “users” that have been taken over, as a way to exfiltrate data. So this setting will stop that as well.

Admin consent requests

The rest of the settings in this section I would not change for security purposes, so this section is blank. Depending on the size of the company, a lot of configuration can be done here to spread the work of consent requests.

Consent and permissions | Permission classifications

Here we can add classifications to permissions. Please note that we can only do this for “… delegated permissions that don’t require admin consent are supported.” In our case, we set it up so we need admin consent for all apps, so this section is blank.

For larger companies I can see setting the user setting a bit more lenient, like allowing the user to consent to “apps from verified publishers, for selected permissions”, where those permissions are the one we classify here as “low impact”:

Protection - Identity Protection

You can get to the Identity Protection settings here.

Identity Protection | Conditional Access

Conditional access is huge, and I would much rather you go check out Daniel Chronlund and his work on this for a good baseline.

If all else fails, I’d recommend the following policies to be in place at least:

1. Require MFA for all users
   • Preferably phishing resistant MFA, but passwordless is also an option
2. Require phishing resistant MFA for all administrators
   • Target high privileged admin roles
3. Require compliant devices for all users
   • If all else fails, you can limit this to just administrators or admin portals, but all users is the best idea
4. Disable legacy authentication
5. Session controls for all users
   • Sign-in frequency to 7-9 hours
   • Persistent browser sessions off
   • Sign-in risk policy for high risk sign-ins or users in block

Context here; I assume that you are using Intune-managed compliant devices, in which case the total amount of prompts would be once per browser (if you assume that you’re using that browser to sign in to all services defined in tenant X). If you’re not using a machine devie with Windows Hello, I would recommend looking into the session policies and maybe exempting low privileged users from some of the session controls to ensure a smooth user experience and avoiding MFA fatigue.

Identity Protection | User risk policy

I’d set this to block for high (or medium), depending on company size. You can (and should) do this via conditional access, however.

Identity Protection | Sign-in risk policy

I’d set this to block for high (or medium), depending on company size. You can (and should) do this via conditional access, however.

Identity Protection | Multifactor authentication registration policy

Access the MFA registration setting here.

Only changes I’d make from the default here is to change the default targetting.

Default it targets all users with no exceptions, I’d change this to exclude any break the glass users you might have.

Security | Named locations

Named locations can be accessed here.

I would add at least two named locations here:

1. Office locations
2. Not allowed country list

This is to ensure that we have control over where users can sign in from. I would then create a conditional access policy for securing registration info limited to the office locations, and a policy for blocking sign-ins from the not allowed country list.

Security | Authentication methods | Policies

I would also remove any other authentication methods that are not needed, or that are not secure. In sum, I’d keep it at Passkey and Microsoft Authenticator only. For some scenarios you’d also need a Temporary Access Pass.

Security | Authentication methods | Password protection

I would also add custom banned passwords, and enable password protection on Windows Server Active Directory (this is on by default, just making sure). Usually there’s a good chance that you have some “standard” passwords like “Summer2023!” that you want to ban.

Security | Authentication methods | Registration campaign

I would enable the registration campaign, and limit the number of snoozes. I would also exclude break the glass users from the campaign.

Security | Authentication methods | Authentication strengths

I would not change anything here, unless you have certain requirements for authentication strengths in your company. In this case, create a custom strength and use that in your conditional access policies.

Summary

This is a list of settings I would change in any Entra ID-tenant I manage. I hope this list is helpful to you, and that you can use it as a baseline for your own hardening. If you have any questions, feel free to reach out.