Configuration of Mainstream Browsers to Allow AAD SSO

1 year ago
Ruian Ding
3 minutes

Overview

When we configure the Device Based Conditional Access Policies (e.g. Devices that required Hybrid Azure AD Join to access certain online resources), device registration is a definitely a necessary prerequisite. However, we still need to successfully obtain the other factor called Azure AD Primary Refresh Token (Azure AD PRT). Only after the Azure AD PRT (which contains device information) is successfully obtained by the device, we can ensure that the device based conditional access policies can be successfully passed.

Browsers are used when we visit some web resources, but not all browsers support reading the Azure AD PRT by default. The following is the configuration of the three mainstream browsers to read Azure AD PRT.

The full supported browser list could be found on this documentation: Conditions in Conditional Access policy – Microsoft Entra | Microsoft Learn

1. Configuration of Mainstream Browsers

1.1 Microsoft Edge

Generally, after the device was successfully registered to Azure AD, it will be automatically sign-in the Edge.

As above, if there is no signed-in user, we cannot pass the Device Based Conditional Access Policies (Not specify the logon user’s Azure AD PRT). We can click Sign in to sync data to do a login process.

This documentation explained why we need a sign-in the profile in order to let the Edge read the PRT:

Microsoft Edge and Conditional Access | Microsoft Learn

1.2 Google Chrome

1.2.1 Installation

We need to install an extension called Windows Accounts.

Google Chrome can also support Incognito Window SSO, after enable the below settings (Only Google Chrome with Windows Accounts Extension).

Notes: The reason why Windows account extension can be used in Incognito mode is due to Google itself having a setting that allows loading extensions in Incognito mode.

1.2.2 Deep Dive

You may have noticed that the full list of supported browsers does not include Windows Server 2016. This is because the SSO extension is only compatible with Windows 10 Creators Update (version 1703) or later operating systems.

The reason for this limitation is that SSO requires a built-in executable file called BrowserCore.exe, which serves as the communication link between Chrome and the SSO artifact. If BrowserCore.exe is not running or Chrome is unable to establish contact with it, SSO and CA (Conditional Access) will not function properly.

Depending on the Windows version, BrowserCore.exe can be found in either of the following locations:

  1. C:\Program Files\Windows Security\BrowserCore\
  2. C:\Windows\BrowserCore\

Therefore, in the case of Windows Server 2016, SSO via Chrome and the SSO extension is not supported since the necessary BrowserCore.exe is not embedded in the system image.

1.3 Mozilla Firefox

We can go to Settings > Privacy & Security > Enable Allow Windows SSO for Microsoft, work, and school accounts to allow Firefox to read the Azure AD PRT.