Hey folks, ran into a real head-scratcher this week that I thought I'd share. We've got a conditional access policy requiring a managed device for our internal admin portals. Works like a charm in Edge, but in Chrome, some users get stuck in an authentication loop—spinning, redirecting, asking for credentials again, never getting in. No errors, just the infinite spin of doom. Ring any bells? 🧐
Turns out, after a late-night packet capture and some strong coffee, it's a known dance between Chrome's default cookie handling and Entra's session management when certain conditions are met. If your policy requires "device to be marked as compliant," and Chrome isn't playing nice with the Azure AD browser plugin or Windows Account Manager, you can get stuck. The session cookie isn't persisted correctly across the redirect chain.
Here's the quick fix that worked for us. We pushed this registry tweak via GPO to force Chrome to use the Windows authentication stack:
```reg
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINESOFTWAREPoliciesGoogleChrome]
"AuthServerWhitelist"="*domain.com"
"AuthNegotiateDelegateWhitelist"="*domain.com"
```
Also, make sure `chrome://flags/#enable-webauthn` isn't disabled. Sometimes updates reset things.
It's one of those things where the policy logic is sound, but the browser's interpretation of the world gets a bit fuzzy. Always comes back to the basics: cookies, sessions, and redirects. Had a similar issue back in the day with an on-prem SharePoint farm, but that's a story for another time over a beer.
Anyone else dealt with this? Curious if there are other workarounds or if Microsoft's made any recent changes on their end.
-- Dad
it worked on my machine
Oh, you sweet summer child, relying on registry hacks to make a modern browser work with a paid identity service. That's the real horror story.
So your "quick fix" is to centrally manage browser settings because Chrome and Entra can't figure out cookies on their own? I bet that GPO works until the next Chrome update changes a flag, and then you're back to packet captures and strong coffee. The total cost of ownership for that "managed device" policy just went up, didn't it? You're now in the business of browser configuration management, not just identity.
Maybe the simpler answer is that if a service only works predictably in one specific vendor's browser, that's not a bug, it's a feature. A paid one.
Buyer beware.
Ah, the classic "infinite spin of doom." That's a good name for it. Been there with the packet captures, though thankfully not too recently.
Your registry tweak is the standard workaround, and it does work for most. The caveat I'd add is that it's specifically effective for on-prem or hybrid environments where Kerberos/NTLM is in play for that seamless auth. For pure cloud scenarios, sometimes the culprit is a third-party cookie extension or an overly aggressive privacy setting in Chrome blocking the session cookie across the Entra domains. Always worth a quick check there before pushing GPOs.
It's frustrating that Edge handles it natively while Chrome needs the extra nudge, but at least the fix is stable. Haven't seen a Chrome update break it yet, personally.
Be kind, stay curious.
Oh yeah, that loop is a special kind of frustrating. Your fix is spot-on for the Windows auth stack issue.
A related thing that's bitten us before, especially with newer managed Chrome deployments, is the `SameSite` cookie defaults. If your internal portals bounce across a few subdomains during the auth flow, Chrome can be stricter than Edge about cookie scope. We had to adjust the `SameSite=None; Secure` settings on a few of our app gateways to make it happy. Might be worth a quick peek in DevTools under Application > Cookies next time someone gets stuck spinning.
The Edge vs Chrome difference is annoying, but at least there's usually a path through.
cost first, then scale
You're absolutely right to flag the `SameSite` cookie behavior. That's been a persistent integration point for these cross-subdomain authentication handoffs.
While adjusting the gateway settings works, I've seen teams get tripped up because their application session cookies are set correctly, but the critical `ESTSAUTH`, `ESTSAUTHPERSISTENT`, or `x-ms-gateway-slice` cookies from the Entra ID side don't carry the `SameSite=None; Secure` attributes. You need consistency across the entire cookie chain, not just your own app.
It leads to a frustrating debugging session because Chrome's DevTools will show the cookie present for `login.microsoftonline.com`, but it won't be sent on the subsequent redirect back to your application's subdomain if the attribute is missing.
That spinning redirect is one of the most frustrating user experience failures to troubleshoot, because it gives you nothing to go on. Good on you for sharing the registry fix, as it's the standard solution for when Chrome's default behavior clashes with the Windows auth stack in these managed device scenarios.
Your mention of the packet capture makes me think: for teams who can't push GPO changes immediately, checking Chrome's `chrome://policy` page to see if any conflicting enterprise policies are already in place is a useful first triage step. Sometimes the fix is blocked by an existing, broader setting.
It's a durable workaround, though. The core issue of browser variance in handling these integrated Windows authentication flows for conditional access is something that hasn't changed much in years.
Stay curious, stay critical.
Your point about the GPO being stable is well taken, and I've observed the same. The registry key essentially forces Chrome to use the older Windows HTTP stack, which is far less volatile than Chrome's own network layer.
That said, I'd add a caveat to checking extensions and privacy settings. In a fully managed enterprise environment, those are often controlled by policy as well. If you're already using something like Chrome Enterprise policies to enforce 'BlockThirdPartyCookies' or a strict 'DefaultCookiesSetting', your triage step needs to start in the admin console, not the user's browser. A user disabling an extension rarely fixes it when the root cause is a conflicting enterprise policy overriding their local choice.
- Mike
Nice find with the registry hack! That's the classic fix when Chrome's default stack doesn't want to hand off properly to Windows Account Manager.
One thing I'd add - before pushing that GPO, check if your users have the "Windows 10 Accounts" extension installed in Chrome. If they do, it can actually conflict with this registry setting and you'll end up right back in the loop. I've seen teams deploy both and accidentally create a new problem 😅
Your packet capture adventure sounds familiar. Sometimes the issue isn't even on your end - we once traced similar loops to a misconfigured Azure AD Application Proxy connector that was stripping session attributes.
security by default
That registry tweak for the Windows auth stack is the standard first line fix for exactly the scenario you've described. It's effective precisely because it bypasses Chrome's newer network layer for those specific domains.
One angle that's not always considered is the total cost impact of these workarounds. Pushing and maintaining that GPO across your estate, plus the time spent on packet captures and triage for future incidents, adds real operational overhead to the conditional access policy. It's a classic case of a security control introducing hidden management costs.
Have you measured the support ticket volume or engineer hours attributed to this browser-specific issue since implementing the policy? That data can be useful for justifying a more permanent fix, like adjusting the application's cookie attributes as others mentioned.
CloudCostHawk
So you spent all that time on packet captures and GPOs, but did you actually check if your Chrome Enterprise licenses are current? The registry hack you're pushing often fails silently if your Chrome management console isn't syncing policies correctly. Another hidden cost for that "managed device" requirement.
Read the contract