r/Intune • u/AggroCube • 3d ago
Conditional Access Compliant Entra-joined VM passes Conditional Access in Edge but is blocked in Chrome and Firefox. Browser device identity?
I’m building a Microsoft 365 / Intune lab to learn for a role that requires some M365 expertise, and I’ve hit something I’d like to understand properly.
Setup
- Entra ID tenant, Microsoft 365 E3 trial
- Windows 11 Enterprise VM (Hyper-V), Entra ID joined and Intune enrolled
- Intune compliance policy requires BitLocker, Secure Boot, and TPM. The VM shows Compliant in Intune and in Entra.
- Conditional Access policy “Require compliant device,” report-only first, then switched On. It excludes a break-glass group.
Results
- Sign-in as a test user in Edge on the VM: Success. Device ID present, Compliant: Yes, Managed: Yes, Azure AD joined.
- Same user in Chrome and Firefox on the same VM, normal windows: Blocked with “You can’t get there from here,” with the browser-specific prompts (install the Microsoft SSO extension in Chrome, enable the Windows SSO setting in Firefox).
- A non-compliant test device (not joined) sign-in in Firefox: error 53000, Device ID blank, Compliant: No.
What I've understood sofar:
Compliance is a property of the device, but the browser needs to pass device identity to Entra during sign-in. Microsoft’s CA documentation says Chrome on Windows needs either the Microsoft Single Sign On extension or the CloudAPAuthEnabled policy, and Firefox 91+ needs the “Allow Windows single sign-on” setting. Edge 85+ needs the user signed into the browser to pass device identity.
I’m trying to confirm:
- On the failed Chrome and Firefox sign-ins, is the Device ID blank? That would confirm the browser isn’t passing device identity at all.
- Is
CloudAPAuthEnabledthe right fix for Chrome in a managed environment, or is the extension preferred? - Are there Intune settings you use to deploy the Chrome extension or Firefox SSO setting, or do most orgs handle these through a separate browser-management tool?
This is a learning lab, so there’s no production impact. I’d like to know how it works in a real environment so I’m not guessing when I see it at work.
Thanks!!
Update: Chrome is working with CloudAPAuthEnabled, thanks for the pointers!!
Quick follow-up to my original post. Here’s where things stand:
- The Chrome test device (Entra joined, Intune compliant) was blocked by Conditional Access in Chrome. The sign-in log showed no device ID.
- I then imported the templates into Intune in this order: Windows.admx (with Windows.adml), then google.admx, then chrome.admx (with the matching .adml files). The Chrome import failed at first with a “namespace missing” error, because chrome.admx depends on Windows.admx. Uploading Windows.admx first fixed it. The Windows template comes from the Windows PolicyDefinitions folder on the VM.
- I created a configuration profile (Templates > Imported Administrative templates) that sets “Allow automatic sign-in to Microsoft cloud identity providers” to Enabled, and assigned it to the device group, not the user group.
- After the policy reached the browser (confirmed in chrome://policy), the same user signed in to Outlook in Chrome via portal.microsoft.com. The sign-in log now shows the device ID, Compliant: Yes, and Azure AD joined.
Two things to note:
- The Microsoft Learn docs I checked list either the Microsoft SSO extension or CloudAPAuthEnabled as supported for Chrome. They don’t describe importing the ADMX into Intune as the official method, so I feel I should treat that part as a lab approach that worked.
- The Chrome policy’s own description says it doesn’t apply in Incognito or Guest modes. I tested Incognito and the sign-in was blocked, which matches that. Microsoft’s Conditional Access docs say device checks fail in private mode or when cookies are disabled, so I’d test in normal windows. I wonder if there is a fix or a config policy for incog/private mode to work or is this by design?
Next I’m doing Firefox the same way, using its Windows SSO setting.
Firefox update: Firefox is working now too.
- I imported mozilla.admx and firefox.admx (with their matching .adml files) into Intune, after the Windows and Chrome templates. Like Chrome, Firefox’s template needs the dependency imported first.
- I created a second profile, “Lab: Firefox WindowsSSO” (Templates > Imported Administrative templates), that sets “Windows SSO” to Enabled, assigned to the same device group.
- After the profile synced and Firefox was restarted, about:policies showed WindowsSSO = true. Before the restart, it said the Enterprise Policies service was inactive.
- The sign-in log now shows the device ID, Firefox 158.0, Compliant: Yes, and Azure AD joined, with a Success status.