Ctrl+Alt+Route

Microsoft Edge integrates tightly with Microsoft 365 and Entra ID, but Chrome is still widely used in Windows environments.

That can create authentication issues when Conditional Access policies expect device information to be present during sign-in.

Microsoft provides a Single Sign On extension for Chrome that can help bridge that gap by allowing supported Microsoft authentication flows to use the signed-in Windows account.

This guide covers how to deploy the extension through Intune, validate the authentication flow, and troubleshoot a common issue where a hybrid-joined device exists in Entra ID but is not actually enrolled in Intune.

Microsoft SSO Extension Details

The Microsoft Single Sign On extension ID is:

ppnbnpeolgkicgegkbkbjmhlideopiji

For a force-installed Chrome extension policy, use:

ppnbnpeolgkicgegkbkbjmhlideopiji;https://clients2.google.com/service/update2/crx

Google documents the Intune deployment process here:

Manage Chrome browser with Intune Settings Catalog

Create the Intune Policy

In the Intune admin center, go to: Devices > Windows > Configuration and then create a new policy with:

Platform: Windows 10 and later
Profile type: Settings catalog

A clear policy name would be:

Chrome Extension - Microsoft SSO

Under Configuration settings, browse to:

Google > Google Chrome Extensions > Configure the list of force-installed apps and extensions
Select:

Extension/app IDs and update URLs to be silently installed (Device)
Add:

ppnbnpeolgkicgegkbkbjmhlideopiji;https://clients2.google.com/service/update2/crx

Using the device-level setting makes the extension deployment independent of which user signs into Chrome.

Don’t be surprised if the policy doesn’t appear immediately.

Intune group membership and configuration profile assignments can take time to propagate. A device may not initially appear under the profile’s assignment status even when the configuration is correct.

For initial testing, assign the policy to a small device group rather than a broad production group.

Test Microsoft SSO

Once the extension is installed, test authentication against Microsoft services such as:

https://outlook.office.com
and:
https://myapps.microsoft.com
The more important validation, however, is in Entra ID.

Go to:

Entra ID > Monitoring > Sign-in logs
Generate a new authentication event from Chrome and inspect the result.

If the extension is working correctly, the sign-in should include the expected device context.

This becomes especially important when Conditional Access policies depend on whether a device is known, compliant, or managed.

When the Extension Doesn’t Deploy

One issue that can be easy to miss is the difference between an Entra-joined device and an Intune-enrolled device.

Consider a hybrid-joined Windows computer where:

dsregcmd /status

shows:

AzureAdJoined : YES
DomainJoined  : YES

and the MDM URL is populated.

At first glance, the device looks correctly configured.

But that does not necessarily mean Intune enrollment has completed.

A device can successfully complete its Entra or hybrid join while still having no active MDM enrollment.

If the device isn’t enrolled in Intune, Intune cannot deliver the Chrome configuration profile.

Test Applications That Redirect to Chrome

It’s also worth testing applications that use the system browser for authentication.

If Chrome is configured as the default browser, applications such as VPN clients or remote-access tools may redirect Microsoft authentication through Chrome.

Complete the authentication and review the resulting Entra sign-in event.

If everything is working correctly, the device information should still be available during the authentication flow.

Microsoft SSO and Google Accounts

Another useful test is running Chrome while signed into a Google profile.

The Microsoft SSO extension does not necessarily replace Chrome’s existing Google authentication.

In testing, Microsoft services continued using Microsoft authentication while sites supporting Google authentication continued using the Google account.

A typical result looks like:

Outlook Web       Microsoft authentication
Excel Web         Microsoft authentication
My Apps           Microsoft authentication
Google services   Google authentication

This allows Chrome users to remain signed into their normal browser profile while still benefiting from Microsoft SSO for supported Microsoft resources.

Moving Beyond a Pilot Group

Once testing is complete, the policy can be assigned to a broader device group.

Dynamic device groups work well for this because membership can be based on the same criteria used to identify managed Windows devices.

A separate exclusion group is also useful.

A simple structure could look like:

Chrome Extension - Microsoft SSO
Include:
Managed Windows Devices
Exclude:
Chrome Microsoft SSO Exclusions

The exclusion group provides an easy way to remove individual devices from the deployment during troubleshooting without modifying the main targeting logic.