Introduction

In the first post of the top things that you might not be doing (yet) in Entra Conditional Access, we focused on basic but essential security controls that I recommend you checking out if you do not have them implemented already. In this second part, we’ll go over more advanced security controls within Conditional Access that, in my experience, are frequently overlooked in environments during security assessments. However, they can help you better safeguarding your identities.

Similar to my previous blog post, the list of controls provided here is not exhaustive. The relevance of each control may vary depending on your specific environment. Moreover, you should not rely on those only, but instead investigate whether they would bring any value in your environment. I also encourage you to check out other Conditional Access controls available to make sure your identities are correctly protected.

This article focusses on features that are available in Entra ID Premium P1 and P2 licenses. Therefore, if none of those licenses are available, check my previous blog post on how to protect identities in Entra ID Free: https://blog.nviso.eu/2023/05/02/enforce-zero-trust-in-microsoft-365-part-1-setting-the-basics/. Note that other licenses could also be required depending on the control.

Additionally, should you need any introduction to what Entra Conditional Access is and which security controls are available, feel free to have a look at this post: https://blog.nviso.eu/2023/05/24/enforce-zero-trust-in-microsoft-365-part-3-introduction-to-conditional-access/.

Finally, if you have missed part 1, feel free to check it out: https://blog.nviso.eu/2024/02/27/top-things-that-you-might-not-be-doing-yet-in-entra-conditional-access/.

Entra Conditional Access security controls

Make sure all Operating Systems are covered in your current Conditional Access design

License requirement: Entra ID Premium P1

When performing Entra Conditional Access assessments, we usually see policies to enforce controls on Windows, and sometimes Android and iOS devices. However, other platforms such as MacOS, Windows Phone, and Linux are sometimes forgotten. This can represent a significant gap in your overall security defense as access from those platforms is not restricted by default. You could use all the Conditional Access policy features, but if you do not include them, all your effort will be in vain.

Indeed, it is well known from attackers that “nonstandard” platforms are sometimes forgotten in Conditional Access. By trying to access your environment using them, they might be able to simply bypass your Conditional Access (CA) policies. It is therefore necessary to make sure that your security controls are applied across all operating systems.

The next points will shed some light on controls that you can implement to support all platforms.

Don’t be afraid of blocking access, but only in a considered and reasonable way

License requirement: Entra ID Premium P1

Based on our numerous assessments over the years, we have observed that ‘Block’ policies are typically not implemented in Conditional Access. While those policies can definitely have an adverse impact on your organization and end users, specific actions, device platforms, or client applications (see part 1), should be blocked.

For example, if you do not support Linux in your environment, why not simply block it? Moreover, if Linux is only required for some users, Conditional Access allows you to be very granular by targeting users, devices, locations, etc. Therefore, platforms can be blocked for most use cases, and you can still allow specific flows based on your requirements. This principle can be extended to (guest) user access to applications. Should guest users have access to all your applications? No? Then, block it. Such control effectively decreases the overall attack surface of your environment.

I highly recommend you giving a thought to ‘Block’ policies. Moreover, they could be extended to many other scenarios on top of the device platforms and (guest) user access to cloud apps.

Before moving on to the next point, I want to highlight that such policies can be very powerful. So powerful that they could lock you out of your own environment. To avoid that, please, always exclude emergency / break-the-glass accounts. In addition, never rollout Conditional Access policies in production before proper testing. The report-only policy mode can be of great help for that. Moreover, the What If tool is also a very good tool that you should be using to assess the correctness of your policies. Once the potential impact and the policy configuration have been carefully reviewed, gradually roll out policies by waves over a period of a few weeks with different pilot groups.

Use App Protection Policies to reduce the risk of mobile devices

License requirement: Entra ID Premium P1 and Microsoft Intune

If access from mobile devices, i.e., Android and iOS, is required for end user productivity for example, App Protection Policies (APPs) can help you preventing data loss on devices that you may not fully manage. Note that App Protection Policies are also now available for Windows devices but are still in preview at the time of writing (beginning of March 2024).

In short, App Protection Policies are a set of rules that ensures that data access through mobile apps is secure and managed appropriately, even on personal devices. APPs can enforce the use of Microsoft-managed applications, such as Microsoft apps, enforce data encryption, require authentication, restrict actions between managed and unmanaged applications, wipe the data from managed applications, etc.

For that purpose, the following Grant control can be configured:

Of course, to be effective, App Protection Policies should be created in Intune and assigned to users. Because of that, Microsoft Intune licenses are required for users in scope of that control.

Moreover, together with the Exchange Online and SharePoint Online app enforced restrictions capabilities, you can allow, restrict, or block access from third-party browsers on unmanaged devices.

Require Authentication Strengths instead of standard multi-factor authentication

License requirement: Entra ID Premium P1

Authentication Strength policies in Entra Identity Conditional Access enable administrators to mandate certain authentication methods, such as FIDO2 Security Keys, Windows Hello, Microsoft Authenticator, and passwordless authentication. Please note that the authentication methods available to users will be determined by either the new authentication method policies or the legacy MFA policy.

By configuring Authentication Strengths policies and integrating them in Conditional Access policies, you can further restrict (external) user access to sensitive applications or content in your organization. Built-in policies are also available by default:

One common use case for Authentication Strength policies is to ensure that user accounts with privileged access are protected by requiring phishing-resistant MFA authentication, thus restricting access to authorized users only. In Conditional Access, this goal can be achieved through multiple methods:

1. Secure Privileged Identity Management role activation with Conditional Access policies (see next point for more details);
2. Include privileged Entra ID roles in Conditional Access, by selecting directory roles in the policy assignments;
3. Integrate protected actions into Conditional Access policies to enforce step-up authentication when users perform specific privileged and high-impact actions (see next point for more details).

Other use cases include enforcing stricter authentication requirements when connecting from outside a trusted location, when a user is flagged with a risk in Identity Protection, or when accessing sensitive documents in SharePoint Online.

Finally, as mentioned above, external users (only those authenticating with Microsoft Entra ID, at the time of writing) can be required to satisfy Authentication Strengths policies. The behavior will depend on the status of the cross-tenant access settings, as explained in my previous blog post.

Use Authentication Context to protect specific actions and applications

License requirement: Entra ID Premium P1

Authentication Contexts in Conditional Access allow to extend the locations or actions covered by Conditional Access policies. Indeed, they can be associated with applications, SharePoint Online sites or documents, or even specific privileged and high impact actions in Entra ID.

Before diving into how they can be used, we will quickly go over how they can be created. Authentication Context is a feature of Microsoft Entra Conditional Access and can therefore be managed from the Conditional Access service. Before being able to use them, they need to be created and published to applications:

Once they have been created and published, we can use them in Conditional Access policies. Let’s take a closer look at the different scenarios described above:

1. Integrate Authentication Contexts in Sensitivity Labels to require step-up authentication or enforce restrictions when accessing sensitive content:

In this first example, the Super-Secret sensitivity label has been configured to require step-up authentication when accessing documents with that label assigned:

If we configure the below CA policy with the target resource set to the ‘Sensitive documents’ Authentication Context, users will have to satisfy the phishing-resistant MFA requirements, unless it has already been satisfied, when accessing documents labeled with the Super-Secret label:

• Integrate Authentication Context with Privileged Identity Management roles to enforce additional restrictions on role activation (PIM requires Entra Premium P2 licenses):

Role settings in Entra Privileged Identity Management can be changed to require Authentication Context on role activation. That way, administrators can ensure that high privileged roles are protected against abuse and only available to authorized users themselves:

When such control is configured in PIM, users will not be prompted to perform MFA twice if the specified MFA requirement has been previously met during the sign-in process. On the other hand, they will be prompted with MFA if it hasn’t been met before.

Similar to the previous point, the same principle applies to the creation of the Conditional Access policy. The custom PIM Authentication Context should be set as the target resource, and the conditions and access controls configured to meet your security requirements.

Important note: when changing the configuration of high privileged roles, which allow to modify the configuration of Microsoft Entra PIM, make sure you are not locking yourself out of the environment by having at least one active assignment configured.

• Integrate Entra ID Protected Actions with Conditional Access policies:

Finally, by integrating Entra Identity Protected Actions with Conditional Access, administrators can introduce an extra layer of security when users attempt specific actions, such as modifying Conditional Access policies. Once again, make sure you are not locking yourself out here.

