While describing the NIST zero trust architecture in my last article — Five practical steps for creating a zero trust strategy — we discussed the importance of having a policy engine to evaluate access. The simplest way I think of a policy engine is like a bouncer at a club. Just as a bouncer will enforce the rules and regulations of a venue and ensure that only authorized people are allowed in, a policy engine also enforces pre-defined rules and policies within a system or organization. This ensures that only authorized individuals or actions are allowed, which prevents unwanted behavior or breaches. For Microsoft’s suite of products, that zero trust policy engine is called Entra ID Conditional Access (CA).
Microsoft’s Conditional Access (CA) has evolved significantly over the years from its introduction as part of Microsoft Entra ID (formerly Azure Active Directory) to its integration with the Microsoft 365 product suite, such as Exchange Online, SharePoint Online, Microsoft Intune and Teams.
In this article, we will discuss the new capabilities available and key Conditional Access best practices to help overcome the most common challenges organizations face when using it.
New capabilities in Conditional Access
There are two fairly new capabilities within Conditional Access that have been game-changers — Application Filtering and Authentication Strengths:
- Application Filtering: Before this new capability, CA policies could be applied to either all applications or to individual apps. As a result, it was difficult for organizations to manage a large number of their applications across the multiple CA policies they had defined. This new feature allows organizations to tag applications with custom attributes, such as application tiers or business impact of applications. These attributes are then added to the Conditional Access policies and the filters are evaluated at runtime during token issuance. This allows organizations to better operationalize CA by easily creating policies targeted to the tagged groups of applications. They also no longer need to update their centralized policies as they onboard new applications or want to change the security controls applied to those apps; they can simply tag the applications or change the tags by easily creating policies targeted to the tagged groups of applications.
- Authentication Strengths: This capability leverages the Authentication Methods policy and allows administrators to configure which authentication method needs to be satisfied before a user can access a resource. In the grant control blade, administrators can either choose from the three built-in multifactor authentication (MFA) methods: (MFA strength, Passwordless MFA strength or Phishing-resistant MFA strength), or define a custom authentication strength with any of the authentication methods. So, for example, you can specify that a phishing-resistant MFA is required for access to a highly sensitive document, while access to a medium-sensitivity document would be allowed with any Passwordless MFA method.
Screenshot of the Grant Control blade for Authentication Strength
Screenshot of the three built-in authentication strengths
Overcoming Conditional Access challenges
Creating CA policies is fairly straightforward. However, enterprise customers often face challenges when they:
- Have an excessive number of policies in their environment. Many customers are unaware that CA evaluates only the first 195 policies in scope for a user. Due to this restriction, it is important for administrators to be conscious of the total number of CA policies in their environment, so that they do not exceed that threshold.
- Create policies that are too granular. This ends up creating gaps and leaves more opportunity for sign-ins that do not satisfy any other existing policies. To avoid gaps, it is recommended that policies should be created as broadly as possible. Simplicity is key in this situation.
Four Conditional Access best practices
Here are four recommendations for managing and creating Conditional Access policies:
1. Design an audience matrix with an established baseline
The first best practice is to design an audience matrix and create a baseline policy. An audience matrix represents the diverse personas within your organization. This will guide administrators to develop policies tailored to these personas and thus streamline the number of policies created. For instance, you could define a baseline policy mandating that all privileged users exclusively utilize phishing-resistant methods for privileged actions, or a baseline policy ensuring that all users possess compliant devices before accessing any data.
2. Establish a naming convention
Next, establish a naming convention to clearly identify the purpose of each policy. A straightforward method is to use a letter prefix for each policy name. For example, you could prefix policies for privileged accounts with a “P” and policies for guests with a “G.” This approach simplifies troubleshooting, allows for quick identification of the function of a policy, and brings consistency to the policies in your organization.
Reduce your AD attack surface.
3. Avoid a “Block All Applications” policy
It is crucial for customers to avoid treating Conditional Access (CA) as a firewall. Specifically, refrain from using “block” and “all apps” in the same policy, except in certain scenarios such as blocking legacy authentication. Combining “block” and “all apps” can easily lock administrators out of the Azure Administration Portal. Additionally, certain key endpoints, like Microsoft Graph, cannot currently be explicitly excluded from a CA policy, making the “block all apps” strategy difficult to manage.
4. Classify applications and ensure every application is subject to at least one Conditional Access policy
Finally, classify all your applications according to your business requirements. For instance, you can categorize them based on their business impact (e.g., high, medium, or low), or sort them into tiers reflecting the sensitivity of the data they access. This approach aligns with the goal of creating broad policies, thereby reducing the overall number of policies in your environment. Two examples of classifying applications are shown below.
Migrating Conditional Access policies
It is essential to regularly review and update existing Conditional Access policies, especially as new features and capabilities are released. The steps outlined and in the graphic below provide a simplified strategy for migrating to new Conditional Access policies:
- First, create an empty Microsoft Entra ID security group
- Make sure to include the group on all your new policies
- Exclude the group on all the old policies
- Add users into the new security group that was created to migrate them from the old policy set to the new policy set
- Test with a few users first and flip the new policies to apply to all users when you are satisfied with the results
- Finally, disable the old policies, test and delete later
Conclusion
Conditional Access is Microsoft’s zero trust policy engine. It integrates easily with Microsoft’s products and several third-party applications. The focus in developing and maintaining effective Conditional Access policies should be based on the different personas and types of applications in your organization. The rule of thumb to ensure a high security posture is to keep the policies as simple as possible.
