Problema

En entornos de Azure Virtual Desktop (AVD) que usan Windows Cloud Login (WCL) y están unidos a Microsoft Entra ID, es frecuente observar que la sesión se cierra en el mismo segundo en que se establece. El cliente (Windows App o web) muestra dos solicitudes de autenticación: la primera finaliza con éxito, la segunda devuelve errores como 50033 / temporarily_unavailable, 50000 o AADSTS54005. El resultado es una desconexión instantánea o un bucle de reintentos que nunca llega a una sesión estable.

Este patrón no está limitado a un único usuario o a un dispositivo concreto; suele aparecer cuando:

  • El host pool está configurado con enablerdsaadauth:i:1.
  • Los equipos cliente son no gestionados (no forman parte de Azure AD Join).
  • El host de sesión no tiene IP pública y depende de NAT Gateway.
  • Se usan licencias Microsoft 365 G3 GCC y la máquina está inscrita en Intune.

El síntoma principal es “Bootstrap token acquisition was cancelled” en los logs de AVD y “Windows Cloud Login = Failure” en los registros de Entra.

Causa

Los fallos de bootstrap‑token en AVD se originan cuando el flujo de autenticación de RDS AAD no puede completar el intercambio de tokens entre el cliente, Entra y el host de sesión. Las causas más habituales son:

  1. Restricciones de Conditional Access (CA) que no se aplican al flujo WCL
    CA puede estar configurado para bloquear tokens de “device‑based” o para exigir MFA adicional en escenarios de “cloud‑only”. Si la política no incluye explícitamente el recurso Microsoft.AAD.BrokerPlugin o el cliente WCL, Entra devuelve 50033.

  2. Falta de permisos de “Windows Cloud Login” en la aplicación AAD
    La aplicación “Windows Cloud Login” necesita los permisos User.Read, openid, offline_access y, sobre todo, RDS.AAD.Broker. Si la aplicación está en modo “restricted” o se ha revocado algún permiso, el token de bootstrap nunca se genera.

  3. Desalineación entre la identidad gestionada del host y los roles RBAC asignados
    El host usa una identidad gestionada del sistema para acceder a los recursos de Azure. Si esa identidad no tiene el rol Desktop Virtualization User o Desktop Virtualization Host en el recurso de host pool, el token de bootstrap es rechazado.

  4. Problemas de conectividad a los puntos finales de Entra
    Aunque los puertos requeridos estén abiertos, el NAT Gateway puede estar alterando la cabecera X-Forwarded-For, lo que hace que Entra detecte una IP desconocida y marque la solicitud como sospechosa, devolviendo 50033.

  5. Estado de cumplimiento de Intune incompleto o expirado
    El host necesita estar “compliant” en el momento de la autenticación. Si la política de cumplimiento se actualiza y el agente no ha reportado el nuevo estado, Entra lo interpreta como no compliant y aborta el flujo.

  6. Duplicación del código de autorización OAuth2
    El error AADSTS54005 indica que el código de autorización ya se ha consumido. Esto ocurre cuando el cliente reintenta la solicitud antes de que el primer intento haya expirado, típicamente por una mala gestión del tiempo de espera en la aplicación Windows.

Solución

Una estrategia de diagnóstico y corrección paso a paso cubre la mayoría de los escenarios descritos. La idea es validar cada capa del flujo antes de pasar a la siguiente.

1. Verificar y ajustar políticas de Conditional Access

  • Abre Azure AD → Security → Conditional Access.
  • Crea (o edita) una política que incluya explícitamente “All cloud apps” y “Windows Cloud Login” como aplicación objetivo.
  • En Grant, habilita Require multi‑factor authentication y Require device to be marked as compliant solo si la política ya está probada en entornos de prueba.
  • Asegúrate de excluir usuarios de prueba o grupos de “Break‑glass” para evitar bloqueos totales.

2. Revisar permisos de la aplicación “Windows Cloud Login”

  • En Azure AD → App registrations, busca Windows Cloud Login.
  • En API permissions, verifica que estén presentes User.Read, openid, offline_access y RDS.AAD.Broker.
  • Si falta alguno, añádelo y pulsa Grant admin consent.
  • Si la aplicación está en modo “restricted”, cambia a “public client” o habilita “allow public client flows”.