With Protected Actions, you can require strong authentication, enforce a shorter session timeout or filter for specific devices. To create a Protected Action, administrators first need to create an Authentication Context, which will then be assigned to a set of actions in the ‘Entra ID Roles and administrators’-page:

In this example, the ‘Protected Actions’ Authentication Context has been linked to permissions that allow updating, creating, and deleting Entra Conditional Access policies.

Then, in a Conditional Access policy, set the target resource to the ‘Protection Actions’ Authentication Context and define the conditions as well as the access controls.

Once in effect, administrators will be required to meet the configured authentication requirements and/or conditions each time they attempt to modify Conditional Access policies:

Use Device Filters in Conditional Access policies conditions

License requirement: Entra ID Premium P1

Last but not least, the ‘Filter for devices’-condition in Entra Conditional Access is a powerful tool that can be used for multiple purposes. Indeed, by using this condition, it is possible to target specific devices based on their ID, name, Ownership, compliance or join state, model, operating system, custom attributes, etc.

Besides the common scenarios of using the device filter condition to target compliant, non-compliant, registered, or joined devices, it can be used to restrict or block access based on more advanced conditions. For instance, you might require that only devices with certain operating system versions, specific device IDs, or device names that follow a particular pattern are allowed to access specific applications. Custom attributes can also be useful for more granularity, if needed.

The following filter will target devices meeting the following criteria:

• The display name of the device should contain ‘ADM’;
• The device should be seen as compliant, in Microsoft Intune, for instance;
• The device state should be Microsoft Entra joined;
• And the ExtensionAttribute4 should contain ‘anyvalue’. Extension Attributes for Entra ID registered devices can be added and customized using the Microsoft Graph REST API.

More information about the different operators and properties can be found in the ‘Resources’-section below.

Bonus: Restrict authentication flows

License requirement: Entra ID Premium P1

The ability to restrict authentication flows in Microsoft Entra Conditional Access, which is still in preview, has been introduced end of February (when I was writing this blog post). I included it to make sure that you are aware of this new feature. However, I do not recommend implementing it in production before it is released in General Availability (at least without proper investigation and testing!).

This functionality has been introduced as a new condition in Microsoft Entra Conditional Access policies and allows to restrict device code flow and authentication transfer.

Firstly, the device code flow has been introduced to facilitate user sign-in on input-constrained devices, referred to as ‘device A.’ With this flow, users can authenticate on ‘device A’ by using a secondary device, referred to as ‘device B.’ They do this by visiting the URL: https://login.microsoftonline.com/common/oauth2/deviceauth. Once the user successfully signs in on ‘device B,’ ‘device A’ will receive the necessary access and refresh tokens.

The flow can be represented as follows:

However, this functionality has been, and still is, abused by attackers attempting to trick users into entering the device code and their credentials.

Therefore, Conditional Access policies could now be used to block device code flow, or restrict it to managed devices only. This measure helps ensure that phishing attempts are unlikely to succeed unless the attackers possess a managed device.

Moreover, device code flow authentication attempts are visible in the Entra ID Sign-in Logs:

Secondly, authentication transfer enables users to transfer their authenticated state from one device to another, for instance, by scanning a QR code with their mobile phone from a desktop application. This functionality allows to reduce the number of times users have to authenticate across the different platforms. However, by doing so, users aren’t required to perform MFA again on their mobile phone if they have already performed MFA on their laptop.

Like device code flow authentication, authentication transfer can be blocked using a Conditional Access policy. To do so, simply select ‘Authentication transfer’ under Transfer methods.

Finally, authentication transfer can also be detected in the Entra ID Sign-in logs. Indeed, ‘QR code’ is set as the authentication method in the authentication details.

Evaluate Conditional Access policies

License requirement: Entra ID Premium P1

As a final note, I wanted to highlight the What If tool in Entra Conditional Access. It allows administrators to understand the result of the CA policies in their environment. For that purpose, administrators can select target users, applications, any available conditions, etc., to make sure that existing CA policies have the expected behavior. It also helps troubleshooting the configuration by gaining visibility into the policies that apply to users under specific conditions. The What If tool can be accessed in Entra ID > Conditional Access > Policies:

Moreover, the DCToolbox PowerShell module, which is an amazing toolbox for various Microsoft 365 security tasks, developed by Daniel Chronlund, also allows you to evaluate your current Conditional Access policies for a specific scenario. For that purpose, you can use the Invoke-DCConditionalAccessSimulation function and the tool will fetch all existing CA policies and evaluates them against the scenario that you have provided as arguments. You can find the DCToolbox PowerShell module on GitHub here: https://github.com/DanielChronlund/DCToolbox.

I highly recommend using one of these tools to evaluate your newly created or existing Conditional Access policies. Also note that proper testing and validation with different pilot phases and progressive rollouts is essential to avoid impacting end users when creating new policies.

Finally, as a general best practice, Conditional Access policies, and potential exceptions, should be properly documented. For that purpose, the DCToolbox tool allows you to export the current configuration of your Conditional Access policies in an Excel file, for example.

Conclusion

In this second blog post about Entra Conditional Access settings and configurations, we went over important principles that might help you increase the overall security posture of your environment. As for the first part, the settings and configuration items that I have highlighted could be considered when designing or reviewing your Entra Conditional Access implementation. This list is non-exhaustive and has been made based on my experience reviewing and implementing Conditional Access policies in different environments. Also, it is important to rigorously evaluate any policies before rolling them out in production and to make sure that other controls have also been properly configured in your cloud environment. Conditional Access policies are a great way to safeguard your identities and critical resources, but are not the only layer of defense that you should be relying on.

At NVISO, we have built an expertise reviewing cloud environments and have designed and implemented Entra Conditional Access on numerous occasions. If you want to know more about how we can help you in the journey of building or strengthening your Conditional Access setup, among others, feel free to connect on LinkedIn or visit our website at https://www.nviso.eu.

Resources

You can contact me on LinkedIn should you have any questions or remarks. My contact details can be found below.

Additionally, if you want to get a deeper understanding of some of the topics discussed in the blog post, all the resources that I have used can be found below:

• Conditional Access: Block access: https://learn.microsoft.com/en-us/entra/identity/conditional-access/howto-conditional-access-policy-block-access  
• Common Conditional Access policy: Require approved client apps or app protection policy: https://learn.microsoft.com/en-us/entra/identity/conditional-access/howto-policy-approved-app-or-app-protection
• App Protection Policies overview: https://learn.microsoft.com/en-us/mem/intune/apps/app-protection-policy
• App Protection Policy settings for Windows: https://learn.microsoft.com/en-us/mem/intune/apps/app-protection-policy-settings-windows
• Manage authentication methods for Microsoft Entra ID: https://learn.microsoft.com/en-us/entra/identity/authentication/concept-authentication-methods-manage
• What are protected actions in Microsoft Entra ID: https://learn.microsoft.com/en-us/entra/identity/role-based-access-control/protected-actions-overview
• Add, test, or remove protected actions in Microsoft Entra ID: https://learn.microsoft.com/en-us/entra/identity/role-based-access-control/protected-actions-add
• Conditional Access: Filter for devices: https://learn.microsoft.com/en-us/entra/identity/conditional-access/concept-condition-filters-for-devices

About the author

Introduction

In this blog post, I focus on the top things that you might not be doing (yet) in Entra Conditional Access. It is not an exhaustive list, but it is based on my experience assessing many different Entra ID, formerly Azure AD, environments as a consultant at NVISO Security.

The following points are, in my opinion, some of the most important security controls that can be enforced and configured using Conditional Access to improve the overall security posture of your Azure or Microsoft 365 tenant. Note that items do not have a particular order in the list. They are all more or less equally important to correctly protect and secure identities in Entra ID as some might rely on others to be fully functional in terms of security or have the intended effect.

Please do keep in mind that this article focuses on features that require the Entra ID Premium P1 and P2 licenses . Therefore, if none of those licenses are available, check my previous blog post on how to protect identities in Entra ID Free: https://blog.nviso.eu/2023/05/02/enforce-zero-trust-in-microsoft-365-part-1-setting-the-basics/.

Additionally, should you need any introduction to what Entra Conditional Access is and which security controls are available, feel free to have a look at this post: https://blog.nviso.eu/2023/05/24/enforce-zero-trust-in-microsoft-365-part-3-introduction-to-conditional-access/.

Entra Conditional Access security controls

