This week is still all about conditional access. However, this week it’s not about a specific configuration. This week it’s about the conditional access policy flow. The flow that will help with determining if a conditional access policy is applicable to the user’s attempt to access a cloud app and if access will be allowed or blocked. The idea is similar to the What if tool. The big difference is that the What if tool does a technical check to see which conditional access policy is applicable and this flow can help with determining why a conditional access policy is applicable, or not. Also, almost as important, this flow will clearly show how many options are available to exclude specific users and devices. This is important to know, because if no conditional access policy is applicable, the user’s attempt to access a cloud app (which means company resources) will be allowed. The flow is shown below.
Note: The sign-in risk condition is left out of this flow, as it requires Azure AD Identity Protection. The idea for that condition would be similar to the other conditions. Also, the session controls are left out of this flow. The idea for that control should be similar to other controls, except that this control will not directly block access as it will only provide a limited experience.
The main idea of this flow is to make it very clear that there can be many reasons for a conditional access policy to not be applicable (see all the yellow ovals in the flow above). The flow goes through the following conditions and controls:
- Conditions (can be used to filter):
- Users and groups: Required condition, which is captured in this flow with “Is the policy assigned to the user?”. This should be the result of the included and excluded user groups;
- Cloud apps: Required condition, which is captured in this flow with “Is the policy assigned to the cloud app?”. This should be the result of the included and excluded cloud apps;
- Sign-in risk: Condition not part of this flow (see note);
- Device platforms: Optional condition (“Is the device platform condition enabled?”), which is captured in this flow with “Does the policy include the device platform?”. This should be the result of the included and excluded device platforms;
- Locations: Optional condition (“Is the device locations condition enabled?”), which is captured in this flow with “Does the policy include the location?”. This should be the result of the included and excluded locations;
- Client apps: Optional condition (“Is the client app condition enabled?”), which is captured in this flow with “Does the policy include the client app?”. This should be the result of the included and excluded client apps;
- Device state: Optional condition (“Is the device state condition enabled?”), which is captured in this flow with “Does the policy include the device state?”. This should be the result of the included and excluded device states;
- Controls (can be used to set an action)
- Grant: Optional control that can be used to block or grant access, which is captured in this flow with “Does the policy grant access?”, and when used to grant access it must set requirements, which is captured in this flow with “Does the device and/or app meet the requirements?”.
- Session: Control not part of this flow;
The main message of this flow is awareness. Be aware of which users and devices are excluded from the conditional access policy. Those users and devices should be assigned to separate conditional access policies, to make sure that the conditional access configuration creates a secure environment without any (unknown) backdoors.
For more information about conditional access, please refer to the docs that are available here: https://docs.microsoft.com/en-us/intune/conditional-access
7 thoughts on “The conditional access policy flow”
The whatif tool is great and cool!
Your flow is a welcome addition, thanks sir.
Thank you, RKast!
Thank you for your great articles, really helpfull!
We are now using Conditional access to force users on MFA and that works great.
There is one problem however. The policy is set up to kick in for a particular group, for all Cloud apps and for all locations. I see however that some users did not register for MFA yet, although they should have been triggered to do so. Problem could be partially that these users have a local Exchange mailbox (still migrating some of them), so they don’t get MFA for Outlook, but they do use Microsoft Teams (installed on a WIndows Server 2016 Remote Desktop Server using the machine wide installer). Teams works great, but these users haven’t had a single prompt when using Teams.
Do you know why that is? Is there some sort of token refresh? I thought users using Teams would get an MFA prompt….
Other users in the same group using Outlook for their Office 365 mailbox all get MFA…
I think this should provide you with some answers: https://docs.microsoft.com/en-us/microsoftteams/sign-in-teams#how-modern-authentication-works
Thank you for your reply.
So if I understand it correct, this must be because they are already signed on to their Office applications, probably already before we enabled MFA for them (“If users have already signed in to Windows or to other Office apps with their work or school account, when they start Teams they’re taken straight to the app. There’s no need for them to enter their credentials.”)?
And they probably won’t see an MFA prompt as long as there Refresh token hasn’t expired or been revoked? (“Refresh tokens are valid for 90 days, and with continuous use, they can be valid until revoked.
Refresh tokens can be invalidated by several events such as :
User’s password has changed since the refresh token was issued.”)
Our users are forced to change their password every 30 days, so that means they will not get the MFA prompt until they change their password?
That would also be my understanding. You could look at temporarily adjusting the sign-in frequency via Session control in CA.