3. Alinear roles de la identidad gestionada

  • En el portal, navega a Host pools → → Access control (IAM).
  • Asigna a la System‑assigned managed identity del host pool los roles Desktop Virtualization Host y Desktop Virtualization User.
  • Si usas una identidad de usuario, verifica que tenga los mismos roles a nivel de recurso.

4. Confirmar conectividad a los endpoints de Entra

  • Ejecuta un curl o Test-NetConnection desde el host de sesión hacia los dominios login.microsoftonline.com, aadcdn.msftauth.net y enterpriseregistration.windows.net.
  • Asegúrate de que la respuesta sea 200 y que no haya redirecciones a direcciones internas del NAT.
  • Si el NAT Gateway está usando SNAT, habilita source IP preservation o añade una regla de salida estática para que la IP pública sea constante.

5. Forzar re‑registro de cumplimiento en Intune

# Forzar sincronización del agente de Intune
mdmclient -reset
mdmclient -sync
  • Después de ejecutar los comandos, revisa en Intune → Devices que el estado sea Compliant.
  • Si persiste, elimina y vuelve a registrar el host en Intune.

6. Limpiar tokens y caché del cliente Windows

  • En el equipo cliente, abre Credential Manager y elimina todas las entradas relacionadas con MicrosoftAccount y Windows Cloud Login.
  • Reinicia el cliente Windows App y vuelve a iniciar sesión.
  • Si el error AADSTS54005 sigue apareciendo, aumenta el tiempo de espera en la configuración del cliente (opción “Advanced – Token refresh timeout”).

7. Revisar logs de diagnóstico

  • En el host de sesión, habilita Diagnostic settings para Azure Monitor y captura los logs de AzureDiagnostics y AADSignInLogs.
  • Busca eventos con eventId=50033 o eventId=50000.
  • Correlaciona la marca de tiempo con la solicitud de bootstrap para identificar si el fallo ocurre antes o después de la validación de cumplimiento.

Cuándo aplicar esta solución

Aplica este proceso cuando:

  • Los usuarios experimentan desconexiones inmediatas tras autenticarse con Windows Cloud Login.
  • Los logs de AVD indican fallos en AcquireRDSAADToken o Bootstrap token acquisition was cancelled.
  • Los intentos de conexión fallan tanto en el cliente Windows App como en la versión web.

No es necesario seguir todos los pasos si ya se ha verificado una capa específica (por ejemplo, si la política CA está confirmada como correcta). En entornos donde el host tiene IP pública y no usa NAT, el punto 4 puede omitirse.

Código

# 1. Verificar conectividad a los endpoints de Entra
for host in login.microsoftonline.com aadcdn.msftauth.net enterpriseregistration.windows.net; do
    echo "Probando $host"
    Test-NetConnection -ComputerName $host -Port 443 -InformationLevel Detailed
done

# 2. Forzar sincronización de Intune
mdmclient -reset
mdmclient -sync

Verificación

  1. Inicio de sesión exitoso: El cliente muestra la pantalla de escritorio sin volver a pedir credenciales.
  2. Logs de Azure: En AzureDiagnostics, el evento AcquireRDSAADToken debe registrar Success.
  3. Intune: El dispositivo aparece como Compliant y la columna Azure AD Join muestra Joined.
  4. CA: En Sign‑in logs, el campo Conditional Access status debe ser Not applied o Success.

Si alguno de estos indicadores sigue fallando, revisa la capa anterior del proceso y repite los pasos correspondientes.

Notas adicionales

  • En entornos GCC, algunos endpoints de Entra pueden estar restringidos a dominios específicos; verifica que la lista de URLs permitidas en el firewall incluya los dominios de la región correspondiente.
  • Cuando se usa una versión de Windows 11 Enterprise multi‑session, asegúrate de que la imagen base tenga la última actualización de Remote Desktop Services; versiones antiguas pueden no soportar correctamente enablerdsaadauth:i:1.
  • Si el problema persiste después de aplicar todas las correcciones, abre un ticket con Microsoft Support indicando los IDs de los eventos 50033 y 50000; la información de diagnóstico suele acelerar la resolución.