Enforce strong authentication for all users

License requirement: Entra ID Premium P1

Strong authentication, such as Multi-Factor Authentication (MFA), represents a huge improvement to the security posture of your identities. Indeed, according to Alex Weinert, based on studies conducted by Microsoft, the Director of Identity Security at Microsoft, using MFA reduces the likelihood of an account breach by 99.9% (reference: Your Pa$$word doesn’t matter – Microsoft Community Hub).

Before diving into more details, where are the main Multi-Factor Authentication types available?

• Something you know: password, passphrase, PIN, etc.
• something you have: a phone, an application, a token, etc.
• Something you are: biometrics, such as fingerprint, facial recognition, etc.
• Somewhere you are: IP address, geolocation, etc.
• And, something you do: set of actions and recognizable patterns of behavior.

Most of them are available or can be enforced in Microsoft Entra, with the exception of “something you do”, which is the least common authentication type nowadays.

Moreover, Multi-Factor Authentication is usually considered as relatively easy to implement compared to other solutions such as passwordless authentication as it does not (always) require the provisioning of additional hardware and software components, for instance. Indeed, MFA requirements can be satisfied using SMS, a phone call, or an application on a mobile phone. I will not go into the details of passwordless versus multi-factor authentication in this blog post, as each method has its own advantages and disadvantages.

So, if you are not doing it yet, make sure that all identities are regularly prompted multi-factor authentication when they are authenticating to your environment. There might be some exclusions for break-the-glass (emergency accounts) or service principals, but these should be documented and monitored to detect suspicious and anomalous activities.

The easiest way to enforce MFA in Entra Conditional Access is to create the following Conditional Access policy:

Note that in this case, “All users” also includes B2B users.

Once the policy is enabled, MFA will be required for all users when authenticating to a cloud application using their company account. The MFA method, such as SMS, call, Microsoft Authenticator, Security Keys, etc., will depend on the configured policies in your environment. There are diverse ways to manage authentication methods in your environment. Some of them will be deprecated in the near future and combined into one unified configuration panel, which is Microsoft Entra Authentication Methods.

First, we have the legacy MFA settings, which are going to be deprecated end September 2025, as you may have guessed based on the name. They can be configured by going to Entra ID > Security > Multifactor authentication > Additional cloud-based multifactor authentication settings:

Then, we have the possibility to configure the Self-Service Password Reset (SSPR) policy. The SSPR policy will be phased out at the same time as the legacy MFA settings in September 2025. However, it can be configured here: Entra ID > Password reset > Authentication methods:

As mentioned above, the Microsoft Entra Authentication Methods policies will be replacing the legacy MFA and SSPR policies after their deprecation date. The new policy can be configured in Entra ID > Protection > Authentication methods > Policies:

It is recommended to migrate to the new authentication methods policy as it provides better control and granularity over authentication methods. For that purpose, Microsoft provides a way to manage the migration to the new method. The different stages of the migration allow to start configuring the new policies but still respect the legacy MFA and SSPR policies and can be summarized in the following table:

Option	Description
Pre-migration	The Authentication methods policy is used only for authentication. Legacy policy settings are respected.
Migration in Progress	The Authentication methods policy is used for authentication and SSPR. Legacy policy settings are respected.
Migration Complete	Only the Authentication methods policy is used for authentication and SSPR. Legacy policy settings are ignored.

Note that before the migration, all policies are merged together, and all authentication methods are respected. This means that users will be able to use any authentication methods enabled in any of those policies.

Regarding which authentication methods should be enabled for users, we recommend using stronger methods such as Microsoft Authenticator, security keys, One Time Passcode (OTP), Windows Hello, and certificate-based authentication. SMS and Voice methods are not the preferred ones as they are prone to different attacks. This does not mean that the other methods, listed as better and best below, cannot be targeted. This is why it is important to make sure that additional security controls have been implemented to make them more secure.

Make sure guest users are always authenticating with MFA

License requirement: Entra ID Premium P1

During security assessments, we have seen that, in some cases, MFA was not enforced on guest users. Indeed, in some configurations, they were either not included or excluded from Conditional Access policies enforcing strong authentication. The reason was that MFA was already enforced in their home tenant and guest users were prompted MFA twice, impacting user experience.

However, guest users can bypass the MFA control from their home tenant if they directly access the resource tenant. For instance, if I want to access a Tenant B Azure environment using an account in Tenant A, I could do it in two different ways:

1. Login to the Azure Portal of Tenant A and use the switch button to access Tenant B, also known as the resource tenant. When doing so, I first need to satisfy all the requirements from the Tenant A, meaning password authentication (i.e., primary authentication) and then strong authentication with MFA (i.e., secondary authentication). Then, if MFA is not enforced for my account in the resource tenant, I will simply click on switch and get access without any further authentication requirements. Note that a user password is always managed in their home tenant and not in the resource tenant;
2. Instead of accessing the resource tenant from my home tenant, I will directly browser to https://portal.azure.com/@tenantb.onmicrosoft.com. When clicking enter, I will be redirected to my home tenant for the primary authentication. Secondary authentication on my home tenant will not apply as I am not accessing a cloud application of my Tenant A. As MFA in the resource tenant is not enforced on my account, I will gain access to the environment without any further authentication requirements, “bypassing” MFA from my home tenant.

Because of that, MFA should be enforced in the resource tenant (too) to prevent that a user account with a compromised password that has been invited as a guest user in your tenant could access your environment without any restrictions.

To tackle the issue of double MFA prompt, Microsoft introduced the cross-tenant access settings which allows to trust the MFA claims of trusted external Entra ID tenants. This can be configured for different tenants individually or by default to apply to all B2B users from any tenants. We do not recommend trusting MFA claims from all external Entra ID tenants as you do not know how external identities are managed in their home tenant. However, this could be configured for trusted partners with whom you have a long-term collaboration and trust the way they secure and protect their identities. The authentication flow using cross-tenant access policies (XTAP) can be represented as follows:

In this case, the user requests access to Tenant B resources from Tenant A. Therefore, they first need to perform primary authentication and satisfy Conditional Access policies, i.e., secondary authentication, in their home tenant. If satisfied, the flow continues. Then, when accessing the Tenant B, where XTAP policies to trust MFA from Tenant A have been configured, the authentication claim issued by Tenant A is validated against Tenant B Conditional Access policies. If satisfied, access to the resource tenant applications is granted.

Block legacy authentication protocols

License requirement: Entra ID Premium P1

Legacy authentication refers to authentication that does not support multi-factor authentication, as well as other controls, such as sending the device compliance or join status. Therefore, when using legacy authentication, users are only prompted for their password to sign-in. However, based on Microsoft, 97 percent of credential stuffing attacks use legacy authentication, and more than 99 percent of password spray attacks also use legacy authentication protocols.

To block such attacks, Microsoft started disabling Basic Authentication for Exchange Online in all Microsoft 365 tenants regardless of usage, except for SMTP Authentication, as of October 1, 2022.

To control the use of legacy authentication protocols across your Microsoft 365 environment, we recommend configuring a Conditional Access policy. There are two approaches for creating this policy: directly or indirectly blocking legacy authentication protocols.

• The following policy can be used to directly block legacy authentication (recommended):

• To indirectly block legacy authentication, the grant control could be set to “Require multi-factor authentication”, “Require device to be marked as compliant”, and/or “Require Microsoft Entra hybrid joined device” instead of “Block”.

Using a dedicated policy to block legacy authentication is recommended as exclusions on users, applications, locations, etc., that may apply for the above grant controls might not apply to the use of legacy authentication protocols in your environment.

Regularly force users to reauthenticate

License requirement: Entra ID Premium P1

Next to strong authentication, authentication session management, or sign-in frequency, is also important. The sign-in frequency will define how often users must re-authenticate to keep access to your environment.

While requiring users to regularly reauthenticate might cause frustration and impact user productivity, it can effectively increase the overall security posture of an environment. Setting a proper sign-in frequency can help preventing unauthorized access to sensitive resources or information. By default, the sign-in frequency in Entra ID is 90 days. 90 days might be just fine for specific use cases, but I highly doubt that it will be considered as safe to use for most organizations for every use case.

