Many businesses today rely on Microsoft 365 services. As these services become more popular, they also become more likely targets for hackers. Experience shows that there are still organizations that have not secured their Microsoft Cloud clients. Therefore, organizations should take protective measures against cyberattacks – Conditional Access policies are one such measure. This article provides an overview of how Conditional Access policies work.
To help protect your organization from cyberattacks, Microsoft Entra ID offers the Conditional Access feature. It allows to restrict access to cloud data, enforce multi-factor authentication, or even deny access if certain conditions are not met.
However, misconfigurations during initial implementation or in the day-to-day operation of Conditional Access policies can negatively impact the availability of cloud services to users. In addition, gaps in policy coverage can occur, allowing an attacker to bypass Conditional Access policies. It is therefore advisable to develop an understanding of how Conditional Access policies work.
Table of contents
How Do Conditional Access Policies Work?
Conditional Access is a feature of Microsoft Entra ID (formerly known as Azure Active Directory (AD)). To use it, users must have at least a Microsoft Entra ID P1 license.
The Conditional Access policies take effect when a user’s browser or application logs in to a cloud service. Microsoft Entra ID acts as an Identity Provider (IDP) and interprets certain signals sent by the browser or authenticator application during the login process. Based on these signals, Microsoft Entra ID can recognize who is trying to log in to which application, from where, and with which device, and decide what login criteria and policies should be applied.
In addition to requiring users to use Multi-Factor Authentication (MFA) or only use devices managed by the organization, Conditional Access policies can be used to address more complex scenarios as well. For example, compromised accounts can be prevented from being used by blocking all logins from unapproved countries. The following sections summarize the key points, but the full process is documented here.
What Signals Are Evaluated When Applying Conditional Access Policies?
Microsoft can receive and use the following signals from the login to decide which policy to apply:
- Usernames or group memberships can be evaluated to apply certain policies only to certain users, such as a stricter MFA method for management-level employees.
- IP address information can be used during the login process to completely block access to the client from certain regions. This so-called geofencing is a very effective method to reduce the fundamental threat of attacks on user identities, which very often originate from specific regions or countries.
- Information about the device can be used to determine whether a login is coming from a corporate-managed device or a personal device. This allows effective restriction of access to data from external devices.
- It is also possible to request stronger security measures depending on the application (for example, if you want to protect certain SharePoint pages from data loss and only allow access with corporate devices).
Evaluation and Application of Conditional Access Policies
Based on the signals described above, Microsoft Entra ID evaluates which policy(s) to apply to the user and device.
If multiple policies are present, all access controls from all applicable policies are always applied. If any of the access controls cannot be met, or if a policy is applied that requires access to be denied, the user will not be able to log in.
Which Access Controls Can Be Applied?
Microsoft distinguishes between different access controls that can be applied when a user logs in. Access controls are like minimum requirements that must be met for a user to access the desired systems or data they want. For example, it is possible to only require multi-factor authentication for external access to Outlook, but only allow access to an internal SharePoint site if it is also being accessed from a corporate-managed device.
Common access controls are:
- Multi-Factor Authentication (MFA) requires the user to provide an additional factor when logging in, whether it is via the Microsoft Authenticator or other approved factors such as FIDO2, SMS or email.
- A compliant device or Microsoft Entra hybrid joined device ensures that the user’s device either meets certain minimum requirements or is managed by the organization.
- The use of outdated login protocols that do not support MFA can be prevented with a block policy for legacy authentication.
Other access controls include the ability to set the duration of a login’s validity or require administrators to use a phishing-resistant MFA method. With a Microsoft Entra ID P2 license, you also have access to risk assessments and the ability to force a high-risk user to change their password, for example.
Common Challenges When Implementing Conditional Access Policies
There are a number of important aspects to consider when implementing Conditional Access policies for the first time. The most important factors are outlined below.
Internal Communication
Prior to the planned implementation of the Conditional Access policies, it should be determined how and when employees will be informed of the changes. Even when policies are implemented in report-only mode, they can trigger interactions with the end device, such as “compliant device” checks. Unexpected changes or failed login attempts can lead to an increase in support calls and overload the help desk. To avoid this, a clear strategy for communicating the changes should be developed.
Emergency and Service Accounts
One of the major risks of implementing a strict access control strategy is that you may lock yourself out or critical services may stop working because they do not support MFA.
Microsoft recommends setting up at least two emergency access (“break glass”) accounts that are exempt from all policies. This can also be useful if the cloud service by Microsoft that provides MFA stops working, as it did a few years ago. These accounts should have long and complex passwords with specific rules for how they are stored and accessed. In addition, an alert rule should be set up to trigger a notification when an emergency account is used.
Service accounts also cannot satisfy MFA or other access controls because they do not log in interactively. An example of this, especially in hybrid scenarios, is the Microsoft service for directory synchronization between local AD and Entra ID.
A simulation tool (“What If” tool) can be used to plan and analyze the login behavior of individual accounts. This is integrated into the Entra ID administration interface (see Troubleshooting Conditional Access using the What If tool for more information). In addition, the login log of user and service accounts can be used to identify the policies applied. All factors and policies are stored there for 30 days.
For more information, see Manage emergency access accounts in Microsoft Entra ID on Microsoft’s website.
Basic Templates for Conditional Access Policies
Microsoft itself recommends implementing the policies from the “Secure Foundation” template category when implementing Conditional Access policies for the first time. These templates can be easily imported directly from the Entra ID administration interface and serve as basic hardening (see Conditional Access templates for more information).
The templates include a number of predefined policies for different scenarios, including the following policies:
- Securing security info registration serves as a policy to control the conditions under which users are allowed to set up MFA. This allows administrators to secure the MFA registration process itself.
- Require multifactor authentication for all users will make MFA mandatory for all users.
- Require multifactor authentication for admins controls MFA authentication behavior based on the administrative Entra roles assigned to a user. For example, if the account is a user administrator, a second factor is required.
- Require multifactor authentication for Azure management is a similar policy to the one above, but can be used to impose additional requirements (for example, phishing-resistant login factors) when settings need to be configured at the core of the tenant.
- Require compliant or Microsoft Entra hybrid joined device or multifactor authentication for all users provides the option of not using MFA as long as users are using a device that is managed by the company or meets the company’s requirements. Managed devices also offer the benefit of additional policies that can be used to bind the so-called session token to the managed device, providing additional protection against certain attacks such as token theft.
- Block legacy authentication is important to prevent outdated login protocols that do not support a second factor.
- Block access by location is particularly interesting for organizations that want to use cloud services but operate in a well-defined geographic area, allowing them to block a large portion of illegitimate login attempts from around the world.
Once a secure foundation has been created with these policies, as many policies as possible should be adopted from the Zero Trust, Remote work, Protect administrator and Emerging threats template categories.
Conceptual Considerations for a Long-Term Strategy
There are many guidelines and different ways to implement Conditional Access policies. However, once a certain level of complexity is reached, it is advisable to think about conceptual aspects.
The first consideration is which users, with which workload and which devices, will be affected. It may be necessary to clearly separate certain use cases, while others can be combined.
With the persona concept, Microsoft offers an approach that allows users to be divided into requirement groups, such as “internal,” “external,” or “guests”. More information can be found in Conditional Access architecture and personas. In addition, some additional tools and guidelines are described there that can be helpful in developing concepts.
A final recommendation is to establish a naming convention for the policies. This will ensure that the policies are consistently named, which can prevent potential gaps in coverage due to excessive complexity.
Microsoft recommends naming the policies (based on the Conditional Access framework and policies article) according to the following pattern:
CANumber – Persona – PolicyType – App – Platform – GrantControl – OptionalDescription
This ensures that the basic information about the purpose of a policy is already in the name, making it easier to work with policies on a day-to-day basis.
There are also ready-made modular models available on the internet that may seem overwhelming at first, but are well thought out, such as the models by Kenneth van Surksum and Robert Brandso on GitHub and the concept by Daniel Daniel Chronlund.
Conclusion
The secure and sustainable implementation of Conditional Access policies can be a complex undertaking that is often underestimated. It is critical to have a thorough understanding of how the policies work before implementation begins. This provides a solid foundation for the conceptual work. Policies must be carefully tailored to the needs of different user groups within the organization to ensure comprehensive coverage while avoiding potential gaps.
If you need additional support or consultation, or would like an experienced Penetration Tester to review your implementation, we are happy to help.
