Microsoft ha añadido a Azure Virtual Desktop la compatibilidad con identidades externas mediante la federación de IdP SAML sin dominio (Domainless SAML IdP federation). En línea con la disponibilidad general de la federación de IdP SAML sin dominio en Microsoft Entra ID, esta actualización elimina uno de los puntos de fricción más persistentes en los escenarios de colaboración B2B: el requisito de que el dominio de correo electrónico del usuario invitado coincida con un dominio configurado en el proveedor de identidad externo.

Si alguna vez has intentado dar acceso a tu entorno de AVD a un partner, un contratista o una empresa adquirida y te has topado con un muro porque su dominio de correo no encajaba con la configuración de tu IdP SAML, esta es la actualización que lo soluciona.

El problema que resuelve

La federación directa tradicional en Microsoft Entra ID funciona enrutando la autenticación según los dominios de correo electrónico. Configuras un proveedor de identidad SAML o WS-Fed y lo asocias a uno o varios dominios verificados. Cuando un usuario invitado inicia sesión, Entra ID examina el sufijo de su UPN (el dominio de correo) y lo dirige al IdP correspondiente.

Esto funciona bien cuando la organización partner usa un único dominio de correo predecible. Pero se desmorona rápidamente en escenarios reales:

  • Organizaciones con varias marcas, cuyas filiales usan dominios distintos pero comparten un IdP central
  • Fusiones y adquisiciones, en las que los dominios de la empresa adquirida todavía no se han migrado
  • Redes de contratistas, en las que cada contratista usa su propio dominio de correo personal
  • Ecosistemas de partners, en los que varias organizaciones necesitan acceso a través de distintos IdP, pero algunas comparten proveedor de correo

En todos estos casos, el requisito de coincidencia de dominio hacía que o bien no pudieras federar en absoluto, o bien tuvieras que configurar y verificar todos los dominios posibles, una pesadilla administrativa.

Cómo funciona la federación sin dominio

La federación de IdP SAML sin dominio cambia por completo el modelo de enrutamiento. En lugar de buscar coincidencias por dominio de correo, Entra ID enruta las solicitudes de autenticación según el URI del emisor SAML (Issuer URI) y los parámetros opcionales domain_hint.

Esto es lo que ocurre internamente:

  1. Configuras un IdP SAML en Entra ID como sin dominio (domainless)
  2. Cuando un usuario invitado canjea su invitación, Entra ID envía la solicitud de autenticación al IdP SAML configurado usando el Issuer URI, no el dominio de correo del usuario
  3. El invitado se autentica en su IdP de origen
  4. Entra ID acepta la aserción SAML basándose en la relación de confianza con el IdP, independientemente del dominio de correo del usuario
  5. La cuenta de invitado se crea en tu inquilino (tenant) y se puede asignar a grupos de hosts y grupos de aplicaciones de AVD

La confianza se deposita en la aserción SAML y el emisor, no en el sufijo del correo. Es un cambio de fondo que hace que la gestión de identidades externas sea mucho más flexible.

Restricción clave

Solo se puede configurar un IdP comodín (sin dominio) por tenant de Entra. Si necesitas admitir varios IdP externos con enrutamiento sin dominio, tendrás que planificar con cuidado tu topología de federación, posiblemente con un patrón de broker de federación o de hub de identidades.

Qué significa esto para AVD

Desde la perspectiva de Azure Virtual Desktop, esta actualización significa que ahora puedes:

  • Proporcionar escritorios y RemoteApps a identidades externas cuyos dominios de correo difieren del dominio configurado en el IdP SAML
  • Invitar a usuarios invitados por correo electrónico sin preocuparte de si su dominio coincide con tu configuración de federación
  • Usar la mecánica de asignación existente de AVD, sin un flujo de aprovisionamiento especial para las identidades externas sin dominio
  • Aprovechar el SSO de Entra: las identidades externas autenticadas mediante el IdP SAML sin dominio reciben tokens de Entra que AVD acepta para el inicio de sesión