It is important to note that when configuring such controls, we should not go too far and not be disruptive to users, as they will probably tend to find alternatives or “hacks” to bypass controls. Because of that, the sign-in frequency, to be effective in my opinion, should be based on conditions. For example, a user authenticating from a managed device in a trusted location represents an overall smaller risk than the same user authenticating from an unmanaged device outside of a trusted location. As a result, the sign-in frequency in the first scenario could be lower than for the second one. Moreover, an administrator assigned to the Entra ID Global Administrator role should also not have the same sign-in frequency as a standard user with no privileges. By implementing a proper sign-in frequency, it helps enforcing the principle of Zero Trust in the environment as access to resources is regularly challenged based on the context and signals.

How can the sign-in frequency be configured in Entra ID? Well, here also, we have different possibilities. First, we have the legacy setting in the per-user MFA portal:

As you can see in the above screenshot, this setting will apply tenant-wide and for all scenarios. Therefore, for more advanced configurations and reduce or increase the number of times users are prompted to reauthenticate based on different signals (i.e., location, device, risk, application, privileges, etc.), Entra Conditional Access policies should be used. Indeed, they allow for more granular configurations as we can target specific applications and users, and configure various conditions.

Note that both settings should not be configured. Indeed, if Conditional Access is used to manage the sign-in frequency, which is greatly recommended, the legacy setting should be turned off to avoid impacting end users with unexpected MFA prompts, for example. If you want to know more information about this, I have already discussed those specificities in previous blog posts (e.g., https://blog.nviso.eu/2023/05/24/enforce-zero-trust-in-microsoft-365-part-3-introduction-to-conditional-access/). Feel free to check them out.

Besides this, it is also possible to let users the possibility to trust the device they are using when authenticating. This is represented by the “Stay signed in?” checkbox when authenticating. This checkbox can be controlled in Conditional Access policies or at the tenant level. In Conditional Access, this behavior can be configured in the Session controls, by setting the ‘Persistent browser session‘-option to Always or Never persistent:

At the tenant level, it can be configured in the User settings by setting the Show keep user signed in toggle to On or Off:

In brief, defining the sign-in frequency and the browser persistence will vary for every organization. However, it is recommended to define it for every use case, such as user, including guest user, or administrative access, and access to sensitive resources or information, from managed or unmanaged devices, from trusted or untrusted locations, etc.

Restrict sensitive user actions

License requirement: Entra ID Premium P1

User actions in Entra Conditional Access policies represent actions that are performed by users, as its name suggests :). At the time of writing, Entra Conditional Access only supports two user actions, namely, register security information, and register or join devices to Entra ID. To better understand why those actions should be protected, let’s see what they actually mean:

• Regis­ter security information refers to the enrollment of an authentication method using the combined registration. In other words, it covers the action of a user adding an MFA method for their account. If registering security information is not restricted, attackers that would have compromised a user password might be able to register their own MFA to gain access to other cloud applications;
• Register or join devices to Entra ID allows users to register or join a device to your Entra ID tenant. If device registration or join has not been restricted, someone might abuse it to register a device, get it enrolled in Microsoft Intune, assuming Automatic Enrollment is being used, get the configuration profiles and compliance policies assigned and finally gain access to protected resources that require a compliant device.

Because of that, it is usually recommended to restrict those actions by requiring strong authentication and / or by requiring users to be in a trusted location. Note that the “Devices to be Microsoft Entra joined or Microsoft Entra registered require multifactor authentication”-setting in Entra ID should be set to ‘No’ first, before configuring a Conditional Access policy to require MFA on device join or registration.

These restrictions will vary depending on your organization’s security requirements. Additional restrictions can be configured for registering or joining a device in Entra ID device settings.

Configure restrictions on service accounts

License requirement: Entra ID Premium P1 & Entra ID Workload Identities Premium

In Entra ID, there are three types of service accounts: user-based service accounts, service principals, and managed identities. These identities are not meant for human access but represent an instance of an application used to access Entra ID or Azure resources such as services, APIs, etc.

A user-based service account is simply a standard user account used as a service account. One common example is the Directory Synchronization Account which is used in hybrid environments. However, creating such accounts for your applications is not recommended as their passwords must be stored somewhere and managed making them more prone to credentials leak. If such accounts are used, their sign-ins should be restricted to specific locations and/or devices. This can be done using a Conditional Access policy.

Then, service principals are a representation of an application object in Entra ID. These service accounts have two authentication methods available: secret- and certificate-based authentication. Certificate-based authentication is recommended as it cannot be (accidentally) hardcoded in the application code, making it less prone to credential leaks. Sign-in attempts from service principals can be covered by Conditional Access policies but it requires additional Entra ID Workload Identities Premium licenses. If available, it is recommended to restrict the use of the service principals to strict locations to prevent abuse in case of credential leak. Risk-based policies for service principals are also available and should be considered. For instance, access from service principals associated with a medium or high risk could be blocked:

Finally, managed identities are identities that can be associated with Azure resources to access other resources or services. They are considered as the most secure option as you do not have to manage any credentials for them. They cannot be covered by Conditional Access.

Further resources on how to secure those identities can be found below.

Enforce restrictions based on user risk, and sign-in risk

License requirement: Entra ID Premium P2, very limited feature in Entra ID Premium P1

Last but not least, Entra Identity Protection signals can be included to Entra Conditional Access to automatically act upon user and sign-in risk. Identity Protection is a service that allows organizations to identify, investigate, and remediate risks related to identities. Entra Identity Protection calculates user and sign-in risk based on real-time and offline detections, such as anomalous token, atypical travel, credentials leak, possible attempt to access Primary Refresh Token (PRT), etc. The full list of detections for both Premium P2 customers, and Free or Premium P1 customers are available in the ‘Resources’-section.

To integrate Identity Protection signals into Conditional Access policies, Entra ID Premium P2 licenses are required. Note that it is recommended to use Conditional Access policies instead of the Identity Protection policies directly as Conditional Access allows for better granularity and more control over the configuration.

As a standard recommendation, user sign-ins that are associated with a medium or higher risk should require users to perform MFA. On the other hand, users associated with a high risk, should, at least, be requested to change their password.

Once implemented, it allows to reduce the risk of unauthorized access in case of account compromise or suspicious activities. Moreover, users with credentials that have leaked can be required to change their password to make sure their account cannot be abused.

Conclusion

The above security controls can help your organization enhance its cloud and identity security posture. Indeed, as identities have become the new perimeter in cloud environments, it is essential to implement strong controls around identities to safeguard your sensitive and critical resources. The above list highlights basic but important controls that should be considered when designing or reviewing your Entra Conditional Access implementation.

While this list is not exhaustive and there are many more essential security controls to take into account, it can already be used to strengthen the defenses of your cloud environment. If some of these controls are not implemented yet in your environment, I highly encourage you to reevaluate your current controls and investigate the different capabilities discussed above.

At NVISO Security, we have built an expertise reviewing cloud environments and we have designed and implemented Entra Conditional Access policies on numerous occasions. If you want to know more about how we can help you in the journey of building or strengthening your cloud environment, feel free to connect on LinkedIn or visit our website at https://www.nviso.eu.

Resources

You can contact me on LinkedIn should you have any questions or remarks. My contact details can be found below.

Additionally, if you want to get a deeper understanding of some of the topics discussed in the blog post, all the resources that I have used can be found below:

• What authentication and verification methods are available in Microsoft Entra ID?: https://learn.microsoft.com/en-us/entra/identity/authentication/concept-authentication-methods
• Manage authentication methods for Microsoft Entra ID: https://learn.microsoft.com/en-us/entra/identity/authentication/concept-authentication-methods-manage
• Authentication and Conditional Access for External ID: https://learn.microsoft.com/en-us/entra/external-id/authentication-conditional-access
• Block legacy authentication with Microsoft Entra Conditional Access: https://learn.microsoft.com/en-us/entra/identity/conditional-access/block-legacy-authentication
• Configure authentication session management with Conditional Access: https://learn.microsoft.com/en-us/entra/identity/conditional-access/howto-conditional-access-session-lifetime
• Conditional Access: Target resources – User actions: https://learn.microsoft.com/en-us/entra/identity/conditional-access/concept-conditional-access-cloud-apps#user-actions
• Conditional Access for workload identities: https://learn.microsoft.com/en-us/entra/identity/conditional-access/workload-identity
• Securing managed identities in Entra ID: https://learn.microsoft.com/en-us/entra/architecture/service-accounts-managed-identities
• Securing service principals in Entra ID: https://learn.microsoft.com/en-us/entra/architecture/service-accounts-principal
• What are risk detections?: https://learn.microsoft.com/en-us/entra/id-protection/concept-identity-protection-risks

