Azure AD Conditional Access Best Practices
Today we'll be taking a look at Azure AD Conditional Access. Conditional Access is a feature of Azure AD Premium P1 and P2 that helps organizations control how users access corporate resources
Today we'll be taking a look at Azure AD Conditional Access. Conditional Access is a feature of Azure AD Premium P1 and P2 that helps organizations control how users access corporate resources. My team at Senserva spends a considerable amount of time working with our customers to automate Azure Security with a great part of that on Conditional Access. In this article I will do a deep dive on Conditional Access, provide some baselines and best practices, and offer some insight on how my team helps you manage Conditional Access with less effort and more efficiency.
Background
Conditional access utilizes real-time signals such as user context, device compliance, location, and session risk factors to determine when to allow, block, limit access, or require additional verification steps (such as multi-factor authentication or MFA) to access your Azure-based organizational resources.
Conditional access can be used to ensure that only healthy and trusted devices can access corporate resources by checking device health and security posture of registered devices.
Also included is the ability to monitor and control sessions, application access, and sensitive data in real-time across your organization based on user behavior in your applications.
Conditional Access is a very powerful tool, but there are some shortcomings. We (Senserva) have developed a platform that continuously scans your Azure environment for security and compliance issues, presenting them with an easy to use web portal in an easily digestible format. Our tools can help augment and enhance your use of conditional access policies, allowing you to detect issues and act on them before they end up becoming a problem. Some examples of our tools can be seen in the gallery below. Visit the Common Issues section of this article to see more examples, though reading through the remainder will provide some helpful context.
Policy Components
A conditional access policy is essentially an if-then statement. Building a conditional access policy involves using assignments to make decisions about access to your Azure resources and enforcement of organizational policies.
Assignments include users and groups which determine who the policy will include or exclude, cloud apps or actions which allow the administrator to assign controls to specific applications and actions, and conditions like risk, device platform, or location.
Common signals for users and groups:
- Include or exclude none, all, or select users
- Exclude guest or external users
- Include specific directory roles
- Target specific sets of users (groups)
Common signals for cloud apps or actions:
- Administrators can add any Azure AD registered application to conditional access policies
- User actions like registering security information
- Registering or joining devices
- Authentication context
Common signals for conditions:
- Sign-in risk
- User risk
- Device platform
- Sign-in location
- Client applications
- Supported browsers
- Filter for devices which can restrict access to privileged resources, restrict access for non-compliant devices, exempt devices from multi-factor authentication, etc.
These assignments (signals) are then used to make decisions about resource access, such as:
- Block or grant access to a resource
- Require multi-factor authentication
- Require compliant devices
- Require hybrid Azure AD joined device (periodic on-premise connection)
- Require approved client app
- Require app protection policy
- Require terms of use acceptance
- Require client certificate
- Session controls
- Allow or restrict persistent sign on
- Specify user sign in frequency
Baseline Policies
A number of basic policies can be applied in order to create a security baseline for your organization.
1) Enforce multi-factor authentication
Multi-factor authentication makes user accounts significantly less likely to be compromised and should be required for all users except for certain emergency access or break-glass accounts.
2) Block legacy authentication protocols
Legacy authentication protocols (such as POP, SMTP, IMAP) cannot enforce MFA, therefore provide a significant security risk for your organization.
3) Require device compliance or hybrid joined devices
Requiring users to perform actions from devices marked as compliant or hybrid Azure AD joined can limit possible exposure to targeted attacks on accounts with highly privileged rights. This requires an endpoint management tool such as Microsoft Intune.
4) Block or require MFA for high-risk sign-in events
Risky sign-ins are triggered by detections that indicate an authentication request isn't authorized by the identity owner. Azure AD Premium P2 licenses can create conditional access policies incorporating Azure AD Identity Protection sign-in risk detections.
5) Block, require MFA, or password change for high-risk users
Using the aforementioned Azure AD Identity Protection user risk detections, policies can be created to block, require MFA, or password changes for high-risk users. Attributes like sign-in frequency can be accessed in the policy.
6) Session policies such as reauthentication and browser persistence
Session controls such as application enforced restrictions, conditional access application control, sign-in frequency, and persistent browser sessions can be controlled with conditional access policies.
Blocking access by location, or geofencing, can control access to your organization's resources and prevent unauthorized access from countries or regions where network traffic is unexpected. Location-based policies can also be used to create trusted locations, like a corporate office, by configuring policies which utilize IP address ranges and/or geographical locations. However, global administrators should have MFA enforced at all times and locations.
Recommendations & Best Practices
Apply Conditional Access to every authentication request for all users and applications. From a security standpoint, it is better to create policies that cover all cloud applications, then create exclusions for specific applications. This makes adding new applications easier.
Minimize the number of policies - conditional access has a limit of 195 policies per tenant. Creating policies for each application is difficult to administer and inefficient. Analyze your applications and group them by resource/user group requirements, then apply policies as such.
Configure report-only mode when creating new policies. By default each policy is created in report-only mode. You should test and monitor usage to verify the intended results before turning on conditional access policies. Scope new policies to test accounts and run through a test plan to validate expected results.
Create a resilient access control strategy to prevent access failures to applications and resources if a single access control becomes unavailable or misconfigured.
Use a standard naming convention to help you find policies and understand their purpose at a glance. See this example in Microsoft's documentation.
Consider guest access when defining new policies if the intention of an application is to allow access by users from outside your organization. Also consider geofencing as previously mentioned to block access from countries or regions where you do not expect internet traffic to originate from. Make sure to exempt emergency access accounts from this policy. There are some location-based considerations that can assist with reducing MFA fatigue, as well as some updates to the features of common apps like Microsoft Authenticator.
Zero Trust Principle of Least Privilege
Consider following the Zero Trust principle of least privilege. Azure AD privileged identity management can be used to just-in-time activate privileged role assignments (requires an Azure AD Premium P2 license).
Zero Trust is a security strategy that incorporates three principles:
- Verify explicitly: always authenticate and authorize for all resources based on all available data, including identity, device health, location, and anomalies.
- Use least privilege access: limit user access with just-in-time and just-enough-access, adaptive policies based on risk, and protection of data.
- Assume breach: minimize blast radius and segment access. Always verify end-to-end encryption and use analytics to drive threat detection.
The Zero Trust model verifies each request as if it originates from an uncontrolled network, instead of assuming that everything behind a firewall is safe. Regardless of where a request originates from or what resource it is attempting to access, the Zero Trust model assumes breach, never trusts, and always verifies.
Privileged Identity Management, or PIM, provides time-based and approval-based role activation to mitigate the risk of excessive, unnecessary, or misused access permissions on corporate resources. Some key features of PIM are that it can provide just-in-time privileged access to Azure AD, assign time-bound access to resources, require approval to activate privileged roles, enforce MFA to activate a role, etc.
Plan an Azure CA Deployment
Prerequisites
Several prerequisites are required for the deployment of conditional access:
- A working Azure AD tenant with Azure AD Premium P1, P2, or trial license is required. P2 is required to include Identity Protection Risk.
- Administrators who interact with conditional access must have one or more of the following role assignments depending on the tasks they're performing: read conditional access policies and configurations, and/or create or modify conditional access policies.
- A test user (or group of test users) that are not administrators that allow you to verify intended policy behavior before deploying to real users.
- A group that the test users are a member of.
Building a Conditional Access Policy
Conditional access policies can be designed to grant access, limit access with session controls, block access, etc. These policies are built using if-then statements.
Some Common Questions to Help Build Policies
Users or workload identities:
- Which users, groups, roles, or workload identities will be included or excluded from the policy? What emergency access accounts should be excluded?
- Emergency access or break-glass accounts to prevent organization-wide access lockouts. In the scenario that all administrators are locked out of your tenant, emergency access administrator accounts can be used to restore access.
- Service accounts and service principals such as the Azure AD Connect Sync Account. Service accounts are not tied to any particular users and are non-interactive. Normally used for back-end services and programmatic access to applications, they are also used to sign into systems for administrative purposes. They should also be excluded from multi-factor authentication.
Cloud apps or actions:
- What applications, user actions, or authentication contexts will this policy apply to?
Conditions:
- Which device platforms, organizational network locations, client app types, and/or device attributes will be included or excluded from the policy? Should sign-in or risky-user conditions be included in the policy?
User and sign-in risk:
- Organizations with P2 licenses, can include risky-user and sign-in risk in their conditional access policies by using Azure AD Identity Protection Risk. These additions can limit multi-factor authentication or secure password change in the event that a user or sign-in is labeled risky by Identity Protection Risk.
Block or grant controls:
- Do you want to block or grant access to resources by requiring: MFA, device compliance, hybrid Azure AD joined devices, approved client apps, password changes, and/or terms of use accepted?
- Policies with block statements can have unintended side-effects. It is important to test and validate policies with block statements before deployment. Use report-only mode as I touched on earlier.
Session controls:
- Do you want to include app enforced restrictions, conditional access app control, sign-in frequency, persistent browser sessions, and/or continuous access evaluation?
Deploy
A phased approach to deployment is recommended for conditional access policies.
- Build your policies
- Evaluate impact with report-only mode and test users/groups.
- Test policies to verify the expected and intended behavior of the policies.
- Deploy in production after confirmation of intended behavior.
- Roll back policies if required by disabling the policy or excluding groups/users.
- Troubleshoot policies if required.
Common Issues
Unfortunately, access to the features of Conditional Access is not free, and requires at least an Azure AD Premium P1 license for both the policy creator and the users of the policy. For risk-based Conditional Access and Privileged Identity Management, an Azure AD Premium P2 license is required. Microsoft 365 E3 includes Azure AD Premium P1, and Microsoft 365 E5 includes Azure AD Premium P2.
Per-user-MFA, which is a free component of Azure AD, includes the ability for a user to disable MFA prompts on trusted machines. Adding trusted devices can present a security risk that your administrators may like to avoid. A safer way to approach this would be to configure a conditional access policy for MFA with location conditions as mentioned previously, which include the options to utilize IP address ranges and/or geographical locations. Remember that global administrators should have MFA enforced at all times and locations.
In the Azure portal it is difficult to determine which takes precedence of per-user MFA or conditional access policy enforced MFA, but it is important to consider that per-user MFA rules supersede MFA rules imposed by conditional access policies. Per-user MFA enforcement status may have to be manually disabled in the Azure portal by a global administrator in order for your MFA conditional access policies to apply properly. On the same page, Microsoft also provides a PowerShell script to do this for all users to assist in converting to conditional access based MFA. One component of Senserva's Conditional Access and MFA workbook provides a report on users that may be covered by per-user MFA so you can easily investigate these accounts to assist with conversion to conditional access.
The What If tool can be used to troubleshoot conditional access policies, but it has some limitations, namely that it can only be executed on one scenario at a time which may be difficult for larger enterprise organizations with many users, policies, and locations.
Along the same lines, there are a large number of scenarios in which a user may be attempting to access corporate resources, and hitting them one at a time with the What If tool may not address all possibilities. This tool is more helpful with debugging an issue that is already known, but it is less helpful for finding issues.
The Senserva Conditional Access and MFA workbook as part of the Senserva Portal included with Senserva Live provides tools that can help identify these issues by providing access to conditional access policy events, information on whether or not conditional access polices are enforced, the number of excluded users per policy, non-compliant devices excluded from policies, among many other reports.
Wrapping Up
By leveraging the capabilities of Azure AD Conditional Access Policies and related tools such as Identity Protection Risk and Privileged Identity Management, along with the best practices we've outlined here, your organization can focus on controlling access to corporate resources and securing your valuable data against breaches and attacks. If you haven't already checked out our blog post about Azure App Services which allow you to quickly build, deploy, and scale web apps with a number of built-in security features, please do!
At Senserva, we prioritize your security in all of our work and products. Please reach out on our contact page and ask for Kyle or TJ, or call +1-651-728-6108 if you have any questions or would like to demo our solution and discuss your needs. We hope to talk with you soon!
Sources
https://www.egroup-us.com/azure-ad-conditional-access-baselines-best-practices/
https://learn.microsoft.com/en-us/security/zero-trust/
https://www.crowdstrike.com/cybersecurity-101/zero-trust-security/
https://learn.microsoft.com/en-us/azure/active-directory/conditional-access/plan-conditional-access
https://learn.microsoft.com/en-us/azure/active-directory/authentication/concept-mfa-licensing
https://learn.microsoft.com/en-us/azure/active-directory/authentication/howto-mfa-userstates
https://learn.microsoft.com/en-us/azure/active-directory/conditional-access/what-if-tool