This content has been machine translated dynamically.
Dieser Inhalt ist eine maschinelle Übersetzung, die dynamisch erstellt wurde. (Haftungsausschluss)
Cet article a été traduit automatiquement de manière dynamique. (Clause de non responsabilité)
Este artículo lo ha traducido una máquina de forma dinámica. (Aviso legal)
此内容已经过机器动态翻译。 放弃
このコンテンツは動的に機械翻訳されています。免責事項
이 콘텐츠는 동적으로 기계 번역되었습니다. 책임 부인
Este texto foi traduzido automaticamente. (Aviso legal)
Questo contenuto è stato tradotto dinamicamente con traduzione automatica.(Esclusione di responsabilità))
This article has been machine translated.
Dieser Artikel wurde maschinell übersetzt. (Haftungsausschluss)
Ce article a été traduit automatiquement. (Clause de non responsabilité)
Este artículo ha sido traducido automáticamente. (Aviso legal)
この記事は機械翻訳されています.免責事項
이 기사는 기계 번역되었습니다.책임 부인
Este artigo foi traduzido automaticamente.(Aviso legal)
这篇文章已经过机器翻译.放弃
Questo articolo è stato tradotto automaticamente.(Esclusione di responsabilità))
Translation failed!
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 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 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. 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 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.
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. Esta entrada se puede utilizar en lugar de la entrada SupportMultipleForest, que se puede seguir utilizando 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:
- 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 para edición de texto, como por ejemplo el Bloc de notas.
- Busque
allowNtlm="false"y cambie el texto aallowNtlm="true". - 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 | Sí |
| Raíz del árbol | Transitiva | Bidireccional | Sí |
| Externa | No transitiva | 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 de Active Directory complejos, consulte CTX134971.
Compartir
Compartir
En este artículo
This Preview product documentation is Citrix Confidential.
You agree to hold this documentation confidential pursuant to the terms of your Citrix Beta/Tech Preview Agreement.
The development, release and timing of any features or functionality described in the Preview documentation remains at our sole discretion and are subject to change without notice or consultation.
The documentation is for informational purposes only and is not a commitment, promise or legal obligation to deliver any material, code or functionality and should not be relied upon in making Citrix product purchase decisions.
If you do not agree, select I DO NOT AGREE to exit.