About the author

This blog post is the third blog post of a series dedicated to Zero Trust security in Microsoft 365.

In the first two blog posts, we set the basics by going over the free features of Azure AD that can be implemented in an organization that starts its Zero Trust journey in Microsoft 365. We went over the Security Defaults, the per-user MFA settings and some Azure AD settings that allowed us to improve our default security posture when we create a Microsoft 365 environment.

Previous blog posts:

• Enforce Zero Trust in Microsoft 365 – Part 1: Setting the basics;
• Enforce Zero Trust in Microsoft 365 – Part 2: Protect against external users and applications.

Introduction

In this blog post, we will see what Azure AD Conditional Access is, how it can be used to further improve security and introduce its integration capabilities with other services.

As a reminder, our organization has just started with Microsoft 365. However, we have decided to go for Microsoft 365 for our production environment. Therefore, we want to have a look at a more advanced feature, Azure AD Conditional Access policies. This feature requires an Azure AD Premium P1 license which comes as a standalone license or which is also included in some Microsoft 365 licenses (Microsoft 365 E3/A3/G3/F1/F3, Enterprise Mobility & Security E3, Microsoft 365 Business Premium, and higher licenses). Note that one license should be assigned to each user in scope of any Conditional Access policies.

Azure AD Conditional Access allows to take identity-driven signals to make decisions and enforce policies. They can be seen as if-then statements. For instance, if a user wants to access SharePoint Online, which is a Microsoft cloud application that can be integrated in such policies, the user, more specifically, the user’s request, is required to meet specific requirements, defined in those policies. Let’s now see what the capabilities of those policies are.

Conditional Access

This part will be more theoretical to make sure everyone has the basics. Therefore, if you are already familiar to Azure AD Conditional Access Policies, you can directly jump to the next section for the implementation where we go over some prerequisites and important actions that need to be done to avoid troubles when setting up those policies based on our hands-on experience.

Conditional Access signals

As we have seen, signals will be considered to make a decision. It is possible to configure the following signals:

• User, group membership or workload identities (also known as service principals or managed identities in Azure): It is possible to target or exclude specific users, groups, or workload identities from a Conditional Access policy;
• Cloud apps or actions: Specific cloud applications such as Office 365, the Microsoft Azure Management, Microsoft Teams applications, etc. can be targeted by a policy. Moreover, specific user actions like registering security information (registering to MFA or Self-Service Password Reset) or joining devices can be included as well. Finally, authentication context can also be included. Authentication contexts are a bit different as they can be used to protect specific sensitive resources accessed by users or user actions in the environment. We will discuss authentication contexts in details in later blog post;
• Conditions: With an Azure AD Premium P1 license, specific conditions can be set. This includes:
  • The device platforms: Android, iPhone, Windows Phone, Windows, macOS and Linux;
  • The locations: Conditional Access works with Named Locations which can include country/countries or IP address(es) that can be seen as trusted or untrusted;
  • The client apps: client apps which support modern authentication: Browser and Mobile apps and desktop clients; and legacy authentication clients: Exchange ActiveSync clients and other clients;
  • Filter for devices: allows to target or exclude devices based on their attributes such as compliance status in the device management solution, if the device is managed in Microsoft Endpoint Manager or on-premises, or registered in Azure AD, as well as custom attributes that have been set on devices;
  • Note that these conditions need to be all matched for the policy to apply. If a condition such as the location is excluded and match an attempt to access an application, the policy will not apply. Finally, if multiple policies matched, they will all apply, and access controls will be combined (the most restrictive action will be applied in case of conflicts).

Conditional Access access controls

Then, we have the access controls which are divided into two main categories, the “grant” and the “session” controls. These access controls define the “then do this” part of the Conditional Access policy (if all conditions have matched as mentioned previously). They can be used to allow or block access, require MFA, require the device to be compliant or managed as well as other more specific controls.

Grant controls

• Block access: if all conditions have matched, then block access;
• Grant access: if all conditions have matched, then grant access and optionally apply one or more of the following controls:
  • No controls are checked: Single-Factor Authentication is allowed, and no other access controls are required;
  • Require Multi-Factor Authentications;
  • Require authentication strength: allows to specify which authentication method is required for accessing the application;
  • Require device to be marked as compliant: this control requires devices to be compliant in Intune. If the device is not compliant, the user will be prompted to make the device compliant;
  • Require Hybrid Azure AD joined devices: this control requires devices to be hybrid Azure AD joined meaning that devices must be joined from an on-premises Active Directory. This should be used if devices are properly managed on-premises with Group Policy Objects or Microsoft Endpoint Configuration Manager, formerly SCCM, for example;
  • Require approved client apps: approved client apps are defined by Microsoft and represent applications that supports modern authentication;
  • Require app protection policy: app protection policies can be configured in Microsoft Intune as part of Mobile Application Management. This control does not require mobile devices to be enrolled in Intune and therefore work with bring-your-own-device (BYOD) scenarios;
  • Require password change;
  • For multiple controls (when multiple of the aforementioned controls are selected):
    • Require all the selected controls;
    • Require one of the selected controls.

Session controls

• Use app enforced restrictions: app enforced restrictions require Azure AD to pass device information to the selected cloud app to know if a connection is from a compliant or domain-joined device to adapt the user experience. This control only works with Office 365, SharePoint Online and Exchange Online. We will see later how this control can be used;
• Use Conditional Access App Control: this is the topic of a later blog post, but it allows to enforce specific controls for different cloud apps with Microsoft Defender for Cloud Apps;
• Sign-in frequency: this control defines how often users are required to sign in again every (x hours or days). The default period is 90 days;
• Persistent browser session: when a persistent session is allowed, users remain signed in even after closing and reopening their browser window;
• Customize continuous access evaluation: continuous access evaluation (CAE) allows access tokens to be revoked based on specific critical events in near real time. This control can be used to disable CAE. Indeed, CAE is enabled by default in most cases (CAE migration);
• Disable resilience defaults: when enabled, which is the case by default, this setting allows to extend access to existing session while enforcing Conditional Access policies. If the policy can’t be evaluated, access is determined by resilience settings. On the other hand, if disabled, access is denied once the session expires;
• Require token protection for sign-in sessions: this new capability has been designed to reduce attacks using token theft (stealing a token, hijacking or replay attack) by creating a cryptographically secure tie between the token and the device it is issued to. At the time of writing, token protection is in preview and only supports desktop applications accessing Exchange Online and SharePoint Online on Windows devices. Other scenarios will be blocked. More information can be found here.

Conditional Access implementation

Before getting started with the implementation of Conditional Access policies, there are a few important considerations. Indeed, the following points might determine if our Zero Trust journey is a success or a failure in certain circumstances.

Per-user MFA settings

If you decided to go for the per-user MFA settings during the first blog post, you might consider the following:

• As mentioned before, Conditional Access policies can be used to enforce a sign-in frequency. However, this can also be achieved using the ‘remember multi-authentication’ setting. If both settings are configured, the sign-in frequency enforced on end users will be a mix of both configuration and will therefore lead to prompting users unexpectedly;
• If trusted IPs, which require an Azure AD Premium P1 license, have been configured in the per-user MFA settings, they will conflict with named locations in Azure AD Conditional Access. Named locations allow you to define locations based on countries or IP address ranges that can then be used to allow or block access in policies. Besides that, if possible, named locations should be used because they allow more fine-grained configurations as they do not automatically apply to all users and in all scenarios;
• Finally, before enforcing MFA with Conditional Access policies, all users should have their MFA status set to disabled.

Security Defaults

Moreover, if you opted for the Security Defaults, it needs to be disabled as they can’t be used together.

How and where to start?

Now that we have some concepts about Conditional Access and some considerations for the implementation, we can start with planning the implementation of our policies. First, we need to ensure that we know what we want to achieve and what the current situation is. In our case, we first want to enforce MFA for all users to prevent brute force and protect against simple phishing attacks.

However, there might be some user accounts used as services accounts in our environment, such as the on-premises directory synchronization account for hybrid deployments, which can’t perform multi-factor authentication. Therefore, we recommend identifying these accounts and excluding them from the Conditional Access policy. However, because MFA would not be enforced on these accounts, they are inherently less secure and prone to brute force attacks. For that purpose, Named Locations could be used to only allow these service accounts to login from a defined trusted location such as the on-premises network (this now requires an additional license for each workload identity that you want to protect: Microsoft Entra Workload Identities license). Except for the directory synchronization account, we do not recommend the use of user accounts as service accounts. Other solutions are provided by Microsoft to manage applications in Azure in a more secure way.

