Product Documentation

Active Directory

May 03, 2015

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.

You need any of these functional levels for the forest and domain:

  • Windows 2000 native
  • Windows Server 2003
  • Windows Server 2008
  • Windows Server 2008 R2
  • Windows Server 2012
  • Windows Server 2012 R2

To use Policy Modeling, the domain controller must be running on a server whose operating system is 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 Controller discovery and CTX118976.

Deploy in a multiple forest Active Directory environment

Updated: 2014-05-29

Note: 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 for name lookup and registration. To allow the appropriate Active Directory users to create computer accounts, use the Delegation of Control wizard. Refer to Microsoft documentation for more information about this wizard.

No reverse DNS zones are necessary in DNS infrastructure if appropriate DNS forwarders are in place between forests.

In this release, the SupportMultipleForest key is necessary if the Virtual Delivery Agent (VDA) and Delivery Controller are in separate forests, regardless of whether the Active Directory and NetBios names are different. The SupportMultipleForest key is only necessary on the VDA. Use the following information to add the registry key:
  • HKEY_LOCAL_MACHINE\Software\Citrix\VirtualDesktopAgent\SupportMultipleForest
    • Name: SupportMultipleForest
    • Type: REG_DWORD
    • Data: 0x00000001 (1)

Set the value to 1.

You might need reverse DNS configuration if your DNS namespace is different than that of Active Directory.

Caution: Editing the registry incorrectly can cause serious problems that may 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. Be sure to back up the registry before you edit it.
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 a 32-bit or 64-bit VDA, locate the registry key: HKEY_LOCAL_MACHINE\Software\Citrix\VirtualDesktopAgent\ListOfSIDs
    • Name: ListOfSIDs
    • Type: REG_SZ
    • Data: Security Identifier (SID) of the Controllers

To obtain your domain SID, use ADExplorer or XDPing.

When external trusts are in place, you will also need to make the following changes on the VDA:
  1. Locate the file <ProgramFiles>\Citrix\Virtual Desktop Agent\brokeragentconfig.exe.config
  2. Make a backup copy of the file
  3. Open the file in a text editing program such as Notepad
  4. Locate the text allowNtlm="false" and change the text to allowNtlm="true"
  5. Save the file

After the ListOfSIDs registry key has been added and the brokeragent.exe.config file has been edited, you will need to restart the Citrix Desktop Service so that the changes will be applied.

The following table indicates which trust types are supported:
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.