Azure Conditional Access for Chromebooks

I suspect most of you reading this article will already know this, but part of Microsoft’s Azure AD (AAD) / Office 365 Cloud directory service that you get when you pay for premium AAD is Conditional Access (CA), which can be used to allow quite sophisticated access controls for accessing Office 365 resources.

Of course, you get basic Office 365 MFA with the basic Office 365 enterprise product, and you should absolutely look into enrolling your users and turning this on straight away if that is what you have. Don’t let my talk of better MFA systems stop you implementing one of the single most effective protections for your Office 365 accounts and data possible.

Conditional Access, a very quick primer.

[caption id="attachment_919" align="alignleft" width="300"] Fig 1: Azure Conditional Access Config[/caption]

Conditional Access rules let you set various conditions (clue in the name!) on login to achieve some quite subtle changes in security profile.

For example, you can decide whether or not a device needs to be enrolled in Intune based on location, take different actions depending on the risk profile of the logon, have different logon conditions to satisfy based on whether a user is using a desktop computer or mobile device, or App vs. Browser, and so-on.

One slightly weird issue I’ve run into lately with using Azure Conditional Access to drive MFA is dealing with operating systems that Microsoft do not support directly.

For many people this is a non-issue. If you want all users to go through identical validation regardless of device type, login type, etc, you can do this with just one rule, for example, consider the basic CA rule below.

[caption id=“attachment_923” align=“aligncenter” width=“1024”] Fig 2: MFA All Devices and Users[/caption]

This is a very basic CA rule that requires all users (I excluded my test user to avoid locking myself out while writing this) accessing Office 365 from any location except trusted locations (e.g. outside the office) via the browser or modern authentication-based apps to be required to successfully complete a MFA challenge.

This is very simplistic and will catch all users on all devices. This is a reasonable pattern for a simple CA rule where you don’t need to differentiate between types of users, or types of device, or apply different rules depending on location.

But quite often, we want a bit more control than that. We want to apply different rules to different users.

Complex CA rules and Chromebooks

[caption id="attachment_926" align="alignright" width="189"] Fig 3: Sign-in risk.[/caption]

Perhaps we have a group of users who don’t need to logon from outside the office at all, or a group of especially valuable accounts whose logins we want to track more closely than others. My view on this btw, is that all logins are equally value because compromising a so-called “low value” account can often be a stepping stone to compromising other “high value” accounts by sending phishing emails to the high value users that must be safe, they’re internal, for example.

Perhaps we want to apply different login actions based on risk level, so we need different policies for different risk levels? This can be useful if we want to say that a “high risk” user login is denied, or has to pass extra checks in order to be allowed. To do this, we’d create several CA rules for different risk profiles.

Or perhaps we want to apply different rules for different devices. This is where the Chromebook issue I talk about in the title comes in to play.

Consider the pair of rules visible in the first screenshot in this article:

1. MFA Conditional Access test for Desktop - applying settings to Windows and MacOS device types.
2. MFA Conditional Access test for Mobile - applying settings to mobile device types.

To do this, I created two rules similar to the one above, but with 1 small difference.

[caption id=“attachment_928” align=“aligncenter” width=“1024”] Fig 4: MFA for mobile vs. MFA for desktop[/caption]

The mobile rule looks for Android, iOS or (for the sake of completeness) Windows Phone. The desktop rule looks for Windows or MacOS. This is great… until someone logs on with a Chromebook (or a Linux system for that matter). What policy does that fall under?

Sadly, where Microsoft don’t have explicit support for a platform, it doesn’t get tested for CA compliance under either of these rules because it isn’t a listed system, so all your nice CA rules are being subverted for the cost of a cheap Chromebook, or a cheaper or even completely free Linux ISO.

This means that devices that fall into this pattern are not being targetted by your Conditional Access rules. This means that any rules around DLP, MFA, etc. built on this pattern will not work properly with unknown devices.

Luckily this is easily fixable. You have two choices, both of which revolve around the Device Platforms Controls above. You might notice that some controls in the CA creation process have an include and exclude tab, and this includes the Device Platforms control. We can use a combination of Include and Exclude to direct  unsupported or"unknown" devices down a particular route as follows.

To Deny Logins for unsupported devices, do the following.

Create a CA rule similar to my "MFA All Users and Devices" rule earlier in the article (Fig 2).

[caption id=“attachment_932” align=“aligncenter” width=“1024”] Fig 5: CA blocking unsupported devices[/caption]

• Create a CA rule and under Device Platforms, click the Exclude tab and select all your supported Platforms. This means the rule to block access will not apply to your supported Device Platforms that you've just selected.
• Still in Device Platforms, return to the Include tab and select Any Device. Click Done.
• Select Grant under Access Controls.
• Click Block Access, then Select.
• Click Save to save your new rule. Review it carefully and when you are sure it is right, return to editing the rule and Enable the policy, then click Save again. The rule will become active straight away.

This rule will apply to all devices excluding Android, iOS, Windows and MacOS, and is set to block access to platform types not listed on the Exclude tab, which is useful if you require all supported devices to be successfully enrolled in Intune, and to block all other access.

To support MFA on Chromebooks/Linux, do the following.

Firstly, keep in mind your limitations. For example. if a device isn't able to be enrolled in Intune, you cannot expect it to work with CA rules that require Intune compliance. My assumption in this example is that we have two types of device login:

1. Desktop based, for MacOS and Windows, which does not require the device to be enrolled in Intune. (I'm including laptops and Surface tablets as "desktop" here).
2. Mobile based, for Android and iOS, which does require the device to be enrolled in Intune.

So in this example, we're classifying Chromebooks and Linux as a "desktop OS", and our CA rule for desktop devices already requires MFA for logins from desktop devices but does not require AAD join or Intune Compliance. This is a common scenario when a business wants to allow users to access their email from a personal device at home.

[caption id=“attachment_936” align=“aligncenter” width=“1024”] Fig 6: Require MFA for Mac OS, Windows and “unknown”, excluding mobile devices.[/caption]

• Edit your Desktop MFA rule, and under Device Platform, click on the Exclude tab and select Android, iOS and if you must, Windows Phone. This means that the your Desktop MFA CA rule will not target mobile devices, leaving them to be targetted by your specific Mobile Device rule.
• Still in Device Platform, return to the Include tab and select Any Device. Click Done on the Device Platforms tab.
• Click Save to update your CA rule. The change will be applied straight away.

This rule requires MFA for all devices, except the devices specified in Device Platforms / Exclude . Those excluded devices can then be used with another CA rule, as per my example of different login routes for mobile OS vs "desktop" OS.