This post is part of the overall MS-500 Exam Study Guide. Links to each topic as they are posted can be found here.

This post will cover the following exam topics listed under the “Implement Conditional Access” section:

• Plan for compliance and conditional access policies
• Configure and manage device compliance for endpoint security
• Implement and manage conditional access

Plan for Compliance and Conditional Access Policies

We’ve touched on the configuration of Conditional Access in this series while looking at implementing MFA however there are a lot more capabilities of Conditional Access than just implementing MFA. To recap, Conditional Access in Azure AD allows us to define a set of rules that will trigger based on “Signals” from a given authentication request. When the authentication context meets the criteria we have outlined, we can then trigger specific actions, shaping the authentication process for our users.

To understand and plan Conditional Access Policies appropriately, let’s outline the options available to us when configuring our policies, we can then apply some real world examples to provide context:

Assignments

The following criteria specify which signals should be present for our policy to trigger

• Users and Groups – We specify which users/groups we want to target with our policy. We have the option to both include and exclude selected users/groups.
  • All Users – All users in our directory
  • All guest and external users – Applies to all guest users who access our resources
  • Directory roles – Applies to accounts with specific roles assigned, e.g. Global Admins
  • Users and groups – Applies to selected users and groups
• Cloud apps or actions – We include or exclude specific cloud apps or actions to target
  • Cloud apps – Select apps in our directory that will trigger the policy, e.g. Exchange Online or SharePoint Online
  • User actions – The only option available here is to trigger when a user registers security information i.e. MFA registration
• Conditions – We specify the signals to detect during an authentication request which will trigger the policy
  • User risk – Azure AD will assess the risk level associated with a particular user based on factors such as potential credential breach and assign a “high”, “Medium” or “Low” risk level. We can specify a risk level as a signal
  • Sign-in risk – Similar to User risk, sign in risk associates a risk level to the particular sign-in request, this is based on factors such as source IP address, impossible travel times etc. This risk level can be used as a signal for our policy
  • Device platforms – We can use the platform of the device being used as a signal to trigger our policy. We can choose from Android, iOS, Windows Phone, Windows or MacOS
  • Locations – As we did when we were configuring MFA policies, we can configure known locations based on IP Addresses or Geographical regions and use these locations as signals to include or exclude in our policy
  • Client Apps – We can detect the client app that our user is connecting with and use that as a signal. This is split into two types of apps, apps that use Modern Authentication and apps that don’t. Our options are:
    • Modern Authentication: “Browser” or “Mobile and Desktop apps”
    • Legacy Authentication: “Exchange ActiveSync” or “Other”
  • Device State – We have the option to exclude MEM Compliance or Hybrid Azure AD Joined Devices from our policy

Access Controls

Based on the signals above, we can take the following actions:

• Grant – Control how users are given access when they meet our signal criteria
  • Block access – Reject all authentication requests that meet our defined signals
  • Grant Access – Grant access to all authentication requests that meet our defined signals but required one or all of the following:
    • Require MFA – Require the user to respond to an MFA Prompt
    • Require Device to be marked as compliant – Require MEM to report the device as compliant with any assigned policies
    • Require Hybrid Azure AD joined device – Require that the device is Hybrid Azure AD Joined
    • Require an approved client app – Require that the user is using one of the approved client apps to connect. This is useful when combined with Mobile Application Management (MAM)
    • Require app protection policy – Require the app to have an assigned MAM policy
    • Require Password Change (Preview) – This requires that the user performs the SSPR process. this is very useful when combined with high-risk user sign-ins as it inherently requires MFA
  • From the above Grant controls, we can select to require all of our selected controls or just meet one
• Session – Control how the users session is managed once they are signed in
  • Use app enforced restrictions – Leverage the app restrictions from Exchange Online and SharePoint to provide limited access to data such as blocking download
  • Use Conditional Access App Control – Proxies sessions through Microsoft Cloud App Security (MCAS) to apply policies which have been defined there. We will deep dive into MCAS in a later post
  • Sign-in Frequency – Define how frequently a user is asked to reauthenticate to Azure AD
  • Persistent browser session – Define if authentication tokens should remain active even after a browser is closed. This is defined by default by the “Keep me signed-in” option however we can block or enforce this behaviour through this option

