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!
Active Directory joined
Active Directory is required for authentication and authorization. The Kerberos infrastructure in Active Directory is used to guarantee the authenticity and confidentiality of communications with the Delivery Controllers. For information about Kerberos, see the Microsoft documentation.
The System requirements article lists the supported functional levels for the forest and domain. To use Policy Modeling, the domain controller must be running on all supported Server OSs. This does not affect the domain functional level.
This product supports:
- Deployments in which the user accounts and computer accounts exist in domains in a single Active Directory forest. User and computer accounts can exist in arbitrary domains within a single forest. All domain functional levels and forest functional levels are supported in this type of deployment.
- Deployments in which user accounts exist in an Active Directory forest that is different from the Active Directory forest containing the computer accounts of the Controllers and virtual desktops. In this type of deployment, the domains containing the Controller and virtual desktop computer accounts must trust the domains containing user accounts. Forest trusts or external trusts can be used. All domain functional levels and forest functional levels are supported in this type of deployment.
- Deployments in which the computer accounts for Controllers exist in an Active Directory forest that is different from one or more additional Active Directory forests that contain the computer accounts of the virtual desktops. In this type of deployment a bi-directional trust must exist between the domains containing the Controller computer accounts and all domains containing the virtual desktop computer accounts. In this type of deployment, all domains containing Controller or virtual desktop computer accounts must be at “Windows 2000 native” functional level or higher. All forest functional levels are supported.
- Writable domain controllers. Read-only domain controllers are not supported.
Optionally, Virtual Delivery Agents (VDAs) can use information published in Active Directory to determine which Controllers they can register with (discovery). This method is supported primarily for backward compatibility, and is available only if the VDAs are in the same Active Directory forest as the Controllers. For information about this discovery method see Active Directory OU-based discovery and CTX118976.
Note:
Do not change the computer name or the domain membership of a Delivery Controller after the site is configured.
Deploy in a multiple Active Directory forest environment
In an Active Directory environment with multiple forests, if one-way or two-way trusts are in place you can use DNS forwarders or conditional forwarders for name lookup and registration. To allow the appropriate Active Directory users to create computer accounts, use the Delegation of Control wizard. See the Microsoft documentation for details about this wizard.
No reverse DNS zones are necessary in the DNS infrastructure if appropriate DNS forwarders are in place between forests.
The SupportMultipleForest key is necessary if the VDA and Controller are in separate forests, regardless of whether the Active Directory and NetBIOS names are different. Use the following information to add the registry key to the VDA and the Delivery Controllers:
Caution:
Editing the registry incorrectly can cause serious problems that might require you to reinstall your operating system. Citrix cannot guarantee that problems resulting from the incorrect use of Registry Editor can be solved. Use Registry Editor at your own risk. Back up the registry before you edit it.
On the VDA, configure: HKEY_LOCAL_MACHINE\Software\Citrix\VirtualDesktopAgent\SupportMultipleForest.
- Name:
SupportMultipleForest - Type:
REG_DWORD - Data:
0x00000001 (1)
On all Delivery Controllers, configure: HKEY_LOCAL_MACHINE\Software\Citrix\DesktopServer\SupportMultipleForest.
- Name:
SupportMultipleForest - Type:
REG_DWORD - Data:
0x00000001 (1)
You might need reverse DNS configuration if your DNS namespace is different than that of Active Directory.
A registry entry has been added to avoid unwanted enabling of NTLM authentication in VDAs, which is less secure than Kerberos. This entry can be used instead of the SupportMultipleForest entry, which can still be used for backwards compatibility.
On the VDA, configure: HKEY_LOCAL_MACHINE\Software\Policies\Citrix\VirtualDesktopAgent.
- Name:
SupportMultipleForestDdcLookup - Type:
REG_DWORD - Data:
0x00000001 (1)
This registry key performs a DDC lookup in a two-way trust multiple forest environment that allows you to remove NTLM-based authentication during the initial registration process.
If external trusts are in place during setup, the ListOfSIDs registry key is required. The ListOfSIDs registry key is also necessary if the Active Directory FQDN is different than the DNS FQDN, or if the domain containing the Domain Controller has a different NetBIOS name than the Active Directory FQDN. To add the registry key, use the following information:
For the VDA, locate the registry key HKEY_LOCAL_MACHINE\Software\Citrix\VirtualDesktopAgent\ListOfSIDs.
- Name:
ListOfSIDs - Type:
REG_SZ - Data: Security Identifier (SID) of the Controllers. (SIDs are included in the results of the
Get-BrokerControllercmdlet.)
When external trusts are in place, make the following change on the VDA:
- Locate the file
Program Files\Citrix\Virtual Desktop Agent\brokeragent.exe.config. - Make a backup copy of the file.
- Open the file in a text editing program such as Notepad.
- Locate the text
allowNtlm="false"and change the text toallowNtlm="true". - Save the file.
After adding the ListOfSIDs registry key and editing the brokeragent.exe.config file, restart the Citrix Desktop Service to apply the changes.
The following table lists the supported trust types:
| Trust type | Transitivity | Direction | Supported in this release |
|---|---|---|---|
| Parent and child | Transitive | Two-way | Yes |
| Tree-root | Transitive | Two-way | Yes |
| External | Nontransitive | One-way or two-way | Yes |
| Forest | Transitive | One-way or two-way | Yes |
| Shortcut | Transitive | One-way or two-way | Yes |
| Realm | Transitive or nontransitive | One-way or two-way | No |
For more information about complex Active Directory environments, see CTX134971.
Share
Share
In this article
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.