No matter what you say sometimes, people are stuck in their ways. Especially when it comes to web browsers. If you’re using Windows and Intune joined devices, using Edge offers your users the best and most seamless experience (in my opinion). However, many organizations still want to use Chrome or require that its installed on their devices (even though Edge has been based on Chromium for years).
When using conditional access policies that evaluate device signals, such as compliance or device registration state, authentications from Edge are natively compatible with conditional access and can send this device information to Entra during an authentication attempt. However, by default, Chrome does not do this. Even if users are trying to authenticate from an Entra-joined compliant device, since Entra is not receiving device information, it considers the device “unknown” or “unmanaged” and blocks access.
The user experience will look like this. This authentication attempt is from a compliant device from a user targeted by a conditional access policy to require a compliant device to access any O365 app.
And in the Entra Sign-in logs, you’ll see this for the authentication attempt:
Microsoft does give you a fix right on the block message. The link brings you to where you can download and install the Microsoft Single Sign On – Chrome Web Store (google.com).
That’s one option, and it will work. After installing the Microsoft Single Sign-On extension, the device signals will be sent to Entra during authentication. The other option, which I prefer, is to deploy a registry value for CloudAPAuthEnabled, which allows Chrome to send device-specific details during an authentication attempt. More specific details can be found on the MS Learn page related to conditional access and supported browsers – Conditions in Conditional Access policy – Microsoft Entra ID | Microsoft Learn.
After installing the extension, or adding the reg value, authentications from Chrome will show the device ID, compliance, and Join Type (like in the screenshot below from the sign-in logs). Google’s documentation on this can be found here – Chrome Enterprise Policy List & Management | Documentation. I prefer to use the registry edit instead of the extension since this is built into Chrome and simply needs to be switched on. It’s one less extension to manage/deploy, and adding reg keys using Intune is simple. /
Adding the CloudAPAuthEnabled Registry value with Intune
So, we have a couple of ways to add this registry value using Intune. We can import the ADMX files from here, but I continued to receive errors when trying to import. Not sure if there was an Intune issue going on at the time I was trying to do this, but after about 15 minutes I gave up and made a simple script that adds the registry keys and value. This can be deployed as a remediation, platform script, or Win32 app. I’m using a Win32 app in this example since my customer at the time was not licensed for Remediations.
Wrap the install.ps1 file as an Intunewin file, create your app, and use the install command below, where install.ps1 is the name of the Powershell script.
- Powershell.exe -executionpolicy bypass .\install.ps1
Add your requirements, and for our detection method, we will use a registry rule to see if the reg name and value exist:
After your deployment, you can either wait for the device status to report back to Intune, or check the new AppWorkload log for the Win32 app deployment:
Once that’s deployed. Chrome will send device information to Entra during logons 👍