Citrix Virtual Apps and Desktops

Unidos a Azure Active Directory

Para la autenticación y la autorización es necesario usar Active Directory. La infraestructura de Kerberos en Active Directory se usa para garantizar la autenticidad y confidencialidad de las comunicaciones con los Delivery Controllers. Para obtener más información sobre Kerberos, consulte la documentación de Microsoft.

En el artículo Requisitos del sistema, se ofrece una lista de los niveles funcionales admitidos para el dominio y el bosque. Para usar el modelado de directivas, el controlador de dominio debe ejecutarse en todos los sistemas operativos de servidor compatibles. Esto no afecta al nivel funcional del dominio.

Este producto admite lo siguiente:

  • Implementaciones en las que las cuentas de usuario y de equipo existen en dominios de un único bosque de Active Directory. Las cuentas de usuario y de equipo pueden existir en dominios arbitrarios dentro de un único bosque. En este tipo de implementación se admiten todos los niveles funcionales de dominio y bosque.
  • Implementaciones en las que las cuentas de usuario existen en un bosque de Active Directory que es diferente del bosque de Active Directory que contiene las cuentas de equipo de los controladores y los escritorios virtuales. En este tipo de implementación, los dominios que contienen las cuentas de equipo de controlador y escritorio virtual deben confiar en los dominios que contienen las cuentas de usuario. Se pueden utilizar relaciones de confianza de bosque o externas. En este tipo de implementación se admiten todos los niveles funcionales de dominio y bosque.
  • Implementaciones en las que las cuentas de equipo de los controladores existen en un bosque de Active Directory que es diferente de uno o más bosques de Active Directory adicionales que contienen las cuentas de equipo de los escritorios virtuales. En este tipo de implementación, debe existir una confianza bidireccional entre los dominios que contienen las cuentas de equipo de controlador y todos los dominios que contienen las cuentas de equipo de escritorio virtual. En este tipo de implementación, todos los dominios que contienen cuentas de equipo para los escritorios virtuales o para Controller deben tener un nivel funcional “Windows 2000 nativo” o superior. Se admiten todos los niveles funcionales de bosque.
  • Controladores de dominio con capacidad de escritura. No se admiten controladores de dominio de solo lectura.

Opcionalmente, los Virtual Delivery Agent (VDA) pueden usar la información publicada en Active Directory para determinar en qué Controllers se pueden registrar (detección). Este método se ofrece principalmente con fines de compatibilidad con versiones anteriores, y solo está disponible si los VDA y los Controllers se encuentran en el mismo bosque de Active Directory. Para obtener información acerca de este método de detección, consulte Detección de Controllers basada en unidades organizativas de Active Directory y CTX118976.

Nota:

No cambie el nombre de equipo ni la pertenencia al dominio de un Delivery Controller™ una vez configurado el sitio.

Implementación en un entorno de Active Directory de varios bosques

En un entorno de Active Directory con varios bosques, si hay confianza unidireccional o bidireccional, se pueden usar reenviadores DNS o condicionales para la búsqueda de nombres y registros. Para permitir que los usuarios correspondientes de Active Directory puedan crear cuentas de equipo, use el Asistente para delegación de control. Consulte la documentación de Microsoft para obtener información sobre este asistente.

No se necesitan zonas DNS inversas en la infraestructura DNS si se incluyen los reenviadores DNS adecuados entre los bosques.

La clave SupportMultipleForest es necesaria si el VDA y el Controller se encuentran en bosques separados, independientemente de si los nombres de Active Directory y NetBIOS son diferentes. Utilice la siguiente información para agregar la clave del Registro al VDA y a los Delivery Controllers:

Precaución:

Si se modifica el Registro de forma incorrecta, pueden producirse problemas graves que obliguen a reinstalar el sistema operativo. Citrix® no puede garantizar que los problemas derivados de un uso inadecuado del Editor del Registro puedan resolverse. Utilice el Editor del Registro bajo su propio riesgo. Haga una copia de seguridad del Registro antes de modificarlo.

En el VDA, configure: HKEY_LOCAL_MACHINE\Software\Citrix\VirtualDesktopAgent\SupportMultipleForest.

  • Nombre: SupportMultipleForest
  • Tipo: REG_DWORD
  • Datos: 0x00000001 (1)

En todos los Delivery Controllers, configure: HKEY_LOCAL_MACHINE\Software\Citrix\DesktopServer\SupportMultipleForest.

  • Nombre: SupportMultipleForest
  • Tipo: REG_DWORD
  • Datos: 0x00000001 (1)

Es posible que sea necesaria la configuración de DNS inversa si el espacio de nombres DNS es diferente del de Active Directory.

Se ha agregado una entrada del Registro para evitar la habilitación no deseada de la autenticación NTLM en los VDA, que es menos segura que Kerberos. Se puede usar esta entrada en lugar de la entrada SupportMultipleForest, que se puede seguir usando para garantizar la compatibilidad con versiones anteriores.

En el VDA, configure: HKEY_LOCAL_MACHINE\Software\Policies\Citrix\VirtualDesktopAgent.

  • Nombre: SupportMultipleForestDdcLookup
  • Tipo: REG_DWORD
  • Datos: 0x00000001 (1)

Esta clave de Registro realiza una búsqueda de DDC en un entorno de confianza bidireccional de varios bosques que le permite quitar la autenticación basada en NTLM durante el proceso de registro inicial.

Si existen confianzas externas durante la instalación, se necesita la clave del Registro ListOfSIDs. La clave del Registro ListOfSIDs también es necesaria si el FQDN de Active Directory difiere del FQDN de DNS o si el dominio que contiene el controlador de dominio tiene un nombre de NetBIOS que difiere del FQDN de Active Directory. Para agregar la clave del Registro, utilice la siguiente información:

Para el VDA, busque la clave de Registro HKEY_LOCAL_MACHINE\Software\Citrix\VirtualDesktopAgent\ListOfSIDs.

  • Nombre: ListOfSIDs
  • Tipo: REG_SZ
  • Datos: identificador de seguridad (SID) de los Controllers (Los SID se incluyen en los resultados del cmdlet Get-BrokerController).

En caso de que haya relaciones de confianza con elementos externos, realice el siguiente cambio en el VDA:

  1. Busque el archivo Archivos de programa\Citrix\Virtual Desktop Agent\brokeragent.exe.config.
  2. Haga una copia de seguridad del archivo.
  3. Abra el archivo en un programa para edición de texto, como por ejemplo el Bloc de notas.
  4. Busque el texto allowNtlm="false" y cámbielo a allowNtlm="true".
  5. Guarde el archivo.

Después de agregar la clave del Registro ListOfSIDs y de modificar el archivo brokeragent.exe.config, reinicie Citrix Desktop Service para aplicar los cambios.

La siguiente tabla muestra los tipos de confianza admitidos:

Tipo de confianza Transitividad Dirección Se admite en esta versión
Elemento primario y secundario Transitiva Bidireccional
Raíz del árbol Transitiva Bidireccional
Externa No transitiva Unidireccional o bidireccional
Bosque Transitiva Unidireccional o bidireccional
Acceso directo Transitiva Unidireccional o bidireccional
Dominio Transitiva o no transitiva Unidireccional o bidireccional No

Para obtener más información sobre entornos de Active Directory complejos, consulte CTX134971.

Qué hacer a continuación

Para obtener información sobre cómo crear un grupo de identidades de máquinas unidas a una instancia de Active Directory (AD) local, consulte Grupo de identidades de la identidad de la máquina unida a Active Directory local.

Unidos a Azure Active Directory