"Use password instead" button where passwordless prompt would have been

ChatGPT tells me this... Perfect — that’s exactly the right question, and you’re thinking about it in the right direction. If this is a clean, non-persistent Citrix desktop, with a new user profile each session (i.e.,

%localappdata%

is created fresh from the default profile at logon), then yes — there’s truly no local cache to pull from. So the natural follow-up is: “Then where the hell is Teams getting the idea that this domain is managed and that I should start the Microsoft Authenticator/passwordless flow?” Let’s go step by step. 🧩 What’s really happening (and it’s not local) Even on a pristine session, when Teams (or any WAM-enabled app) starts an auth flow, it doesn’t actually query

GetUserRealm

directly. It goes through the Microsoft Identity Service (WAM), which in turn relies on STS discovery metadata cached globally within Microsoft’s infrastructure, not on your device. 1️⃣ “Tenant metadata” caching in Microsoft’s STS When a user enters

<mailto:user@rgrdlaw.com|user@rgrdlaw.com>

, WAM calls into Microsoft’s login service (

<http://login.microsoftonline.com|login.microsoftonline.com>

) to determine the authentication type. Microsoft’s front-end STS maintains an internal realm/metadata cache for every verified domain. When you flip a domain from Managed → Federated, Microsoft updates that mapping—but the propagation to all login endpoints (especially globally distributed STS edges and CDN caches) can take 24–48 hours. So, depending on which login front-end your Citrix host hits (based on its egress IP and region), it may still have the old “Managed” entry. That’s why your fresh desktop, with no local state, still starts on Microsoft’s passwordless/Authenticator flow until that regional cache expires. That’s also why your iOS users (hitting a different STS region) might already be seeing the Okta redirect correctly. 2️⃣ Why “Use password instead” fixes it That button forces a full interactive auth request that bypasses the pre-cached passwordless endpoint and performs a fresh userRealm lookup. That’s when it finally gets the up-to-date “Federated → Okta” mapping and redirects properly. So, even in a stateless Citrix session: • No

%localappdata%

cache exists. • No WAM tokens exist. • The stale routing is coming from Microsoft’s own distributed cache layer, not your VM. 🧭 TL;DR Summary SourceCache LocationLifetimeWhat It AffectsLocal Token / ADAL / MSAL`%LOCALAPPDATA%`Per-userNot present hereWAM MetadataLocal + STS-fetchedSessionOnly live cache, gone at logoff*STS Tenant Metadata (Microsoft Edge Servers)Microsoft global infrastructure≈ 24–48 h propagationDetermines whether login.microsoftonline.com routes user to Authenticator or Okta* So even though you’re in a clean, non-persistent session, you can still hit an STS edge that hasn’t picked up your new federation state yet. That’s the only remaining explanation that’s consistent with your test.

+90 hours (Monday morning) and found out why some accounts, including mine, were sticking with an MS Authenticator auth flow (dispelling WAM cache theory) Definite edge case in our org that revolved around the stuck users setting up passwordless. I guess it was a mixed blessing that passwordless has not gained momentum in our use base? My iPhone was still registered for passwordless sign-in (FIDO2/WebAuthn), and that process triggers before the userRealm check that would’ve sent me to Okta. Once I removed the passwordless pairing, the end user can do so themselves at https://mysignins.microsoft.com/security-info or even better, an admin can remove the enrolled passkey devices from Entra user objects ahead of federation, everything behaved normally.