AVD no necesita ninguna configuración especial para la federación sin dominio. Simplemente consume la autenticación de Entra y trata la identidad de invitado como a cualquier otro usuario de Entra una vez que está en el directorio.

Cómo configurarlo

La configuración se hace íntegramente en Microsoft Entra ID. AVD solo consume el resultado.

Paso 1: configurar el IdP SAML sin dominio en Entra ID

  1. Inicia sesión en el Centro de administración de Microsoft Entra como, como mínimo, External Identity Provider Administrator
  2. Ve a Identity > External Identities > All identity providers
  3. Selecciona Add SAML/WS-Fed identity provider
  4. Proporciona la configuración necesaria:
    • Display name: un nombre descriptivo para el IdP del partner
    • Issuer URI: el identificador de emisor único del IdP SAML (es en lo que se basará el enrutamiento)
    • Metadata URL or file: para importar los endpoints SAML y los certificados de firma
  5. Activa Domainless: marca el campo Domainless en la configuración del IdP
  6. Guarda la configuración

Paso 2: invitar a usuarios externos

  1. Ve a Identity > Users > All users
  2. Selecciona + New user > Invite external user
  3. Introduce la dirección de correo del usuario invitado; no se aplican restricciones de dominio
  4. Configura el nombre para mostrar, los grupos, los roles o los paquetes de acceso según sea necesario
  5. Envía la invitación

Cuando el invitado canjea su invitación, Entra ID dirige el inicio de sesión al IdP SAML sin dominio usando el Issuer URI. El invitado se autentica en su IdP de origen y, a continuación, se crea como invitado en tu tenant.

Paso 3: asignar usuarios a los recursos de AVD

  1. Ve a la configuración de tu grupo de hosts y grupo de aplicaciones de AVD en el portal de Azure
  2. Asigna los usuarios o grupos invitados de Entra a Desktop application groups o RemoteApp groups
  3. Los usuarios externos ya pueden iniciar sesión en AVD con la Windows App o con los clientes de Escritorio remoto compatibles

Paso 4: aplicar gobernanza y acceso condicional

  • Usa Entra Governance (paquetes de acceso, directivas de ciclo de vida) para gestionar el ciclo de vida de los invitados
  • Aplica directivas de acceso condicional que cubran a los usuarios externos (MFA, cumplimiento del dispositivo, acceso basado en riesgo)
  • Considera Entitlement Management para que los usuarios externos soliciten acceso mediante un flujo gobernado

Casos de uso

Acceso de partners y contratistas

Es el caso de uso más inmediato. Las organizaciones que trabajan con partners externos, proveedores o contratistas ahora pueden dar acceso a AVD sin exigir que esos usuarios tengan dominios de correo concretos. Configura una federación sin dominio con el IdP SAML del partner e invita a los usuarios por correo electrónico.

Fusiones y adquisiciones

Durante las transiciones de M&A, los empleados de la empresa adquirida a menudo necesitan acceso al entorno de AVD de la organización matriz antes de que termine la migración de dominios. La federación sin dominio cubre esa brecha: el IdP de la empresa adquirida se puede configurar como IdP sin dominio y los usuarios pueden acceder a AVD con sus credenciales actuales.

Organizaciones con varias marcas

Las organizaciones que operan varias marcas con dominios de correo diferentes pero con una infraestructura de identidad compartida pueden usar un único IdP sin dominio para dar acceso a AVD en todas las marcas sin configurar cada dominio por separado.

BYOD y plantillas entre organizaciones

Combina la federación sin dominio con el acceso condicional de Entra y las directivas de cumplimiento de dispositivos para ofrecer acceso controlado a AVD a usuarios con dispositivos administrados externos o dispositivos personales. La aplicación de directivas en el lado del servidor garantiza la seguridad sin depender de controles en el lado del cliente.

Consideraciones de seguridad

