Configure CloudAPAuthEnabled to support Conditional Access in Google Chrome natively

Starting with version 111 of Google Chrome, organizations can leverage conditional access policies natively using CloudAPAuthEnabled. Before this release, Conditional access policies were only supported on Google Chrome by using additional extensions like Windows Accounts and Office Online. If you want to know more about the use of these extensions, then you can read all about it over here.

Let's see the new policy involving CloudAPAuthEnabled in a little detail and how can organization configure it using enterprise device management solutions.

CloudAPAuthEnabled is a setting that can be configured using the policy Configures automatic user sign-in for accounts backed by a Microsoft® cloud identity provider. 

By setting this policy to 1 (Enabled), users who sign into their computer with an account backed by a Microsoft cloud identity provider or who have added a work or school account to Microsoft Windows, can be signed into web properties using that identity automatically. Information pertaining to the user's device and account is transmitted to the user's cloud identity provider for each authentication event. 

By setting this policy to 0 (Disabled) or leaving it unset, automatic sign-in as described above is disabled. Once the policy is enforced, the following registry will get created.

Software\Policies\Google\Chrome\CloudAPAuthEnabled

Now let's look at configuring the policy. Google has added the new policy in the v111 and later in .admx templates. Organizations have the option to use these templates and apply the policy or use custom scripts like a PS script to configure the relevant registry values. If your organization has already adopted modern workplace methodology and managing devices using Intune, then you can configure the policy easily. As of writing this blog, the new Google chrome .admx policies have not made it to the built-in Intune settings catalog for Google Chrome, therefore, we are going to import the relevant .admx templates and configure the necessary policy. If you want to know more about using built-in Google Chrome settings catalog, then you can read it about it here.

1. Head over to Download Chrome Browser for enterprise and make sure to download the bundle.

2. Extract the contents of  the downloaded zip file.

3. Head over to Microsoft Intune admin center.

4. Navigate to Devices > Configuration > Import ADMX

5. Import the .admx and .adml files for chrome, google at a minimum, located under Configuration\admx and Configuration\admx\en-US respectively. 

Note: For languages other than english, use other language .adml file.

Note: If you get the error NamespaceMissing:Microsoft.Policies.Windows, then chances are you are missing the Windows namespace.

To fix this you will need to import the Windows.admx file. Head over to Windows 10 or Windows 11 download links and import it in Intune using the same process as described above. You will need to install the downloaded .msi first which will extract the files under the default Program Files (x86) location -

6. After a successful import, it is time to create a new profile. Navigate to Devices > Configuration > Create Profile.

7. Select Platform as Windows 10 and later.

8. Select Profile type as Templates and then Imported Administrative templates (Preview).

9. Give a name and select the following value as shown below.

10. Assign to a device or user based group.

Time to put this to test

I am testing a CA policy requiring device compliance state. First let's see what the behavior is like when you try to access corporate resources without the extension and CloudAPAuthEnabled. As expected, the device state is not captured and the CA policy has blocked the access.

Now let's see what happens when the Intune policy is applied. According to event id 866, the .admx for chrome has been ingested successfully.

The device configuration policy has also applied successfully.

You can be verify for the ingestion of the .admx template in registry as well.

The CloudAPAuthEnabled registry can be seen as created.

With all the policies in place, accessing the corporate data from Google Chrome isn't blocked anymore and this time the device state was captured through CloudAPAuthEnabled.

Last but not the least, the compliance reported correctly in Intune against the setting.

Conclusion

It is simply wonderful that now CA policies on Google Chrome work natively. It certainly makes things easier when you don't have to deal with extensions especially if your organization has strict policy around the use of extensions. However, I did face an issue during my testing where google .admx couldn't be uploaded because an older version was already imported. As of writing this blog, you cannot import an .admx with the same name or containing the same namespace. You will need to delete the existing imported .admx and all its referenced policies and assignments. Alternatively, you can configure the registry using a PS script. Also, according to reddit, there have been some issues reported around getting CloudAPAuthEnabled to work with SSO against some enterprise Apps. I haven't tested this myself, but something to be mindful of.

Until next time..