Active Directory
Active Directory es necesario para la autenticación y la autorización. La infraestructura Kerberos de Active Directory se utiliza para garantizar la autenticidad y la confidencialidad de las comunicaciones con los Delivery Controllers. Para obtener información sobre Kerberos, consulte la documentación de Microsoft.
El artículo Requisitos del sistema enumera los niveles funcionales admitidos para el bosque y el dominio. Para usar el modelado de directivas, el controlador de dominio debe ejecutarse en Windows Server 2003 a Windows Server 2012 R2. Esto no afecta al nivel funcional del dominio.
Este producto admite:
- Implementaciones en las que las cuentas de usuario y las cuentas 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. Todos los niveles funcionales de dominio y de bosque son compatibles con este tipo de implementación.
- Implementaciones en las que las cuentas de usuario existen en un bosque de Active Directory diferente del bosque de 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 Controllers y los escritorios virtuales deben confiar en los dominios que contienen las cuentas de usuario. Se pueden utilizar confianzas de bosque o confianzas externas. Todos los niveles funcionales de dominio y de bosque son compatibles con este tipo de implementación.
- Implementaciones en las que las cuentas de equipo de los Controllers existen en un bosque de Active Directory diferente de uno o varios 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 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 de Controller o de escritorio virtual deben tener un nivel funcional de “Windows 2000 nativo” o superior. Todos los niveles funcionales de bosque son compatibles.
- Controladores de dominio de escritura. Los controladores de dominio de solo lectura no son compatibles.
Opcionalmente, los Virtual Delivery Agents (VDA) pueden usar la información publicada en Active Directory para determinar con qué Controllers pueden registrarse (detección). Este método se admite principalmente por compatibilidad con versiones anteriores y solo está disponible si los VDA se encuentran en el mismo bosque de Active Directory que los Controllers. Para obtener información sobre este método de detección, consulte Detección basada en OU de Active Directory y CTX118976.
Nota:
No cambie el nombre del equipo ni la pertenencia al dominio de un Delivery Controller™ después de configurar el sitio.
Implementar en un entorno de varios bosques de Active Directory
Esta información se aplica a la versión mínima XenDesktop 7.1 y XenApp 7.5. No se aplica a versiones anteriores de XenDesktop o XenApp.
En un entorno de Active Directory con varios bosques, si existen confianzas unidireccionales o bidireccionales, puede utilizar reenviadores DNS o reenviadores condicionales para la búsqueda y el registro de nombres. Para permitir que los usuarios de Active Directory adecuados creen cuentas de equipo, utilice el asistente Delegación de control. Consulte la documentación de Microsoft para obtener más detalles sobre este asistente.
No se necesitan zonas DNS inversas en la infraestructura DNS si existen reenviadores DNS adecuados entre los bosques.
La SupportMultipleForest clave es necesaria si el VDA y el Controller están en bosques separados, independientemente de si los nombres de Active Directory y NetBIOS son diferentes. Utilice la siguiente información para agregar la clave de registro al VDA y a los Delivery Controllers:
Precaución:
La edición incorrecta del registro puede causar problemas graves que podrían requerir la reinstalación del sistema operativo. Citrix® no puede garantizar que los problemas resultantes del uso incorrecto del Editor del Registro puedan resolverse. Utilice el Editor del Registro bajo su propia responsabilidad. Realice una copia de seguridad del registro antes de editarlo.
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 necesite una configuración de DNS inverso si su espacio de nombres DNS es diferente al de Active Directory.
Se ha añadido una entrada de registro para evitar la habilitación no deseada de la autenticación NTLM en los VDA, que es menos segura que Kerberos. Esta entrada se puede utilizar en lugar de la entrada SupportMultipleForest, que todavía se puede usar para 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 varios bosques con confianza bidireccional que le permite eliminar la autenticación basada en NTLM durante el proceso de registro inicial.
Si hay confianzas externas durante la configuración, la clave de registro ListOfSIDs es necesaria. La clave de registro ListOfSIDs también es necesaria si el FQDN de Active Directory es diferente del FQDN de DNS, o si el dominio que contiene el controlador de dominio tiene un nombre NetBIOS diferente al FQDN de Active Directory. Para agregar la clave de registro, utilice la siguiente información:
Para el VDA, localice la clave de registro HKEY_LOCAL_MACHINE\Software\Citrix\VirtualDesktopAgent\ListOfSIDs.
- Nombre:
ListOfSIDs - Tipo:
REG_SZ - Datos: Identificador de seguridad (SID) de los controladores. (Los SID se incluyen en los resultados del cmdlet
Get-BrokerController.)
Cuando existan confianzas externas, realice el siguiente cambio en el VDA:
- Localice el archivo
Program Files\Citrix\Virtual Desktop Agent\brokeragent.exe.config. - Haga una copia de seguridad del archivo.
- Abra el archivo en un programa de edición de texto como el Bloc de notas.
- Localice el texto
allowNtlm="false"y cámbielo porallowNtlm="true". - Guarde el archivo.
Después de agregar la clave de registro ListOfSIDs y editar el archivo brokeragent.exe.config, reinicie el servicio Citrix Desktop Service para aplicar los cambios.
La siguiente tabla enumera los tipos de confianza admitidos:
| Tipo de confianza | Transitivismo | Dirección | Compatible con esta versión |
|---|---|---|---|
| Primario y secundario | Transitivo | Bidireccional | Sí |
| Raíz de árbol | Transitivo | Bidireccional | Sí |
| Externo | No transitivo | Unidireccional o bidireccional | Sí |
| Bosque | Transitiva | Unidireccional o bidireccional | Sí |
| Acceso directo | Transitiva | Unidireccional o bidireccional | Sí |
| Dominio | Transitiva o no transitiva | Unidireccional o bidireccional | No |
Para obtener más información sobre entornos complejos de Active Directory, consulte CTX134971.