Aunque la federación sin dominio elimina los requisitos de coincidencia de dominio, no elimina las responsabilidades de seguridad:

  • Confía en el IdP, no en el dominio: tu perímetro de seguridad es ahora la relación de confianza con el IdP SAML, no la verificación del dominio. Asegúrate de que confías en el IdP con el que federas.
  • Un IdP sin dominio por tenant: es una restricción, pero también una barrera de protección. Elige con criterio qué IdP configuras como sin dominio.
  • El acceso condicional es fundamental: con identidades externas accediendo a AVD, asegúrate de que tus directivas de acceso condicional cubren a los usuarios invitados. Exige MFA, evalúa el riesgo de inicio de sesión y aplica el cumplimiento de dispositivos cuando proceda.
  • Gobernanza y ciclo de vida: usa Entra Governance para gestionar el ciclo de vida de los invitados. Los usuarios externos no deberían permanecer indefinidamente sin revisión.
  • Auditoría y supervisión: supervisa los registros de inicio de sesión de las autenticaciones de identidades externas. Vigila patrones inusuales procedentes del IdP federado.

Cómo encaja en la evolución de la identidad en AVD

Microsoft ha ido ampliando de forma constante la compatibilidad de identidades en Azure Virtual Desktop:

  • Septiembre de 2025: compatibilidad con identidades externas sin FSLogix (versión preliminar)
  • Noviembre de 2025: la compatibilidad con identidades externas alcanzó la disponibilidad general, con los contenedores de perfil de FSLogix en versión preliminar
  • Mayo de 2026: la compatibilidad de FSLogix con identidades solo en la nube y externas alcanzó la disponibilidad general
  • Junio de 2026: se añadió la compatibilidad con la federación sin dominio, que elimina la última barrera de coincidencia de dominio

Junto con funciones existentes como el SSO de Entra, el acceso condicional y los contenedores de perfil de FSLogix para identidades externas, AVD cuenta ahora con una propuesta completa para identidades externas. Las organizaciones pueden proporcionar de forma segura escritorios y aplicaciones virtuales a usuarios ajenos a su organización manteniendo los controles de gobernanza y seguridad.

Qué deberías hacer ahora

  1. Identifica los escenarios de identidades externas: determina dónde necesitan acceso a AVD los usuarios externos y si la federación sin dominio simplificaría tu configuración actual
  2. Evalúa tu panorama de IdP SAML: decide qué IdP externo debe configurarse como IdP sin dominio para tu tenant
  3. Planifica tu estrategia de gobernanza: define paquetes de acceso, directivas de ciclo de vida y reglas de acceso condicional para los usuarios externos antes de habilitar la función
  4. Haz un piloto con un partner: configura la federación sin dominio para una organización externa, invita a un grupo reducido de usuarios y valida el acceso a AVD de extremo a extremo
  5. Actualiza tu documentación: si tu equipo tiene procedimientos para la incorporación de usuarios externos, actualízalos para reflejar la nueva opción sin dominio

Resumen

La compatibilidad con la federación de IdP SAML sin dominio en Azure Virtual Desktop elimina un punto de fricción real que limitaba los escenarios de colaboración B2B. Al desacoplar el enrutamiento de la autenticación de la coincidencia de dominios de correo, Microsoft ha facilitado mucho dar acceso a AVD a partners, contratistas y plantillas de empresas adquiridas.

La configuración es sencilla: configura el IdP en Entra ID, invita a los usuarios por correo electrónico y asígnalos a los recursos de AVD. El trabajo real está en la gobernanza: asegurarte de tener las directivas de acceso condicional, la gestión del ciclo de vida y la supervisión adecuadas para las identidades externas que acceden a tu entorno de escritorios virtuales.

Si ya usas identidades externas con AVD, esto amplía lo que puedes hacer. Si has estado evitando los escenarios de identidades externas por la complejidad de la coincidencia de dominios, esto elimina esa barrera.

Kevin Kaminski es el propietario de Big Hat Group Inc., un partner de Microsoft centrado en tecnologías de IA y nube. Síguelo en https://x.com/kkaminsk para más novedades sobre Azure Virtual Desktop.