The conditional access policy flow

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.

TheConditionalAccessFlow

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.

More information

For more information about conditional access, please refer to the docs that are available here: https://docs.microsoft.com/en-us/intune/conditional-access

2 thoughts on “The conditional access policy flow”

Leave a Comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.