Conditional Access demystified, part 3: How does Conditional Access work?

Now available: May 2020 update of the Conditional Access Demystified Whitepaper, Workflow cheat sheet, Implementation workflow and Documentation spreadsheet

This article is part 3 of a series, for which the following articles are available:

Conditional Access demystified, part 1: Introduction
Conditional Access demystified, part 2: What is Conditional Access?
Conditional Access demystified, part 4: Designing a Conditional Access strategy
Conditional Access demystified, part 5: Implementing Conditional Access

Conditional Access demystified, part 6: Troubleshooting Conditional Access
Conditional Access demystified, part 7: Modifying Conditional Access to suit your special needs
Conditional Access demystified, part 8: Resources and further references

Microsoft explains Conditional Access in the following way. Conditional Access consists of access scenario’s called Conditional Access policies. An Conditional Access policy follows the following pattern:

“When this happens” defines the reason for triggering your policy. This reason is characterized by a group of conditions that have been satisfied. With “Then do this” you define how users can access your cloud apps.

Technically this is translated to Conditions (When this happens) and Access controls (Then do this)

Microsoft provides some already configured policies for you to use, called “Baseline policies”, these policies protect against many common task, at time of writing the following baseline policies exist:

• Require MFA for admins
• End user protection (preview)
• Block legacy authentication (preview)
• Require MFA for service management (preview)

Customers can also create their own “custom” Conditional Access policies, the figure below shows how a new Conditional Access policy are grouped into sections. The Conditions (When this happens) are grouped as assignments, and Access controls (Then do this) are grouped as Access controls.

The Microsoft description covers Conditional Access from a high-level overview, practically Conditional Access is a little more complex as explained in the following flowchart or cheat sheet. You can download this cheat sheet as PDF from the following location: https://gallery.technet.microsoft.com/Conditional-Access-94371e5a

Based on the Conditional Access Workflow Cheat sheet, we can translate the conditional access to the following formula:

Access to <provided> Clouds Apps except <provided> Cloud apps  by <provided> users and/or <provided> groups except <provided> users and/or <provided> groups using <provided> Sign-in Risk and/or <provided> Device Platform except <provided> Device Platform from <provided> Location except <provided> Location using <provided> Client apps with <provided> device state, except <provided> device state  Grants, Grants but <provided requirement must be fulfilled> or Blocks access.

When multiple Conditional Access policies apply for a user when accessing a cloud app, all of the policies must grant access before the user can access the cloud app.

Some important rules are:

All policies are enforced in two phases:

In the first phase, all policies are evaluated and all access controls that aren’t satisfied are collected.

In the second phase, you are prompted to satisfy the requirements you haven’t met.

If one of the policies blocks access, you are blocked and not prompted to satisfy other policy controls. If none of the policies blocks you, you are prompted to satisfy other policy controls in the following order:

Note: Microsoft recently added a new option called “Require app protection policy (preview)” to this list. Unfortunately the documentation doesn’t describe in which order this new option is evaluated, but most probably it will be 4.

External MFA providers and terms of use come next. All assignments are logically ANDed. If you have more than one assignment configured, all assignments must be satisfied to trigger a policy.

Block access trumps all other configuration settings

A Conditional Access policy is built from the following components:

General

The conditional access policy must have a unique name, use a name which gives an idea of what the policy is doing under what circumstances. Policies can also be created but not “enabled”, this can either be while testing the policy or in a situation that the policy must (temporary) be disabled.

Assignments (a.k.a. conditions)

Assignments define the “When this happens” part of the Conditional Access rule and consists of the following conditions.

Users and Groups

In the users and groups condition you can specify for which users or groups the policy is applicable. You can either include and optionally exclude users and groups from the condition. It’s also possible to include or exclude “guest users” or Azure Active Directory roles, like Global Administrator. Directory roles are especially interesting when using Azure Privileged Identity Management (PIM) where the Global Administrator role is assigned “temporarily” to a user instead of permanent. You can for example have a more restricting Conditional Access policy applied while the user has Global Administrator rights.

Cloud apps or actions

Microsoft defines a cloud app as a website, service or endpoint protected by Azure AD Application Proxy. This is partially true since many Microsoft SaaS based services, which are not protected by Azure AD application proxy, or at least Azure AD application proxy as we know it are in scope as well. The supported cloud apps can be found in the following list: https://docs.microsoft.com/en-us/azure/active-directory/conditional-access/technical-reference#cloud-apps-assignments. Some of the cloud apps are Office 365 Exchange Online, Office 365 SharePoint Online and Microsoft Azure Management (the Azure Portal).

Actions are relatively new, and refer task a user can perform. For know the first action available is Register security information (preview), which requires the user to register security information needed to start using MFA.  More information on that here: https://docs.microsoft.com/en-us/azure/active-directory/authentication/howto-registration-mfa-sspr-combined. Actions are a really nice addition since they can really help to make sure that prerequisites are met, before enabling or applying other conditional access policies.

Sign-in Risk (additional license needed)

If you have licensed Azure Active Directory Identity Protection you can use this condition as a criteria to determine to which situation the conditional access policy will apply. Azure Active Directory Identity Protection will generate a so called “sign-in risk level” and based on the level (High, Medium, Low and No Risk) you can make the conditional access policy applicable. More information about this scenario here: https://docs.microsoft.com/en-us/azure/active-directory/conditional-access/app-sign-in-risk

Device Platforms

In the device platform condition you can specify for which device platforms the policy is applicable. You can either include and optionally exclude device platforms from the condition. The following device platforms are available to select:

• Android
• iOS
• Windows Phone
• Windows
• macOS

You can also include All platforms, where you also include the platforms not in the list above (unsupported platforms, like for example Linux) and then exclude a certain supported platform from the list above. You can use the device platform condition in the case that you want to restrict access to cloud apps from managed devices, but also if you need to create several conditional access policies when you want to implement a feature which is not supported on all device platforms.

Note: The device platform feature in Conditional Access is depending on user agent strings sent by the application or the web browser, which can easily be spoofed. This is something you must keep in mind when designing your Conditional Access policies. See this article from Nicola Suter for more excellent information: https://tech.nicolonsky.ch/bypassing-conditional-access-device-platform-policies/

Device state

When using the device state condition, you can exclude devices marked as compliant and devices which are Hybrid Azure AD joined (meaning Active Directory joined, and Azure AD registered) from the policy. Some scenario’s are that you don’t want the policy to apply to domain joined/azure ad registered devices, or that the managed device must report itself as compliant and if not the policy will apply (block access for example until the device is compliant again)

Locations

With locations you can specify conditions based on the network location the user is coming from, this is always the public IP address which is used on the internet and you cannot therefore use internal IP addresses to distinct in CA policies. You can either include or exclude locations from the conditional access policy. Some use cases are that you want to restrict accessing the cloud app only from known locations (for example access to the Azure portal) or that you want to block access to a cloud app from a country or region for which you are sure your users will never use the cloud app service. 

Client apps

Here you can specify the apps on the client for which the condition is applicable. This can be:

• Browser apps – apps accessed by a web browser on the client
• Apps using Modern authentication – these are apps which can use “modern”, meaning secure authentication mechanisms
• Exchange Active Sync clients – apps which use Active Sync to connect to the cloud app – this option can only be selected if Exchange Online only is selected in the Cloud Apps selection.
• Other clients – apps which are not use “modern” authentication mechanisms, like IMAP, POP, SMTP etc… (for example Outlook 2010)

Access Controls

Access Controls define the “then do this” part of the conditional access policy. Based on the conditions the policy can:

• Block access to the cloud app
• Grant access to the cloud app
• Grant access to the cloud app but require an additional control (like MFA, must be compliant, Azure AD joined)
• Grant access to the cloud app but require all of the  selected additional controls
• Grant access to the cloud app but require one of the selected additional controls

The access controls available are:

Grant

• Require multi-factor authentication (MFA)
  • Users are required to provide an extra authentication before access is granted
• Require device to be marked as compliant
  • Device from which the user is accessing the cloud app must be managed and also compliant
• Require Hybrid Azure AD joined device
  • Device is Hybrid Azure AD joined, meaning member of AD and registred in Azure AD
• Require approved client app
  • Approved client apps are apps which can be managed using MAM functionality in Intune, for a list of supported apps see: https://docs.microsoft.com/en-us/azure/active-directory/conditional-access/technical-reference#approved-client-app-requirement
• Require app protection policy
  • Here you can specify that besides the fact that the application must capable of being managed using MAM, that also app protection policies must have been applied.

Session Controls

Session controls are also part of the Access controls and can be applied after the session is granted, they allow for a limited experience within a cloud app and have the following options:

• Use app enforced restrictions
  • When this option is enabled, Conditional Access passes the device information to the cloud app, for now only SharePoint Online (SPO) and Exchange Online (EXO). In the cloud app a limited or full experience is offered depending on the device information.
• Use Conditional Access App Control
  • Routes the user to Microsoft Cloud App Security, which protects data by applying access and session controls. Some examples are: Prevent data exfiltration, protect on download, prevent upload of unlabeled files and monitor user session for compliance. The options available here are: Monitor only (preview), Block downloads (preview) and Use custom policy..
• Sign-in frequency (preview)
  • With sign-in frequency you can specify the time period before a user is asked to sign in again when attempting to access a resource. You can either choose Hours (between 1 and 23) or days (between 1 and 365)
• Persistent browser session (preview)
  • A persistent browser session allows users to remain signed in after closing and reopening their browser window. With this control, which can only be set when all cloud apps are selected you can choose between Always persistent or Never persistent. Never persistent requires the user to login again after the browser window is closed.

In the next article (part 4) I’m going to explain how to design a Conditional Access strategy.