I'm building a pooled Azure Virtual Desktop environment in East US using Windows 11 Enterprise multi-session hosts. The hosts are Microsoft Entra joined, Intune-enrolled and compliant, and users have the required Microsoft 365 GCC licensing, Desktop Application Group access, and Virtual Machine User Login RBAC. MFA works, and the host pool uses RDS AAD authentication with Windows Cloud Login enabled. The session hosts have no public IPs and use a NAT Gateway for outbound traffic.
The goal is to let users connect from unmanaged Windows PCs through Windows App while keeping the AVD session as the managed and compliant CUI environment.
The user signs in successfully and completes MFA in Windows App, but selecting the AVD desktop prompts for authentication again. The connection then either fails or connects briefly before disconnecting. The same behavior occurs in the web client.
Logs show that feed discovery, gateway connection, RDS AAD negotiation, and AAD nonce acquisition succeed. The failure occurs during RDS AAD token acquisition, where Entra returns error 50033 (temporarily unavailable), followed by a cancelled bootstrap-token acquisition. Entra sign-in logs show successful Azure Virtual Desktop authentication but failed Windows Cloud Login with error 50000. Some attempts also show AADSTS54005, indicating that an OAuth authorization code was already redeemed.
The issue affects multiple users and both clients. Entra join, Intune compliance, the AAD login extension, outbound connectivity, managed identity, RBAC, application-group assignments, Windows Cloud Login, and Conditional Access settings have all been checked. A test user excluded from all Conditional Access policies has the same problem, and Token Protection is not enabled.
Has anyone encountered this specific Windows Cloud Login or RDS AAD bootstrap-token failure with an Entra-joined AVD host and an unmanaged client? What additional troubleshooting would you recommend before escalating to Microsoft?
2 Answers
Conditional Access is still worth checking carefully, especially policies targeting all cloud apps, device compliance, MFA, sign-in frequency, or Windows Cloud Login. Since the connecting PCs are unmanaged, a policy requiring a compliant device could break the second authentication step. Also verify that Token Protection is not enabled, because it is unsupported for this AVD scenario.
The quickest isolation step is a test account excluded from every Conditional Access policy. If that account works, re-enable policies one at a time to identify the conflict.
The successful feed discovery, gateway connection, RDS AAD negotiation, and nonce acquisition suggest that networking, RBAC, and the application-group configuration are probably not the immediate problem. The failure is occurring during Entra token issuance, so capture one clean reproduction with the UTC timestamp, user, session host, request or correlation IDs, and the matching Microsoft-Windows-AAD/Operational events from the host.
It is also worth testing a stock-image session host in a small temporary pool. If the same user fails there even after the Conditional Access exclusion, that points more strongly to a tenant or service-side token-issuance problem than to image customizations, the AVD agent, or the host configuration. Those logs should give Microsoft support enough information to trace the 50000 and 50033 responses.
I tested with a user excluded from all Conditional Access policies and the failure remained. Token Protection is also disabled, so I’m continuing to investigate other possible causes.