Given all the above controls, we can be very granular with our policies. We will run through some scenarios at the end of the post but for now, we’ll look into defining our Device Compliance for use with Conditional Access.

Configure and Manage Device Compliance for Endpoint Security

To inform Conditional Access of Device Compliance, we need to first define our compliance policies in Microsoft Endpoint Manager (Intune in this case however with co-management configured, compliance data from SCCM can be used – that’s another topic).

Device compliance policies require a minimum of an Azure AD registered device. We can create and target compliance policies from the Microsoft Endpoint Manager Admin Portal under the “Devices” -> “Compliance Policies” page. Here we will create a basic compliance policy for Windows 10 devices. Select “Create Policy” and choose “Windows 10 and later” as the platform.

Next, give it a name and description.

We will require that devices must have Microsoft Defender active, up to date and with Real-time protection enabled.

If this requirement isn’t met, we will mark the device as non-compliant immediately.

We will apply our policy to all users in our tenant and finish creating the policy.

With our policy configured and applied, we can see that one device has been assessed and is compliant – cool.

For the purpose of our testing, I’m going to disable the Windows Defender real-time protection on our device. This will move the device to non-compliant so we can test our policies.

Now we can jump over to our Conditional Access Settings and start testing our policies!

Implement and Manage Conditional Access

We’ve detailed the options and process for implementing and managing Conditional Access already so for this section, let’s jump straight to the fun stuff and configure some policies.

Scenario 1: Device Compliance

The first scenario we will look at is a straightforward one: We want to block all non-compliant devices for all users from accessing SharePoint Online.

We’ve already defined our basic Compliance policy so let’s create a new Conditional Access Policy. We can give it a name of “CA01 – Require Device Compliance for SPO”. In “Users and Groups” we’ll select “All Users”.

To be safe, let’s exclude our admin account from the policy for now.

Next, we define SharePoint Online as our cloud app. Keep in mind this affects other apps which use SharePoint storage such as Teams.

Finally, we can set our Grant control to Grant Access and “Require device to be marked as compliant”

Make sure to change the enable setting to “on” from “Report-Only” for testing and then hit create. In a real-world scenario, I strongly recommend using report-only mode first.

Now we can test authentication. On our test machine, we can log in to https://portal.office.com – so far so good.

Now let’s open up SharePoint Online.

We are blocked! This is because our device in no longer compliant since we disabled Real-time protection in Microsoft Defender. A quick check of the MEM portal shows us the device as non-compliant:

We can also check the sign-in logs for the failure and check the details.

If we re-enable real time protection and wait for MEM to sync with the device, we can see it comes back as compliant. Issue resolved.

Scenario 2: Require MFA for Office 365 Apps for All Users Except from Trusted Locations

Looking at another common scenario, we want to enable MFA for All Users when they access Office 365 apps from anywhere except our trusted locations.

First, let’s give our policy a name “CA02 – Require MFA for Office 365 Apps for All Users Except from Trusted Locations” and assign to all users. At this point we should also exclude a “Break Glass” admin account, in the event of an MFA outage we’ll need top access the tenant to get it up and running.

For our cloud Apps, we’ll select “Office 365”.

For our Grant controls, we are requiring MFA.

Finally switch the policy on and create.

No if we log in as a user to https://portal.office.com we no longer get straight in. We are pompted for MFA to get access to resources. Great!

We enter the code and we get in as normal.

Summary

We’ve gone through a lot in this post, from Conditional Access, to Device Compliance and even how they can work together to secure access. We will be revisiting Conditional Access quite a lot in the Exam Guide as it is one of the most powerful tools available to us to secure our user identities. For further reading on these topics, there are some good links below to Microsofts documentation

Common Conditional Access policies – Azure Active Directory | Microsoft Docs

Users and groups in Conditional Access policy – Azure Active Directory | Microsoft Docs

Cloud apps or actions in Conditional Access policy – Azure Active Directory | Microsoft Docs

Conditions in Conditional Access policy – Azure Active Directory | Microsoft Docs