Question:

What are the best practices for implementing conditional access policies in different environments? Could you share some examples of the policies you use or recommend, such as MFA requirements, device compliance, protocol blocking, platform restrictions, session lifetime, etc.?

Answer:

How to implement conditional access policies for different environments

Conditional access policies are rules that control the access to cloud applications based on certain conditions, such as user identity, device status, location, sign-in risk, and more. Conditional access policies are essential for securing your resources and enforcing your organization’s access strategy. However, not all environments are the same, and different scenarios may require different policies. In this article, we will discuss some of the best practices for implementing conditional access policies in different environments, and share some examples of the policies we use or recommend.

Before we dive into the examples, let’s review some of the general best practices for designing and deploying conditional access policies:

• Apply Zero Trust principles to conditional access. Zero Trust is a security model that assumes no trust in any entity, and verifies every request before granting access. Zero Trust principles can help you create policies that are granular, adaptive, and context-aware. For example, you can use conditional access to enforce the principle of least privilege, which means granting only the minimum level of access needed for each user and scenario. You can also use conditional access to implement the principle of verification, which means requiring additional authentication factors or device compliance checks when the risk is higher.
• Use report-only mode before putting a policy into production. Report-only mode is a feature that allows you to test the impact of a policy without actually enforcing it. Report-only mode can help you evaluate the effectiveness and accuracy of your policy, and identify any potential issues or conflicts with other policies. You can use report-only mode to monitor the sign-in activity and policy evaluation results for a selected group of users, and then adjust your policy accordingly before applying it to a larger audience.
• Test both positive and negative scenarios. When testing your policy, you should not only verify that it works as expected for the intended users and scenarios, but also that it blocks or challenges the unwanted users and scenarios. For example, if you have a policy that requires MFA for users outside your trusted network, you should test that it prompts for MFA when you sign in from an untrusted network, and that it does not prompt for MFA when you sign in from a trusted network.
• Use change and revision control on conditional access policies. Change and revision control is a process that helps you track and manage the changes made to your policies over time. Change and revision control can help you document the purpose and rationale of each policy, and keep a record of the modifications and updates. You can use change and revision control to review the history and impact of your policies, and to roll back to a previous version if needed.
• Use cloud app security to identify risky apps. Cloud app security is a feature that helps you discover and assess the cloud apps that your users are accessing, and apply policies to control or limit their usage. Cloud app security can help you identify the apps that pose a high risk to your data or compliance, and block or restrict their access with conditional access. For example, you can use cloud app security to detect the apps that use legacy authentication protocols, and block them with conditional access.

Examples of conditional access policies

Now that we have covered some of the best practices, let’s look at some examples of the conditional access policies that we use or recommend for different environments. These examples are based on the common scenarios and recommendations from Microsoft, but you can customize them to suit your specific needs and preferences.

Require MFA for all users

One of the most basic and effective policies is to require MFA for all users. MFA is a method that adds an extra layer of verification to the sign-in process, such as a phone call, a text message, or an app notification. MFA can significantly reduce the risk of account compromise, as it prevents attackers from accessing your resources with just a stolen password. To create a policy that requires MFA for all users, you can use the following settings:

• Users and groups: Include all users, or a specific group of users that you want to apply the policy to.
• Cloud apps or actions: Include all cloud apps, or a specific set of apps that you want to protect with MFA.
• Conditions: No conditions, or any conditions that you want to use to refine the policy scope.
• Access controls: Grant access, and require multi-factor authentication.

Require MFA for admins

Another important policy is to require MFA for admins. Admins are users who have privileged roles or permissions that allow them to manage your resources and settings. Admins are high-value targets for attackers, as they can cause significant damage or disruption if compromised. To create a policy that requires MFA for admins, you can use the following settings:

• Users and groups: Include directory roles, and select the roles that you want to apply the policy to, such as global administrator, security administrator, or conditional access administrator.
• Cloud apps or actions: Include all cloud apps, or a specific set of apps that you want to protect with MFA.
• Conditions: No conditions, or any conditions that you want to use to refine the policy scope.
• Access controls: Grant access, and require multi-factor authentication.

Block Exchange ActiveSync and legacy authentication protocols

Another useful policy is to block Exchange ActiveSync and legacy authentication protocols. Exchange ActiveSync is a protocol that allows mobile devices to sync email, calendar, and contacts with Exchange Online. Legacy authentication protocols are older protocols that do not support modern authentication methods, such as basic authentication or NTLM. Both Exchange ActiveSync and legacy authentication protocols are vulnerable to brute-force or password-spray attacks, as they do not support MFA or conditional access. To create a policy that blocks Exchange ActiveSync and legacy authentication protocols, you can use the following settings:

• Users and groups: Include all users, or a specific group of users that you want to apply the policy to.
• Cloud apps or actions: Include Exchange Online, or any other app that you want to block these protocols for.
• Conditions: Client apps, and select Mobile apps and desktop clients, and then select Exchange ActiveSync clients and Other clients.
• Access controls: Block access.

Block access from unknown platforms

Another helpful policy is to block access from unknown platforms. Unknown platforms are platforms that are not recognized by Azure AD, such as custom or unsupported browsers, operating systems, or devices. Unknown platforms may indicate that the user is using a malicious or compromised app or device, or that the user is spoofing their platform information. To create a policy that blocks access from unknown platforms, you can use the following settings:

• Users and groups: Include all users, or a specific group of users that you want to apply the policy to.
• Cloud apps or actions: Include all cloud apps, or a specific set of apps that you want to block access from unknown platforms for.
• Conditions: Device platforms, and select Unknown.
• Access controls: Block access.

Require MFA for device join

Another beneficial policy is to require MFA for device join. Device join is a process that registers a device with Azure AD, and allows the user to access your resources from that device. Device join can help you manage and secure your devices, but it can also pose a risk if an attacker tries to join a device with stolen credentials. To create a policy that requires MFA for device join, you can use the following settings:

• Users and groups: Include all users, or a specific group of users that you want to apply the policy to.
• Cloud apps or actions: Include Microsoft Entra ID User Registration, which is the app that handles device join requests.
• Conditions: No conditions, or any conditions that you want to use to refine the policy scope.
• Access controls: Grant access, and require multi-factor authentication.

Secure MFA enrollment

Another valuable policy is to secure MFA enrollment. MFA enrollment is a process that sets up the user’s preferred MFA method, such as a phone number or an app. MFA enrollment can help you improve the user experience and adoption of MFA, but it can also pose a risk if an attacker tries to enroll a MFA method with stolen credentials. To create a policy that secures MFA enrollment, you can use the following settings:

• Users and groups: Include all users, or a specific group of users that you want to apply the policy to.
• Cloud apps or actions: Include Microsoft Entra ID User Registration, which is the app that handles MFA enrollment requests.
• Conditions: No conditions, or any conditions that you want to use to refine the policy scope.
• Access controls: Grant access, and require one of the following:
• Require device to be marked as compliant, which means the device must meet the compliance policies defined by Microsoft Intune or another MDM provider.
• Require Hybrid Azure AD joined device, which means the device must be joined to both your on-premises Active Directory and Azure AD.
• Require approved client app, which means the user must use a client app that supports modern authentication and app protection policies, such as the Microsoft Entra app.

Require compliant devices for application access

Another

advantageous policy is to require compliant devices for application access. Compliant devices are devices that meet the compliance policies defined by Microsoft Intune or another MDM provider, such as password requirements, encryption settings, or malware protection. Compliant devices can help you ensure that your devices are secure and up to date, and prevent data loss or leakage. To create a policy that requires compliant devices for application access, you can use the following settings: