Citrix Virtual Apps and Desktops

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.

Este producto admite lo siguiente:

  • Implementaciones donde las cuentas de usuario y las cuentas de equipo existen en dominios de un único bosque 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.
  • Las implementaciones en las que las cuentas de usuario existen en un bosque Active Directory que es diferente al bosque Active Directory que contiene las cuentas de equipo de los Controllers y los escritorios virtuales. En este tipo de implementación, los dominios que contienen las cuentas de equipo de los escritorios virtuales y del Controller 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.
  • Las implementaciones en las que las cuentas de equipo para los Controllers existen en un bosque Active Directory que es diferente de al menos un bosque Active Directory adicional que contenga las cuentas de equipo de los escritorios virtuales. En este tipo de implementación, se requiere una relación de confianza bidireccional entre los dominios que contienen las cuentas de equipo de los Controllers y todos los dominios que contienen las cuentas de equipo de los escritorios virtuales. 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 que permiten la escritura. No se admiten controladores de dominio que sean 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

Esta información se aplica a XenDesktop 7.1 y XenApp 7.5 (versiones mínimas). No se aplica a versiones anteriores de XenDesktop o XenApp.

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. Use la información siguiente para agregar la clave de Registro:

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 la utilización inadecuada del Editor del Registro puedan resolverse. Si utiliza el Editor del Registro, será bajo su propia responsabilidad. 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.

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. Localice el archivo Program Files\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 text allowNtlm="false" y cambie el texto 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.

Active Directory