Share via

AVD SSO Failure with Google Federated External Identity

Isaac Rayner 0 Reputation points
2026-05-22T10:14:23.72+00:00

I want to allow Google (gmail) users to login to AVD. I am using External Identities with B2B user invites.
Entra internal, MS and external MS Tenants work fine. But when I attempt to login with Gmail users and click on the desktop (via the web portal), it fails as follows:
User's image

  1. The Goal: To enable single sign-on (SSO) into an Azure Virtual Desktop (AVD) host pool running Windows 11 24H2 for an external identity provider (IdP) account federated via Google.
  2. The Current Blocker: While workspace feed discovery and initial authentication succeed, launching the RDP connection fails. Entra ID sign-in logs capture a hard failure with Error Code 50085 (Refresh token needs a social identity provider login), targeting the Azure Virtual Desktop resource.
  3. Technical Root Cause: The AVD client runtime attempts to fetch a secondary resource token silently. However, because the user is an external federated social identity, Entra ID requires an interactive authentication step-up back to Google. The application framework appears to be failing to catch or display this interactive prompt, resulting in background token acquisition dropping over a CORS/401 restriction.
  4. Current State: The tenant is fully configured with an Entra P2 license, Cross-Tenant Access Settings inbound trusts are wide open, and the user profile has been flipped from Guest to Member to clear local OS-level restrictions on the session host—yet the backend token exchange remains blocked.

Environment & Baseline Configuration

Session Host Operating System: Windows 11 Enterprise multi-session, version 24H2 (Build 26100.8457).

Identity Architecture: Cloud-native Microsoft Entra Joined (No Hybrid identity dependencies).

Licensing: Entra ID P2 license assigned to the testing identity; external user licensing enabled for AVD.

Conditional Access: No Conditional Access policies active in the tenant (rules out device compliance/MFA blocks).

  • Testing Account: Federated Google identity provider account.

Troubleshooting Steps Attempted

1. Host Pool RDP Configuration

Verified and confirmed that Microsoft Entra ID authentication for RDP is natively enabled on the Host Pool properties.

Configured the advanced RDP properties string to explicitly support Azure AD join and custom authentication parameters: enablerdpmstsc:i:1;targetisaadjoined:i:1;

Documentation Reference: Microsoft Docs: Configure Microsoft Entra single sign-on for Azure Virtual Desktop

2. External Identity & Federation Verification

Confirmed Google Federation is fully set up and functional at the tenant level.

Verified that the external guest identity can successfully authenticate against the tenant identity layer before attempting the RDP stream handoff.

Documentation References: * Microsoft Docs: External Identities in Azure Virtual Desktop

Microsoft Docs: Identity Providers for External ID

  [Microsoft Docs: Add Google as an identity provider for B2B guest users](https://learn.microsoft.com/en-us/entra/external-id/google-federation)
  

3. Entra ID Cross-Tenant Access Settings (XTAS)

Investigated initial token failures showing Error AADSTS5001212 (Device authentication is required to issue primary refresh token via Microsoft Authentication Broker).

Modified tenant Inbound access settings -> Default settings -> Trust settings to explicitly check:

Trust multi-factor authentication from Microsoft Entra tenants

  _Trust compliant devices_
  
     _Trust Microsoft Entra hybrid joined devices_
     
     _Purpose:_ To allow external identities to pass mandatory client device/token assertions natively across the tenant boundary.
     

4. User Object Schema Modification

Identified that the local Windows logon architecture on the session host dropped connections with a 0x0 authentication error when evaluating standard B2B Guest profiles.

Manually modified the user metadata in the Entra ID portal, transforming the structural User Type of ******@gmail.com from Guest to Member.

Ensured explicit Virtual Machine User Login RBAC permissions were applied to the session host resource group for this identity.

5. Deep-Linking & Tenant-Bound Context Testing

Bypassed global/generic discovery endpoints (/organizations/ or /common/) to rule out routing issues.

  • Tested resource feed subscription via tenant-isolated deep links in both browser sandbox environments and the native desktop client:
    • Web Client link used: https://windows.cloud.microsoft/?tenantId=<my tenant>

6. Local Token & Broker Cache Purges

To eliminate stale security context stubs caching the Guest state, performed aggressive client-side cleansing:

Disconnected identity profiles from Windows Access work or school / Email & accounts.

  Forcibly cleared the local browser storage, cookies, and local AppData state for the Remote Desktop client packages.
  
     Purged the native OS broker cache directories via PowerShell (`$env:LOCALAPPDATA\Microsoft\TokenBroker\Cache\*`).
     

Current Status & Blockers

Following the Member object transition, the initial 5001212 broker block resolved, but the connection now fails at the final Azure Virtual Desktop resource handshake.

Latest Entra Sign-In Error: AADSTS50085 (Refresh token needs a social identity provider login).

  • Symptom: When attempting to launch the RDP session, the token request to resource (Azure Virtual Desktop) fails silently over CORS / background token acquisition loops because the platform expects interactive social IdP step-up authentication that the client application is unable to execute or process cleanly.
Microsoft Security | Microsoft Entra | Microsoft Entra External ID

1 answer

Sort by: Most helpful
  1. Rukmini 42,515 Reputation points Microsoft External Staff Moderator
    2026-05-22T11:30:44.4966667+00:00

    Hello Isaac Rayner

    Although the initial authentication is successful, the client needs to covertly obtain more tokens for the AVD resource during the AVD launch sequence. AADSTS50085 results from the existing AVD client/token broker flow's inability to discreetly complete the additional interactive sign-in with Google required by Entra ID for Google-federated users.

    You successfully ruled out the following troubleshooting steps:

    • Conditional Access
    • Cross-tenant trust configurations
    • Configuration of Guests vs. Members
    • Broker cache problems and device compliance

    Currently, seamless AVD SSO is consistently supported for:

    • Native Entra ID accounts
    • Microsoft Accounts
    • External Microsoft Entra tenants

    For this AVD SSO flow, Google/social identity federation scenarios are not yet completely supported.

    As a workaround, we advise utilizing:

    • Google federation can be replaced by cloud-native Entra accounts or external Microsoft Entra tenant identities.

    Currently, there is no public ETA for support of Google federated identities with AVD SSO.

    Let me know if any further queries - feel free to reach out!

    Was this answer helpful?


Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.