Our first policy could be configured as follows (note that using a naming convention for Conditional Access policies is a best practice as it eases management):

1. Assign the policy to all users (which includes all tenant members as well as external users) and exclude service accounts (emergency/break-the-glass accounts might also need to be excluded):

2. Enforce the policy for all cloud applications:

3. Require MFA and enforce a sign-in frequency of 7 days:

4. Configure the policy in report-only first

We always recommend configuring Conditional Access policies in report-only mode before enabling them. The report-only feature will generate logs the same way as if the policies were enabled. This will allow us to assess any potential impact on service accounts, on users, etc. After a few weeks, if no impact has been discovered, the policy can be switched to ‘On’. Note that there might be some cases where you may want to shorten or even skip this validation period.

These logs can be easily access in the ‘Insights and reporting‘ panel in Conditional Access:

Conclusion

In this third blog post, we learned about Conditional Access policies by going over a quick introduction on Conditional Access signals and access controls. Then, we went over some implementation considerations to make sure our Zero Trust journey is a success by preventing unexpected behaviors and any impact on end users. Finally, we implemented our very first Conditional Access policy to require Multi-Factor Authentication on all users except on selected service accounts (which is not the best approach as explained above).

If you are interested to know how NVISO can help you planning your Conditional Access policies deployment and/or support you during the implementation, feel free to reach out or to check our website.

In my next blog post, we will see which policies can be created to enforce additional access controls without requiring user devices to be managed in Intune to further protect our environment.

About the author

In the first blog post of this series, we have seen how strong authentication, i.e., Multi-Factor Authentication (MFA), could be enforced for users using a free Azure Active Directory subscription within the Microsoft 365 environment.

In this blog post, we will continue to harden the configuration of our Azure AD tenant to enforce Zero Trust security without any license requirement. Specifically, we will see how our organization can protect against external users and prevent malicious applications from accessing our tenant.

Previous blog post:

• Enforce Zero Trust in Microsoft 365 – Part 1: Setting the basics

Settings hardening

Because some default settings in Azure Active Directory are not secure and might introduce security issues within our organization, I wanted to quickly go over them and see how they could be used by malicious actors.

Guest users

We haven’t discussed guest users for now. It is because access control for guest users can’t be enforced using an Azure AD free license. However, guest users might be the entry door for attackers to access our Microsoft 365 environment. Indeed, by compromising a user in a partner’s environment, adversaries will directly gain access to our environment because of this implicit trust relationship that is automatically setup when inviting guest users. Therefore, we can either assume that guest users are correctly protected in their home tenant (we will see in a later blog post that even if guest users have the appropriate security controls enforced in their home tenant, these security controls might not be enforced in certain circumstances to access our tenant (i.e., the resource tenant)), or restrict or disable guest user invitations. In any case, the way guest users will be managed is an important consideration for our Zero Trust approach. In our case, we will not simply block guest user invites because we think that collaboration with external parties is an important aspect for our business and will be required. Therefore, we want to take a proactive approach to this problem by setting a solid foundation before it is too late.

First, we want to ensure that no one in the organization, except authorized users, can invite guest users. Indeed, by default, all users in our organization, including guest users, can invite other guest users. This could represent a serious weakness in our Zero Trust approach. Therefore, we will only allow users assigned to specific administrator roles to invite guest users (this includes the Global Administrators, User Administrators and Guest Inviters roles).

Guest invite restrictions are configured in Azure AD. For that purpose, go to the Azure Portal > Azure Active Directory > Users > User Settings > Manage external collaboration settings under External users. Choosing the most restrictive option disables the ability to invite guest users.

Moreover, because our organization works with defined partners, users should only be able to collaborate with them. We can therefore further restrict invitations by specifying domains in the collaboration restrictions settings:

For those restrictions, a reliant process is required to clearly define who can manage guest users and external domains, especially if you regularly collaborate with different partners.

By default, guest users have extensive permissions. If an attacker takes over a guest account, the information to which the guest user has access, may be used for advanced attacks on our company. For this reason, we want to restrict them as much as possible. It might not be required for guest users to be able to enumerate resources in our Azure Active Directory tenant. This could allow adversaries, that compromised a guest user, to gain information on users within our tenant such as viewing our employees for sending (consent) phishing emails to gain initial access or viewing other partners to deceive them by impersonating our company or an employee. Therefore, we want to limit guest users permissions.

With these restrictions implemented for guest users, we have already decreased the potential impact that a compromised guest user could have in our environment. However, remember that with the current configuration, specific access controls, such as strong authentication for guest users, are not enforced to access our tenant. This means that a compromised guest user might still be used to access our environment.

External applications

In Azure Active Directory, applications can be integrated into Azure Active Directory to make them accessible to user. There are many types of applications that can be made accessible through Azure AD such as cloud applications, also known as pre-integrated applications, like Office 365, the Azure Portal, Salesforce, etc., custom applications, and on-premises applications.

Users can consent to applications to allow these applications to access organization data or a protected resource in the tenant on their behalf. Indeed, applications can request API permissions so that they can work properly. These API permissions include accessing a user’s profile, a user’s mailbox content, sending emails, etc. This can also be seen as an entry door for adversaries to gain access to information in our environment. For example, attackers could trick an employee by sending a consent link (consent phishing) to an employee for a malicious application. If the user consents, attackers would have the permissions the user has consented to. Even worse, an administrator might consent to an application for the entire organization. This means that a malicious application could potentially gain access to all directory objects.

Let’s abuse it!

If user consent is allowed in our Azure AD tenant, adversaries could send consent grant phishing to employees. Let’s see how this could be done.

First, because adversaries could access our Azure AD tenant because guest invitation restrictions were initially not configured, they could gather a list of our employees as well as their email address. Then, they used this list to create a phishing campaign for a Microsoft Advertising Certification study guide.

Because one employee was very eager to try out this new limited edition guide, they clicked the link and signed in with their credentials.

Unfortunately, the employee had administrative permission in our tenant and could therefore grant consent on behalf of the entire organization. Everyone should benefit from this free offer, right?… Not really, no. Indeed, as shown in the above screenshot the application, which is not verified, requires a lot of access such as sending and viewing emails, read and write access to mailbox settings, and read access to notes, files, etc.

Once the user clicks, adversaries can retrieve information about the user as well as from the organization. Additionally, they can access the user’s mailbox, OneDrive files and notes.

For this demonstration, I used 365-Stealer from AlteredSecurity to setup the phishing page and to access users in the directory:

How to protect ourselves against consent grant phishing?

There are no bullet proof solutions to protect users from phishing, unless you disable the ability for users to receive emails and messages globally, which is very far from ideal. Indeed, even with Office 365 threat policies, such as anti-phishing policies, and user awareness, malicious actors are always finding new ways of bypassing these polices and tricking users. However, what we can do is disabling the ability to consent for applications in Azure AD.

To restrict user consent for applications, it is possible to disable or restrict applications and permissions that user can consent to. Unless it is required, it is highly recommended to disable user consent. This will be done for our organization tenant to prevent consent grant attacks.

This setting can be configured in Azure Portal > Azure Active Directory > Users > User settings > Manage how end users launch and view their applications under Enterprise applications > Consent and permissions.

Besides blocking this functionality, it is also possible to only allow users to consent for permissions classified as low impact. Microsoft provides the ability to define our own classification model for application permissions, ranging from low to high as show below. In that case, administrators can select the Allow user consent for apps from verified publishers, for selected permissions (Recommended) setting in the user consent settings page:

Conclusion

In this blog post, we went over different settings in Azure AD that can be restricted to prevent malicious users from being added to our tenant. Moreover, we have seen how application consent settings can be abused through consent grant phishing and how we can protect against it.

I have selected these settings among others because we usually see that they are not restricted in most environments during our security assessments. However, configuring only these settings is not enough to protect your environment against malicious and unauthorized actions. If you would like to know more about how NVISO can help you securing your environment, feel free to reach out or to check our website.

In the next blog post, we will go over Azure AD Conditional Access policies, see how they can be used to further increase the security posture of our environment and implement our Zero Trust security approach.

About the author

