I'm building a new Azure Virtual Desktop environment in East US using Windows 11 Enterprise multi-session, a pooled host pool, and Microsoft Entra-joined session hosts. The hosts are enrolled and compliant in Intune, licensed with Microsoft 365 G3 GCC, assigned to the Desktop Application Group, and configured with Virtual Machine User Login RBAC. MFA works, the host pool has enablerdsaadauth:i:1 enabled, and Windows Cloud Login reports IsRemoteDesktopProtocolEnabled = True. The session hosts have no public IP and use a NAT Gateway for outbound access.
The goal is for users to connect from unmanaged Windows computers using Windows App, while the AVD session remains the managed and compliant environment.
The problem is that users authenticate with Entra ID and complete MFA in Windows App, but are prompted to authenticate again when launching the AVD desktop. The connection then either fails or connects briefly before disconnecting. The same behavior occurs in the web client.
Client logs show that feed discovery, gateway connection, RDS AAD authentication negotiation, and AAD nonce acquisition all succeed. The failure occurs during AcquireRDSAADToken, where Entra returns 50033 temporarily_unavailable. The session ends with "Bootstrap token acquisition was cancelled." Entra sign-in logs show successful Azure Virtual Desktop authentication but failed Windows Cloud Login with error 50000, indicating a token-issuance or sign-in-service problem. Some attempts also returned AADSTS54005, stating that an OAuth2 authorization code was already redeemed.
The issue reproduces with multiple users and both client types. Entra join, Intune compliance, the AADLoginForWindows extension, outbound Microsoft connectivity, managed identity, RBAC, application-group assignments, Windows Cloud Login RDP support, and Conditional Access settings have all been checked. A test user excluded from all Conditional Access policies still has the same problem, and Token Protection is not enabled.
Has anyone encountered this specific Windows Cloud Login and RDS AAD bootstrap-token failure with Entra-joined AVD hosts accessed from unmanaged devices? What additional diagnostics or isolation steps would you try before opening a full Microsoft support case?
2 Answers
Because feed discovery, the gateway, RDS AAD negotiation, and nonce acquisition all succeed, I would stop focusing on RBAC and basic networking for now. Capture one clean failure with the exact UTC timestamp, user, session host, Entra correlation and request IDs, and the matching Microsoft-Windows-AAD/Operational events from the host. Microsoft can use those details to trace the 50000 and 50033 token-issuance failures.
As a final isolation step, create a small test pool with a stock image and a new session host. If the same user fails there after the Conditional Access exclusion test, that points more toward a tenant or service-side issue than image customization or agent drift.
I’d first rule out Conditional Access completely. Check policies scoped to all cloud apps, especially anything requiring a compliant device, and verify that the policies for Azure Virtual Desktop and Windows Cloud Login have compatible MFA and sign-in-frequency settings. Token Protection is also unsupported for AVD.
The quickest test is a dedicated user excluded from every Conditional Access policy. If that user can connect, add the policies back one at a time to identify the conflict.
I tested with a user excluded from all Conditional Access policies and the failure remained. Token Protection is also disabled. I’m reviewing the AVD and Windows Cloud Login settings in detail, but this tenant behaves differently from another environment I built previously.