Greetings! This is Sue Bohn, director of program management for Identity and Access Management. One of our most popular features in Azure Active Directory is Conditional Access which provides the flexibility to enable additional security controls before granting access. It is typically deployed first with Azure multifactor authentication (MFA). Then customers take a deeper look at some of the more advanced controls such as device type, client app, and session controls. Once users become members of several policies, it begs the question which controls are applied first. Which one wins? Read on as Andres from our Get to Production team answers the most common set of questions to help you understand how Conditional Access works under the hood.
Hi all, Andres here! Today I’ll be covering the inner workings of Conditional Access (CA) and some details you need to be aware of to ensure that you’re correctly configuring CA to protect all scenarios.
Q1: How does Conditional Access work?
CA protects token issuance. CA policies are evaluated after authentication, they’re determined to be in scope for the token request at initial sign-in, or when using a refresh token to obtain a fresh access token.
The key concept to understand is that what you see in CA as "Cloud Apps" indicates the token audiences that the policy is protecting.
For example, if you create a new policy and select "Exchange Online" as the application and "Require MFA" as the control, then CA will enforce MFA when an app is requesting a token for Exchange Online. The token Audience in this case is Exchange Online.
To provide more clarity and help with troubleshooting, we recently started including the Resource and Resource ID fields on Azure AD Sign-in Logs. The Resource field shows the token audience. Here is an example, where User3 is using the Outlook Mobile app client to request a token for Office 365 Exchange Online, and it is successfully issued.
After all Grant controls are enforced, any Session controls will be applied. App Enforced Restrictions and Conditional Access App Control are not enforced by CA directly, in these cases CA passes flags for the app to enforce the corresponding controls.
Q2: What is the difference between assigning access to applications vs conditional access policies?
In Azure AD, users can be allowed access to applications in two ways, an app can be configured to not require user assignment, hence granting access to all users (including Guest users); or by explicitly defining which groups of users should have access. This is the best way to define which users should have access to apps.
Azure AD will issue tokens to users that have been granted to an app. However, if a CA policy is in scope of the access request, even though the user is assigned access to the application, they would have to meet the controls for that specific access request in order to have a token issued. This allows organizations to have more control of when a token is issued based on the conditions of the access request, and not just application assignment alone.
You manage application access by assigning users to the specific application but may use CA policies to require additional controls depending on the different conditions of the access request.
Q3: Are policies evaluated in a specific order?
All policies are evaluated in no particular order. A policy applies when all configured conditions are satisfied. If multiple policies apply, the controls of all matching policies are enforced, which leads us to the next question.
Q4: In what order are controls applied?
Block always wins. After this, the controls are enforced in the following order:
Something to note here is that Identity Protection policies are applied before CA evaluation.
Q5: How do we determine that a device is trusted?
A trusted device is a managed device that is registered to Azure AD and is either marked as compliant by a supported MDM solution such as Intune; or is a member of an Active Directory forest on-premises. While being registered to Azure AD is a pre-requisite to being considered a managed device, it isn’t enough to make access decisions with CA.
Here is a diagram that shows how managed devices are considered trusted by CA.
Q6: How do we tell if the Client App is a Browser or a Mobile App or a Desktop Client?
We use information provided when the application was published on the Microsoft app directory. If the application was registered as a Confidential Client or the app uses security assestions markup language (SAML), we consider the client a browser. If the application was registered as a Public Client, we consider the client a Mobile or Desktop App.
Here is the oAuth 2.0 spec definition of Confidential and Public clients.
Q7: How do we know which device platform the client app is running on?
As you might already know, CA policies can be targeted to specific Device Platforms. This feature is there to provide you more flexibility at the time of configuring policies and to allow you to only enforce controls to device platforms that can satisfy them.
We determine the device platform by parsing the User Agent String, which is constructed by the client application and only exists for web protocols. There’s no User Agent String on some of the protocols that CA supports, like POP3 or SMTP. As a result, you should not rely on the User Agent String to be present or to be accurate. Most browsers have a function to set an arbitrary User Agent String for testing purposes.
Often when customers are first rolling out policies, they only target specific device platforms like iOS and Android. This can be an efficient approach, but it’s important to remember that platform detection is best effort. As an end state, you should always design your CA policies to provide full coverage of all device platforms, including what to do when the device platform cannot be matched to one of the available options in CA.
Let me give you an example. Here are 2 policies:
That's great, but what if CA is processing a request where the User Agent String is malformed, spoofed or not present? The result will be that no policy is applied, and the user will be granted access.
Here’s a way in which you can model your policies so you can catch unknown device platforms.
Coming back to the spoofed User Agent String example, by creating this policy you’re making sure that at least one control will be applied to flows where the Device Platform cannot be determined. Additionally, it gives you the ability to monitor and alert on these sign-ins and, if needed, exclude users/apps that have legitimate reasons for using a device platform not covered by CA.
Check out our previous mailbag posts!
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.