Just Dropped In (To See What Condition My Conditional Access Rule Was In): Part 1 – Block access for unknown or unsupported device platform

This blog is a series of guides which aim to run through the Conditional Access (CA) templates which Microsoft has published under the title Conditional Access templates (Preview). The templates get you up and running with CA but what is the impact of turning on the policies on devices, how can you adjust the templates to work in your environment and what does the end user experience look like on the endpoint?

The series is co-written by Paul Winstanley, a six times Enterprise Mobility MVP based in the UK and Mike Marable, an active member of the MEM community, based in the US.

Conditional Access Overview

Conditional Access rules are a type of if-then statement. If a user wishes to access something then they must complete an action to be able to access. Conditional Access rules get enforced once first-factor authentication has been completed.

Conditional Access use signals to make a decision and then enforce the decision to allow or deny access as per this diagram from the Microsoft documentation.

Microsoft introduced the Conditional Access templates at the end of 2021 as convenient method to deploy policies. These 15 templates cover five different deployment scenarios:

• Secure foundation
• Zero trust
• Remote work
• Protect administrators
• Emerging Threats

This series will cover the 15 templates in detail.

• Part 1 – Block access for unknown or unsupported device platform
• Part 2 – Require multifactor authentication for all users
• Part 3 – Require multifactor authentication for admins
• Part 4 – Require multifactor authentication for guests
• Part 5 – Require multifactor authentication for Azure Management
• Part 6 – Require Password Change for High Risk Users

Block access for unknown or unsupported device platform

This Conditional Access policy allows the definition of the operating systems which are allowed for your end users when they access Cloud Apps, use User Actions or Authentication context..

It is created in the Azure Portal under the Conditional Access\Policies blade, or in the Microsoft Endpoint Manager console under Devices\Conditional Access.

Click the New policy from template (preview) link.

The policy is available in the Zero trust and Remote work scenarios, or you can click All to display all the templates.

You can click the View option to view the default settings for the policy.

These are the following settings for the Block access for unknown or unsupported device platform template.

To break down the policy:

Users:	All Users are Included – The current user creating the policy will be excluded
Apps:	All Cloud Apps are included
Device Platforms:	Block all but exclude Android, iOS, Windows, macOS, Linux and Windows Phone
Access Control:	Block Access

With the default policy in place, all platforms will actually be allowed as they are excluded from the rule. Therefore to block a platform, the exclusion for that OS needs to be removed (unchecked) from the policy. For example, in the screenshot below we are going to block the Windows platform.

When the policy is created it is set as Report-Only. This is good practice, as the impact of enabling the policy can be assessed before doing so.

For our testing, we have created a group called CA Test User Group and added our test users to it. In the policy, under Users, we have chosen Select users and groups and picked the group to filter for. The user creating the policy via the template is excluded by default, but it is recommended to ensure you have a break glass account which can be used to access should the rule cause problems – e.g. if you block access to all platforms without excluding anyone!

When you are ready to move from the Report-Only mode, switch the toggle to On.

The state of the policy will be reflected in the console.

Impact of enabling the policy

The following tests were undertaken on each device platform by including them in the Device Platform setting, the end result expected would be to block users from accessing Cloud Apps via that OS. We tested the policy by authenticating into office.com or the windows365.microsoft.com portals.

Windows

With Windows included in the Block access for unknown or unsupported device platform policy, a targeted user authenticating into office.com will be prompted to authenticate and then receive the following message.

When clicking the More details link, they receive an error code 53003. Also note the App name and Request Id. These will become relevant when we check the sign in logs later.

macOS

With macOS included in the Block access for unknown or unsupported device platform policy, a targeted user authenticating into office.com will be prompted to authenticate and then receive the following message.

The More details link gives the following information.

Android

With Android included in the Block access for unknown or unsupported device platform policy, a targeted user authenticating into office.com will be prompted to authenticate and then receive the following message.

The More details link gives the following information.

iOS

With iOS included in the Block access for unknown or unsupported device platform policy, a targeted user authenticating into office.com will be prompted to authenticate and then receive the following message.

The More details link gives the following information.

Linux

With Linux included in the Block access for unknown or unsupported device platform policy, a targeted user authenticating into office.com will be prompted to authenticate and then receive the following message.

The More details link gives the following information.

Checking the Sign-in Logs

When it comes to investigating Conditional Access policies, we refer to the Sign-in logs in Azure Active Directory. You can check the sign-ins against an individual user by going into the the Azure Active Directory blade and selecting Users. Search for the user and select, then click the Sign-in logs menu entry.

As you can see, our user Neil has some sign in failures in the Status column, and if you take a look at the Application column you can see entries for OfficeHome and Window 365 Portal. Look back at the screenshots from the various OS’s and you can see that these match.

Let’s drill into one of the events. The Sign-in error code matches the 53003 from our screenshots. The Request ID in this image relates to our Android sign in.

Note the Failure reason, Access has been blocked by Conditional Access policies. The access policy does not allow token issuance.

Clicking on the Device Info link confirms this is our Android device and that we were attempting the authentication on the Edge browser.

The Conditional Access information shows us details information on the failure. This verifies that our policy CABLOG01 – Block access for unknown or unsupported device platform has kicked in and the Grant Control of Block has done its job.

Allowing through the Block

Even though you are blocking access with this rule, you can use the power of Conditional Access to create exemptions. Tweaking the rule slightly will give you that ability.

For example, let’s say you are blocking access on All Cloud Apps but you want to allow users to access Windows 365. This could be helpful in a BYOD unmanaged device scenario where you want to ensure users are using a secure endpoint controlled by you.

In this scenario, you would create an exclusion in the Cloud Apps or actions section. Click the Exclude link under Cloud Apps.

Under Select excluded cloud apps click the None link and search for the Window 365 app and add it into the exclusion.

Save the changes to the policy.

Now, Neil is able to sign into the windows365.microsoft.com portal, and if he is assigned any Cloud PC’s, fire those up to access corporate resources from any browser.

As you can see from the sign-in logs, the authentication to Windows 365 Portal has a Status of Success.

The Conditional Access columns states Not Applied, however. Why is that, surely the rule has applied?

Actually, since the app they used was excluded, they are exempt from the rule and therefore it reports as Not Applied. Check the Result column for confirmation of that when drilling into the sign-in event.

Further reading

Take a look at the following Microsoft documentation if you want to read some more on Conditional Access.

• What is Conditional Access? – https://learn.microsoft.com/en-us/azure/active-directory/conditional-access/overview

• Conditional Access templates (Preview) – https://learn.microsoft.com/en-us/azure/active-directory/conditional-access/concept-conditional-access-policy-common

• Common Conditional Access policy: Block access for unknown or unsupported device platform – https://learn.microsoft.com/en-us/azure/active-directory/conditional-access/howto-policy-unknown-unsupported-device

Look out for the next part of the blog.

Thanks for John Harrop for the time and patience for testing these rules out prior to the blog series.