Updated 16th of February 2021.
Friday morning and I’m on the train heading for our beautiful capitol of Sweden. Last workday before a well deserved weekend I think.
In my last post I presented my Conditional Access Policy Design Baseline which demonstrates a good approach and a starting point when building a Conditional Access implementation.
I get a lot of questions on how Conditional Access policies are applied and what happens when multiple policies overlap and conflict with each other. So here we go…
Conditions vs Access Controls
First of all, it’s important to understand the difference between Conditions and Access Controls.
The Conditions are the ones checked when the authentication occurs and if the conditions are true the policy will match. Access Controls are the required things that must be true or performed by the user and the device after the policy is matched and before the user is let in to the cloud app.
I sometimes see people trying to use a Access Control like Require Compliant Device as a Condition but it’s not the same thing. It doesn’t work like that.
Conditions:
Access Controls:
In What Order Are Conditional Access Policies Applied?
CA policies aren’t applied in any particular order. All matching policys apply and the resulting access controls required by the policies will be merged!
Grant vs Block
If both grant and block policies match, block will always win. No exceptions!
How Multiple Access Controls Are Handled
If multiple policies match and they have different Access Controls like Require MFA, Require Compliant Device or Require Azure AD Joined, the requirements will actually be merged and all the access controls from all matching policies have to be fulfilled.
The same is true for Session Controls from different policies.
We use the Conditional Access What If-tool in the following examples to demonstrate what happens.
In the first example we connect from an Azure AD joined Windows device. We also connects from the users office, which is a trusted location and because of that we match two of our defined CA policies. The first policy has two access controls which requires us to use an approved client app, and to accept the terms of use. The second policy requires us to use a domain joined device. When all access controls from both policies are met the user will be let in.
In this second example we connects from the Internet instead (an untrusted IP address). Because of that, a third policy matches according to our design. This third policy requires the user to authenticate with MFA if untrusted location is true.
In reality all three of these policies will be merged into one when it comes to access controls, and the user have to use an approved client app, accept the terms of use, use a domain joined device and authenticate with MFA. All of them!
Because we configure our policies to match in different scenarios like this, we can simplify our Conditional Access design by leveraging the merging process that occurs when multiple policies match. Again, see my policy design baseline for a demonstration of how this is done.
Policy Details in the Sign-ins Log
Finally, if you are troubleshooting Conditional Access policy matching, you can use the Policy details view in the Sign-ins log. Click a sign-in, click the Conditional Access tab, and then a policy. You will now see details of how the policy was evaluated and which conditional were met, and what access controls that were applied.
I hope this clear things up a bit and please follow me here, on Twitter and on LinkedIn.
Daniel Chronlund Cloud Security Blog 
You have Other Clients and EAS checked and blocked to block unsupported clients. I thought MS did not support combining EAS with any other apps or conditions. Please clarify.
Hi Carolyn and thanks for the comment! The block unsupported clients policy is just blocking the unsupported protocols when authenticating to Azure AD. You can run it through the What-If tool in CA as a proof of concept. I’m not sure why this design would be unsupported by Microsoft. Please share the source for this if there is one.
Thank your for your post! We have a policy that requires MFA for all users. We want to have a policy for one site collection and for one users that does not require MFA. Given that ”block” always win, then this scenario would not be possible, would it?
Glad you like it! You can exclude trusted locations and certain IP address ranges from your block policies. However, in a zero trust strategy you should not think of networks as safe and unsafe. Treat everything as the Internet and let your users safe their MFA verifications on trusted devices instead.
Daniel this info was useful to me but I’m still left with some questions. You say Access Controls (Grant and Session) are summed but what if you have multiple policies with the same Session control. For example, let’s say sing-in frequency in one is set to 1 day and another is set to 7 days? How do you control which wins? I’m struggling to create policies where if a user is on a trusted device in a physicals office they get few MFA prompts than if they take that trusted device remote vs if they use a untrusted device.
Than you Benjamin! Regarding Session Controls, if you design your policies in such a way that multiple match, then the last one evaluated will apply. I would guess that this depens on the order which the policies were created. This is just an issue with Session controls, not Access controls. I would try to avoid any conflicting Session policies if possible.
Hi Daniel. Thank you for the article – very informative. I have been struggling with this query for quite a while and wondering if you can shed some light.
I have a CA policy where the Grant Control is ‘Require MFA’ OR ‘Require Hybrid Joined Device’
When the user (MFA on user account is enabled on Azure) is signing in to the Hybrid joined device, user is still being prompted for MFA. I can’t understand why teh user is being prompted even though he satisfied the ‘Require Hybrid Joined Device’ control.
Is there a way where the user is not prompted for the MFA (Trusted IPs is not an option here)
Thanks in advance
Thanks! Are you using a supported browser (Edge or Chrome with addon), not using private browsing? I would investigate the sign-ins logs to see what happens.
Hi Daniel.We use session control for 10 hours. When a user has logged in after being offline for more then 10 hours the 2-factor is triggered. But the user starts two cloud application at the same time (teams and OneDrive, both ask for a 2-factor by App or SMS. When the user completed the first, the second application is still waiting for the completion of the 2-factor. It does not combine both request to only one 2-factor request. Is there normal, are there any solutions to would resolve the issue that users get 2-5 2-factor request within seconds?
That is normal, but not very convenient. There is little we can do about this behavior. Why do you set it to 10 hours? 90 days is default and I usually set it to 30 days.
What if a user is simultaneous a member of a group belonging to the exclude and member of a group belonging to include?
Exclude wins.