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 se debe ejecutar en las versiones desde Windows Server 2003 a Windows Server 2012 R2; esto no afecta al nivel funcional del dominio.

Este producto respalda 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 respalda 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.

Sugerencia

No cambie el nombre de equipo ni la pertenencia al dominio de un 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 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. La clave SupportMultipleForest solo es necesaria en el VDA. Use la información siguiente para agregar la clave de Registro:

Precaución: Si modifica el Registro de forma incorrecta, podrían generarse problemas graves que pueden provocar la reinstalación del 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.

  • HKEY_LOCAL_MACHINE \ Software \ Citrix \ VirtualDesktopAgent \ 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 un VDA de 32 bits o 64 bits, localice la clave del Registro HKEY_LOCAL_MACHINE\Software\Citrix\VirtualDesktopAgent\ListOfSIDs
    • Nombre: ListOfSIDs
    • Tipo: REG_SZ
    • Datos: identificador de seguridad (SID) de los Controllers

En caso de que haya relaciones de confianza con elementos externos, realice los siguientes cambios en el VDA:

  1. Localice el archivo <ProgramFiles>\Citrix\Virtual Desktop Agent\brokeragentconfig.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.

Active Directory