Varios bosques con AD DS y Microsoft Entra ID

Muchas organizaciones quieren aprovechar Azure Virtual Desktop para crear entornos que tengan varios bosques de Active Directory local.

En este artículo se amplía la arquitectura que se describe en el artículo Azure Virtual Desktop a escala empresarial. Está pensado para ayudarle a comprender cómo integrar varios dominios y Azure Virtual Desktop mediante Microsoft Entra Connect para sincronizar usuarios desde Active Directory Domain Services (AD DS) a Microsoft Entra ID.

Arquitectura

Descargue un archivo Visio de esta arquitectura.

Flujo de datos

En esta arquitectura, el flujo de identidad funciona de la siguiente manera:

1. Microsoft Entra Connect sincroniza los usuarios de CompanyA.com y CompanyB.com con el inquilino de Microsoft Entra (NewCompanyAB.onmicrosoft.com).
2. Los grupos de hosts, las áreas de trabajo y los grupos de aplicaciones se crean en suscripciones y redes virtuales de radio separadas.
3. Los usuarios se asignan a los grupos de aplicaciones.
4. Los hosts de sesión de Azure Virtual Desktop de los grupos de hosts se unen a los dominios CompanyA.com y CompanyB.com con los controladores de dominio (DC) de Azure.
5. Los usuarios inician sesión mediante la aplicación de Azure Virtual Desktop o el cliente web con un nombre principal de usuario (UPN) en el siguiente formato: user@NewCompanyA.com, user@CompanyB.como user@NewCompanyAB.com, en función de su sufijo UPN configurado.
6. Se presentan a los usuarios sus respectivas aplicaciones o escritorios virtuales. Por ejemplo, se presenta a los usuarios de CompanyA escritorios virtuales o aplicaciones del área de trabajo A y el grupo de hosts 1 o 2.
7. Los perfiles de usuario de FSLogix se crean en recursos compartidos de Azure Files en las cuentas de almacenamiento correspondientes.
8. Directiva de grupo objetos (GPO) que se sincronizan desde el entorno local se aplican a los usuarios y a los hosts de sesión de Azure Virtual Desktop.

Componentes

Esta arquitectura usa los mismos componentes que los enumerados en Azure Virtual Desktop a escala empresarial.

Adicionalmente, esta arquitectura utiliza los siguientes componentes:

• Microsoft Entra Connect en modo de almacenamiento provisional: el servidor de almacenamiento provisional para topologías de Microsoft Entra Connect proporciona redundancia adicional para la instancia de Microsoft Entra Connect.

• Suscripciones de Azure, áreas de trabajo de Azure Virtual Desktop y grupos de hosts: puede usar varias suscripciones, áreas de trabajo de Azure Virtual Desktop y grupos de hosts para los límites de administración y los requisitos empresariales.

Detalles del escenario

Este diagrama de arquitectura representa un escenario típico que contiene los siguientes elementos:

• El inquilino de Microsoft Entra está disponible para una nueva empresa denominada NewCompanyAB.onmicrosoft.com.
• Microsoft Entra Connect sincroniza los usuarios de AD DS local con Microsoft Entra ID.
• La empresa A y la empresa B tienen suscripciones de Azure independientes. También tienen una suscripción de servicios compartidos a los que se hace referencia como Suscripción 1 en el diagrama.
• Una arquitectura en estrella tipo hub-and-spoke de Azure se implementa con una red virtual de centro de servicios compartidos.
• Existen complejos entornos locales de Active Directory híbridos con dos o más bosques de Active Directory. Los dominios residen en bosques independientes, cada uno con un sufijo de UPN diferente. Por ejemplo, CompanyA.local con el sufijo de UPN CompanyA.com, CompanyB.local con el sufijo de UPN CompanyB.com y el sufijo de UPN adicional NewCompanyAB.com.
• Los controladores de dominio de ambos bosques se encuentran en el entorno local y en Azure.
• Los dominios verificados están presentes en Azure para CompanyA.com, CompanyB.com y NewCompanyAB.com.
• Se usa GPO y autenticación heredada, como Kerberos, NTLM (Windows New Technology LAN Manager) y LDAP (Protocolo ligero de acceso a directorios).
• Para los entornos de Azure que todavía tienen una infraestructura local de dependencia, conectividad privada (VPN de sitio a sitio o Azure ExpressRoute) se configuran entre el entorno local y Azure.
• El entorno de Azure Virtual Desktop consta de un área de trabajo de Azure Virtual Desktop para cada unidad de negocio y dos grupos de hosts por área de trabajo.
• Los hosts de sesión de Azure Virtual Desktop se unen a los controladores de dominio de Azure. Es decir, los hosts de sesión de CompanyA se unen al dominio CompanyA.local y los hosts de sesión de CompanyB se unen al dominio CompanyB.local.
• Las cuentas de Azure Storage pueden usar Azure Files para perfiles de FSLogix. Se crea una cuenta por dominio de la compañía (es decir, CompanyA.local y CompanyB.local) y la cuenta se une al dominio correspondiente.

Posibles casos de uso

Estos son algunos casos de uso relevantes para esta arquitectura:

• Fusiones y adquisiciones, personalización de marca de la organización y varias identidades locales
• Entornos activos de Active Directory locales complejos (varios bosques, dominios múltiples, requisitos de directiva de grupo (o GPO) y autenticación heredada)
• Infraestructura de GPO local con Azure Virtual Desktop

Consideraciones

Al diseñar la carga de trabajo en función de esta arquitectura, tenga en cuenta las siguientes ideas.

Objetos de directiva de grupo

• Para ampliar la infraestructura de GPO para Azure Virtual Desktop, los controladores de dominio locales deben sincronizarse con los controladores de dominio de infraestructura como servicio (IaaS) de Azure.

• La extensión de la infraestructura de GPO a los controladores de dominio de IaaS de Azure requiere conectividad privada.

Red y conectividad

• Los controladores de dominio son componentes compartidos, por lo que deben implementarse en una red virtual del centro de servicios compartidos en esta arquitectura en estrella tipo hub-and-spoke.

• Los hosts de sesión de Azure Virtual Desktop se unen al controlador de dominio en Azure mediante su respectivo emparejamiento de red virtual en estrella tipo hub-and-spoke.

Azure Storage

Las siguientes consideraciones de diseño se aplican a los contenedores de perfiles de usuario, contenedores de caché en la nube y paquetes MSIX:

• Puedes usar tanto Azure Files como Azure NetApp Files en este escenario. Tu escoges la solución adecuada en función de factores como el rendimiento esperado, el costo, etc.

• Tanto las cuentas de Azure Storage como los archivos de Azure NetApp están limitados a unirse a un único AD DS a la vez. En estos casos, se requieren varias cuentas de Azure Storage o instancias de Azure NetApp Files.

Microsoft Entra ID

En escenarios con usuarios en varios bosques locales de Active Directory, solo un servidor de sincronización de Microsoft Entra Connect está conectado al inquilino de Microsoft Entra. Una excepción a esto es un servidor de Microsoft Entra Connect que se utiliza en modo de almacenamiento provisional.

Se admiten las siguientes topologías de identidad:

• Varios bosques locales de Active Directory.
• Uno o varios bosques de recursos confían en todos los bosques de cuentas.
• Una topología de malla completa permite a los usuarios y recursos estar en cualquier bosque. Normalmente, hay una relación de confianza bidireccional entre los bosques.

Para más información, consulte la sección sobre el servidor de almacenamiento provisional de las topologías de Microsoft Entra Connect.

Colaboradores

Microsoft mantiene este artículo. Originalmente lo escribieron los siguientes colaboradores.

Autor principal:

• Tom Maher | Ingeniero sénior de seguridad e identidad

Pasos siguientes

Para más información, consulte los siguientes artículos.

• Topología de Microsoft Entra Connect
• Comparar diferentes opciones de identidad: Active Directory Domain Services (AD DS), Microsoft Entra ID y Microsoft Entra Domain Services
• Documentación de Azure Virtual Desktop

Recursos relacionados

• Azure Virtual Desktop para la empresa
• Idea de solución: varios bosques con Microsoft Entra Domain Services