This first blog post is part of a series of blog posts related to the implementation of Zero Trust approach in Microsoft 365. This series will first cover the basics and then deep dive into the different features such as Azure Active Directory (Azure AD) Conditional Access policies, Microsoft Defender for Cloud Apps policies, Information Protection and Microsoft Endpoint Manager, to only cite a few.

In this first part, we will go over the basics that can be implemented in a Microsoft 365 environment to get started with Zero Trust. For the purpose of the blog post, we will assume that our organization decided to migrate to the cloud. We just started investigating what are the quick wins that can be easily implemented, what are the features that will need to be configured to ensure security of identities and data, and what the more advanced features that could be used to meet specific use cases would be.

Of course, the journey to implement Zero Trust is not an easy one. Some important decisions will need to be made to ensure the relevant features are being used and correctly configured according to your business, compliance, and governance requirements without impacting user productivity. Therefore, the goal of this series of blog posts is to introduce you possible approaches to Zero Trust security in Microsoft 365.

Introduction

However, before starting we need to set the scene by quickly going over some principles.

First, what is a Zero Trust security approach? Well, this security model says that you should never trust anyone and that each request should be verified regardless of where the request originates or what the accessed resource is. In other words, this model will assume that each request comes from an uncontrolled or compromised network. Microsoft provides this nice illustration to represent the primary elements that contribute to Zero Trust in a Microsoft 365 environment:

We will go over these components as part of this blog post series.

You may wonder why I have decided to discuss Zero Trust in Microsoft 365. Because I think it is one of the most, if not the most, important aspects of a cloud environment. Indeed, with cloud environments, identities are considered as the new perimeter as these identities can be used to access Internet-facing administrative portals and applications from any Internet-connected device. 

Furthermore, even when security controls are enforced, it does not mean that the environment is secure. There were many attacks these past few months/years that allowed attackers to bypass security controls through social engineering, and phishing attacks, for example. Therefore, the goal is more to reduce the potential impact of a security breach on the environment than to prevent attacks from succeeding.

Finally, let’s go over some Microsoft 365 principles. When an organization signs up for a subscription of Microsoft 365, an Azure AD tenant is created as part of the underlying services. For data residency requirements, Microsoft lets you choose the logical region where you want to deploy your instance of Azure AD. This region will determine the location of the data center where your data will be stored. Moreover, Microsoft 365 uses Azure AD to manage user identities. Azure AD offers the possibility to integrate with an on-premises Active Directory Domains Services (AD DS) but also to manage integrated applications. Therefore, you should/must/have to understand that most of the work to set up a Zero Trust approach will be done in Azure AD.

Let’s get started!

Our organization just bought a paid Microsoft 365 subscription which comes with a free subscription to Microsoft Azure AD. The free Azure AD subscription includes some basic features that will allow us to get started with our journey. Let’s go over them!

Security Defaults

The first capability is the Azure AD Security Defaults. The Security Defaults are a great first step to improve the security posture by enforcing specific access controls:

• Unified Multi-Factor Authentication (MFA) registration: All users in the tenant must register to MFA. With Security Defaults, users can only register for Azure AD Multi-Factory Authentication by using the Microsoft Authenticator app using a push notification. Note that once registered, users will have the possibility to use a verification code (Global Administrator will also have the possibility to register for phone call or SMS as second factor). Another important note is that disabling MFA methods may lead to locking users out of the tenant, including the administrator that configured the setting, if Security Defaults are being used;
• Protection of administrators: Because users that have privileged access have increased access to an environment, users that have been assigned to specific administrator roles are required to perform MFA each time they sign in;
• Protection of users: All users in the tenant are required to perform MFA whenever necessary. This is decided by Azure AD based on different factors such as location, device, and role. Note that this does not apply to the Azure AD Connect synchronization account in case of a hybrid deployment;
• Block the use of Legacy Authentication Protocols: Legacy authentication protocols refer to protocols that do not support Multi-Factor Authentication. Therefore, even if a policy is configured to require MFA, users will be allowed to bypass MFA if such protocols are used. In Microsoft 365, legacy authentication is made from clients that don’t use modern authentication such as Office versions prior to Office 2013 a mail protocols such as IMAP, SMTP, or POP3;
• Protection of privileged actions: Users that access the Azure Portal, Azure PowerShell or Azure CLI must complete MFA.

These features already allow to increase the security posture by enforcing strong authentication. Therefore, they can be considered a first step for our organization that just started to use Microsoft 365 and is still researching/evaluating/ the different possibilities.

If we want to enable Security Defaults, we go to the Azure Portal > Active Azure Directory > Properties > Manage Security Defaults:

However, there are important deployment considerations to be respected before enabling Security Defaults. Indeed, it is a best practice to have emergency accounts. These accounts are usually assigned the Global Administrator role, the most privileged role in Azure AD/Microsoft 365 and are created to enable access to the environment when normal administrator accounts can’t be used. This could be the case if Azure AD MFA experiences outages. Because of the purpose of such accounts, these users should either be protected with a very strong first authentication method (e.g., strong password stored in secure location such as a physical vault that can only be accessed by a limited set of people under specific circumstances) or use a different second authentication factor than other administrators (e.g., if Azure AD MFA is used for administrator accounts used regularly, a third party MFA provider, such as hardware tokens, can be used). But here is the problem: this is not possible when using Security Defaults.

Per-user MFA settings

Note that the per-user MFA settings, also known as legacy multifactor authentication, will be deprecated on September 30^th, 2024.

The second capability with an Azure AD free license is the per-user MFA settings. These settings can be used to require Multi-Factor Authentication for specific users each time they sign in. However, some exceptions are possible by turning on the ‘Remember MFA on trusted devices’. Note that when enabled this setting will allow users to mark their own personal or shared devices as trusted. This is possible, because this setting does not rely on any device management solution. Users will only be asked to reauthenticate every few days or weeks when selecting this option. The interval depends on the configuration.

We usually do not recommend using the ‘Remember MFA on trusted devices’ setting unless you do not want to use Security Defaults and do not have Azure AD Premium licenses. Indeed, this setting allows any user to trust any device, including shared and personal devices, for the specified number of days (between one and 365 days). However, these settings can be configured in the https://account.activedirectory.windowsazure.com portal.

In the user settings, MFA can be enabled for each individual user.

Then, in the service settings, we can allow users to create app passwords for legacy applications that do not support MFA, select authentication methods that are available for all users, and allow or not users to remember Multi-Factor Authentication on trusted devices for a given period of time. Note that the trusted IP addresses feature requires an additional license (Azure AD Premium P1) that we do not have for the moment.

Sum-up

These two features are quite different but allow us to achieve the same goal, to enforce strong authentication, i.e., MFA, for all or some users.

For our organization we will choose the Security Defaults for multiple reasons:

• The per-user MFA settings can become unmanageable quickly. This is especially true for growingorganization.With more people and a complex environment, exceptions will be required, and it will become difficult to keep track of the configuration and keep a good baseline. Security Defaults, respectively,allow to enforce a standard baseline for all users;
• By using per user MFA users will be prompted for MFA every time they sign in.. This badly affects user experience and productivity might be impacted;
• Security Defaults blocks legacy authentication protocols that might be used to bypass MFA in some cases. This prevents identities, including administrators, from being targeted by brute force or password spraying attacks and help mitigating the risk of successful phishing attacks to a certain extent;
• Multi-Factor Authentication registration is enforced with Security Defaults for all users meaning that all users will be capable of doing MFA if required.

By going that way we need to consider that exclusions are not possible. Therefore, emergency accounts or user accounts used as service accounts (which it is not recommended to have as they are inherently less secure than managed identities or service principals) might be blocked. Nevertheless, as we are just evaluating the Microsoft 365 products, we can accept that the environment and cloud applications are unavailable for a few hours without any major impact on business processes. However, this might be an crucial point in the future.

Finally, it is important to note that these two features do not allow to configure more granular controls as we will see later in this series.

Conclusion

In this first blog post, we have seen different possibilities to enforce access restrictions that can be implemented when an organization just starts its journey in Microsoft 365:

• Per-user MFA settings: Allow to enforce MFA for specific users but can become quickly unmanageable and does not provide granular controls;
• Security Defaults: Allow to enforce a strong authentication mechanism and to block legacy authentication protocols that may allow users to bypass MFA. This solution is recommended over the per-user MFA settings. However, note that MFA might not be required in most cases which is not ideal.

