I recently tested Seamless SSO on an Azure AD joint device running Google Chrome. I was left scratching my head when the sign-in experience was not the same as with Internet Explorer. I found quite a few articles online detailing some additional Authentication policies within Chrome which are required for this function to work. When you are using InTune to manage your devices, it can be trickier to push these polices to devices so I thought I would share my experience.

Before configuring the policies required, you will need to create an InTune policy to ingest the ADMX template into InTune. This process is pretty straight forward. However, working out the OMA URI and the formatting of the string for the various settings (if you haven’t done it before) is much trickier.

Policy Settings

Name: AuthNegotiateDelegateWhitelist
OMA URI: ./Device/Vendor/MSFT/Policy/Config/Chrome~Policy~googlechrome~HTTPAuthentication/AuthNegotiateDelegateWhitelist
Data Type: String

<enabled/> <data id="AuthNegotiateDelegateWhitelist" value="autologon.microsoftazuread-sso.com"/>

Name: AuthServerWhitelist
OMA URI: ./Device/Vendor/MSFT/Policy/Config/Chrome~Policy~googlechrome~HTTPAuthentication/AuthServerWhitelist
Data Type: String

<enabled/> <data id="AuthServerWhitelist" value="autologon.microsoftazuread-sso.com"/>

A quick tip

The OMA-URI follows a particular format and some policies are configured under a particular category. Make sure you browse the chrome.admx template in a text editor to check this.

In our case, the settings we wanted to configure were under the HTTPAuthentication parentCategory.

Chrome(App)~Policy(Type)~googlechrome(Category)~HTTPAuthentication(Category)/AuthNegotiateDelegateWhitelist(Setting)

The HTTPAuthentication parentCategory falls under googlechrome.