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 Windows Server 2003 to Windows Server 2012 R2. 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.
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
This information applies to minimum version XenDesktop 7.1 and XenApp 7.5. It does not apply to earlier versions of XenDesktop or XenApp.
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.
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:
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:
On all Delivery Controllers, configure:
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:
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
- Data: Security Identifier (SID) of the Controllers. (SIDs are included in the results of the
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 to
- 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|
|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.