In brief, we can see that both solutions have limitations and will not be suitable for most organizations. Indeed, there are still many aspects, such as restricting access based on specific conditions, that are not covered by these capabilities. We will go over additional key features as well as our recommendations for the implementation of a Zero Trust approach in Microsoft 365 in future blog posts.

In the next blog post, we will see how we can protect our environment against external users and applications.

About the author

Introduction

A few weeks ago, I got a question from a client to check how they could prevent administrators, including local administrators on their device, to add exclusions in Microsoft Defender Antivirus. I first thought it was going to be pretty easy by pushing some settings via Microsoft Endpoint Manager. However, after doing some research and tests in a lab environment, I discovered that it might not be as easy as I thought.

What capabilities in Microsoft Defender Antivirus can help us?

Microsoft Defender Antivirus, which is part of the Microsoft Defender for Endpoint (MDE), is one component of the next-generation protection solution. Microsoft Defender Antivirus comes with different features that can be configured using Microsoft Endpoint Manager (MEM)/Intune, Group Policy, PowerShell, etc. These features include cloud-delivered and real-time protection with behavioral, heuristic and machine learning-based protection.

Because some business applications might be blocked by these capabilities, there is the possibility to create specific exclusions for files, processes and processed-opened files from Microsoft Defender Antivirus scans, real-time protection and monitoring. Although they can be useful to benefit from the protection capabilities while preventing any impact on end users and business flows, they represent a protection gap. Indeed, the more exclusions there are, the larger the attack surface is. Therefore, it is a best practice to keep them as limited as possible and to review them periodically.

Because these are protection gaps, you don’t want users from adding exclusions locally on their laptop. By default, standard users can’t change, add or remove exclusions. However, administrators can. This is where our problems start. Indeed, we want to prevent that users help themselves to install suspicious software and we don’t want attackers that would have gained sufficient privileges to add exclusions so that they can install and run their malicious payloads.

How can we prevent users from adding exclusions? We can? Right? We will go over different possibilities in Microsoft Defender for Endpoint to do so.

Tamper Protection

First, let’s have a look at Tamper Protection. By searching on the Internet, I found a few posts mentioning that Tamper Protection could help us to solve this issue.

Tamper Protection is a feature that allows to protect specific protection settings against tampering as its name suggests. The main objective of Tamper Protection is to make sure attackers can’t disable security features to get easier access to your data, install malware or run exploits. In practice, Tamper Protection allows to prevent the following:

• Disabling virus and threat protection
• Disabling real-time protection
• Turning off behavior monitoring
• Disabling antivirus protection, such as IOfficeAntivirus (IOAV)
• Disabling cloud-delivered protection
• Removing security intelligence updates
• Disabling automatic actions on detected threats
• Suppressing notifications in the Windows Security app
• Disabling scanning of archives and network files

Therefore, we can already see that this is not going to help us here. I can also confirm this based on the tests that I have done. During the tests, Tamper Protection is enabled at the tenant level in the Microsoft 365 Defender portal and therefore applied to all devices by default.

Local Admin Merge

Secondly, we have the Defender “local admin merge” feature. This capability looks more interesting. Indeed, it allows to control if exclusion list settings, which are configured by a local admin, will merge with managed settings from an Intune policy. We can use a Microsoft Defender Antivirus profile in Microsoft Endpoint Manager to configure it:

Three values are supported for the Disable Local Admin Merge:

• Not configured: preference settings configured by local administrators will be merged into the resulting effective policy. If there are conflicts, settings from Intune will override local preference settings.
• Enable Local Admin Merge: same as Not configured.
• Disable Local Admin Merge: Intune-managed settings override preference settings that are configured by local administrators.

Theoretically, the Disable Local Admin Merge value would allow to prevent local admins from creating exclusions. We will test that in a moment, but let’s check first if this setting is correctly applied on my device. In the registry editor, I verify that the DisableLocalAdminMerge key is set to 1:

It seems to be the case here, great! If we go to Windows Security on the local machine, we can see that exclusions already exists and that we can’t add or manage them. This is because these policies have been pushed through Intune:

We will now see if we can still add local exclusions to download and run malicious software. First, if we try to download SharpHound for example, it will end up in the user’s download folder and get removed automatically:

As mentioned before, exclusions can be managed in PowerShell. We will add an exclusion for our download folder using the Add-MpPreference -ExclusionPath 'C:\Users\<USERNAME>\Downloads' (make sure to replace <USERNAME>) PowerShell cmdlet. Moreover, we can verify the exclusions that currently apply using Get-MpPreference as shown below:

It looks like our exclusion has been successfully added (see ExclusionPath). Once added, SharpHound can be downloaded and is not removed by Microsoft Defender Antivirus. Additionally, if we bypass the Windows antimalware warning, it can be executed (my machine is not joined to any domain hence the error in SharpHound):

Note that alerts will still be generated in Microsoft 365 Defender for this action because the endpoint detection and response (EDR) capability of Microsoft Defender for Endpoint is running and antivirus exclusions do not apply to it. Indeed, the purpose of EDR is to detect post-breach activities. Usually, EDR is set in block mode to remediate these post-breach detections when a non-Microsoft antivirus product is running.

Based on that, it seems that Disable Local Admin Merge does not allow us to prevent local admins from adding exclusions via PowerShell. Note that it will also be the case via WMI using the MSFT_MpPreference class. In fact, from what I have observed during my testing is that the created exclusions will be overwritten when the device is restarted or when policies are pushed again. However, it did allow us to download and run SharpHound during this time.

Hide Exclusions From Local Admins

The last feature that I wanted to talk about is the Hide Exclusions From Local Admins setting. This setting is not available in Microsoft Defender Antivirus profile yet but can already be configured with a custom configuration profile or with a Group Policy, for example. When enabled, all exclusions in PowerShell, Windows Security and registry editor are not visible to administrators.

It can be configured using the following registry key: Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows Defender\HideExclusionsFromLocalAdmins.

If the value is set to 1 as it is currently the case, it blocks all access to exclusions to administrators as shown below:

• Registry Editor:

• Windows Security application

• PowerShell

However, it does not allow to block admins from adding exclusions. Indeed, it only blocks them from accessing exclusions.

Detection

At the time of writing, there is currently no method to block administrators from adding exclusions. As a general guidance, it is a best practice to avoid granting local administrator permissions to users on their machine. However, it might not always be possible for multiple reasons. In this case, it might be interesting to implement detection measures.

In the Microsoft 365 Defender portal, custom detection rules can be created to detect and alert when such events occur. Moreover, if Microsoft Defender for Endpoint events are connected in Microsoft Sentinel, an analytics rule could also be created. We will focus on creating a custom detection rule in Advanced Hunting in the Microsoft 365 Defender portal as part of this blog post.

When adding an exclusion in Microsoft Defender Antivirus, a registry key is created. Therefore, we can query the DeviceRegistryEvents with the following Advanced Hunting query:

DeviceRegistryEvents
| where ActionType == "RegistryValueSet"
| where RegistryKey contains "HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\Windows Defender\\Exclusions"

However, during my tests, I have noticed that exclusions are pushed again every time a device is restarted when configured in Intune. Therefore, this would generate a lot of false positives. To prevent that, exclusions could be defined in the query to make sure the rule only triggers on non-legitimate exclusions.

let exclusions = dynamic ([
"C:\\myapp",
"myapp.exe",
".app"
]);
DeviceRegistryEvents
| where ActionType == "RegistryValueSet"
| where RegistryKey has "HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\Windows Defender\\Exclusions"
| where RegistryValueName !in (exclusions)

A custom detection rule can be created based on the DeviceId, and rule properties, such as response actions, can be specified to help investigation and remediation activities.

Conclusion

As we have seen during this blog post, it is currently not possible to block administrators from adding exclusions in Microsoft Defender for Endpoint. If local administrators are required on devices, detection mechanisms can be implemented to make sure your security operations teams have visibility on such events.

About the author

Guillaume is a Senior Security Consultant in the Cloud Security Team. His main focus is on Microsoft Azure and Microsoft 365 security where he has gained extensive knowledge during many engagements, from designing and implementing Azure AD Conditional Access policies to deploying Microsoft 365 Defender security products. Additionally, Guillaume has recently gained interest into DevSecOps and has obtained the GIAC Cloud Security Automation (GCSA) certification.

You can find Guillaume on LinkedIn.