This article is about a subject I covered before in my blogpost titled: “Understanding and governing reauthentication settings in Azure Active Directory“. The reason I’m doing a more specific article on the subject is because I see a lot of issues when it comes to browser configuration which must be solved if you want to implement Conditional Access and use compliance as a way to grant access the environment.

Even though you are working in the browser on a compliant device, doesn’t necessarily mean that Azure AD can detect that. Therefore you must make sure that your browsers are configured correctly before you implement the Conditional Access policy. For an overview of my recommended set of Conditional Access policies see: Conditional Access demystified: My recommended default set of policies

Some examples I often encounter: End user is working on a compliant device, but cannot download or print files when using the web interface to connect to SharePoint online, this is caused by the App Enforced Restrictions policy being active (see: Limit Access to Outlook Web Access, SharePoint Online and OneDrive using Conditional Access App Enforced Restrictions). Or, MCAS blocks the download of a file, even though the user is working on a compliant device. (see: Extending Conditional Access to Microsoft Cloud App Security using Conditional Access App Control)

Browser support

This all has to do with browser support and configuration, below is an overview of the requirements and what is, and what’s not supported. Currently Microsoft supports the following browsers:

Sign-in Logging

When users are using a non-supported configuration, this might reflect as followed in the Azure AD sign-in logging. As you can see the Conditional Access policy requires a compliant device before access to the resource can be given. And in this case, our test user Ferry was working on a compliant device (you have to take my word for it).

Mozilla FireFox

Mozilla Firefox isn’t a supported browser when it comes to Conditional Access. If you configure a conditional access policy enforcing App Enforced Restrictions for example, you will experience these restrictions even when working on a compliant device. Keep in mind that there are also other browsers who use the Mozilla engine, like Tor Browser, Waterfox, and SeaMonkey to name a few. All these browsers will not work in this scenario.

Update October 2021: Mozilla FireFox is now supported, read the article below for more information

Using Mozilla Firefox as a browser when using Azure AD Conditional Access on your Modern Workplace

Google Chrome

In order for the Google Chrome browser to support the device authentication you must deploy the Windows 10 accounts extension in the Chrome browser to your devices. You’ll need this extension if you want to use the device compliancy within your Conditional Access policies.

Deploying extensions for Google Chrome using Microsoft Endpoint Manager

You can configure the Google Chrome browser running on a Intune/MEM managed Windows 10 device by using a Configuration Profile with a custom profile type.

In order for this to work, we first need to download the Google Chrome Bundle. Within that bundle you can find a folder called ADMX. From that folder you’ll need the chrome.admx file. Within the ADMX file we will use the ExtensionInstallForceList parameter to define the extensions we want to have installed.

Secondly we must determine the unique identifiers for the extension(s) we want to install. You can determine this by browsing to the chrome web store. From the chrome web store we need the Windows 10 Accounts extension, which at time of writing has the following id:”ppnbnpeolgkicgegkbkbjmhlideopiji” make sure that if you are configuring this yourself to doublecheck whether the id still matches.

After downloading the ADMX file and figuring out which extensions we want to install by their ID in the chrome web store we can define our Configuration Policy.

First make sure that the custom policy ingests the ADMX file, use the following OMA-URI settings to configure this:

Name: Chrome ADMX Ingestion (can be any name, but make it easy to understand what it does)

Description: <Your description if you prefer>

OMA-URI: ./Device/Vendor/MSFT/Policy/ConfigOperations/ADMXInstall/Chrome/Policy/ChromeAdmx

Data type: String

Value: Copy/Paste here the contents of the ADMX file.

Secondly we can define the setting we want to make as defined in the ingested ADMX file. Be very careful here.

Name: ExtensionInstallForcelist (can be any name, but make it easy to understand what it does)

Description: <Your description if you prefer>

OMA-URI: ./Device/Vendor/MSFT/Policy/Config/Chrome~Policy~googlechrome~Extensions/ExtensionInstallForcelist

Data type: String

Value: <enabled/> <data id=”ExtensionInstallForcelistDesc” value=”1&#xF000;ppnbnpeolgkicgegkbkbjmhlideopiji;https://clients2.google.com/service/update2/crx&#xF000;2&#xF000;bkbeeeffjjeopflfhgeknacdieedcoml;https://clients2.google.com/service/update2/crx”/>

In the example above I also install another extension (The Microsoft Defender Browser Protection) as you can see the value must be carefully composed.

First of all, the ExtensionInstallForceList will eventually end up as a REG_MULTISZ registry string. Which means that each entry must be separated by the Unicode character 0xF000 (or &#xF000; when encoded). You can also see that the URL https://clients2.google.com/service/update2/crx is being used. That URL is needed in order for the browser to determine the download path once its ready to download the extension. Each extension is also numbered, so the Windows 10 Accounts extension is number 1 and the Microsoft Defender Browser Protection extension is number 2. If you want to add more use 3, 4, etc…

Once configured assign the policy to a group and you verify whether the necessary extensions are installed within the Google Chrome browser.

Microsoft Edge

Microsoft Edge obviously supports device authentication, but whether this is being used is depending on the profile you are signed into. When you’re signed into a Microsoft Edge profile with enterprise Azure AD credentials, Microsoft Edge allows seamless access to enterprise cloud resources protected using Conditional Access. On a compliant device, the identity accessing the resource should match the identity on the profile. See: Accessing Conditional Access protected resources in Microsoft Edge for more information.

If you want to configure this sign-in for your devices you can use two settings using a Configuration Profile with an Administrative Template.

The first setting we must modify is the “Browser sign-in settings”, make sure that the setting is enabled, and that the option “Force users to sign-in to use the browser” is selected.

The second setting we must modify is called: “Configure whether a user always has a default profile automatically signed in with their work or school account”. Make sure that this setting is enabled.

Finish the Configuration Profile and assign it to a group of your choosing.

On a sidenote, installing extensions in Microsoft Edge is much easier, since it’s also part of the Administrative Templates, search for  “Control which extensions are installed silently” and just supply the unique id or more in a list.

Conclusion

Before rolling out Conditional Access make sure that you have configured the browsers on your Modern Workplace to support your Conditional Access scenario’s. Also make sure that you explain to your users which browsers can be used for what scenario. In the end it shouldn’t matter if they use non-standard browsers, as long as they are aware of the consequences.