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.
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 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.
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.