Product Documentation

Recommendations for Active Directory Environments

Oct 09, 2015
Citrix recommends the following configuration for server farms with Active Directory:
  • XenApp servers are in their own Organizational Units (OUs).
  • Create OUs for application silos, keeping servers from different silos organized in their own OUs. (You can, however, create application silos that span multiple OUs.)
  • All servers reside in the same domain.
  • The server farm domain has no trust relationships with non-Active Directory domains, as this can affect operations requiring trusted domains.
  • The server farm is in a single Active Directory forest. If your farm has servers in more than one forest, users cannot log on by entering user principal names (UPNs).
    UPN logons use the format username@UPN identifier. With Active Directory, UPN logons do not require a domain to be specified, because Active Directory can locate full UPN logons in the directory. However, if the server farm has multiple forests, problems occur if the same UPN identifier exists in two domains in separate forests.
    Important: Citrix XenApp does not support UPN logons if a server farm spans multiple Active Directory forests.

Active Directory User Permission

Active Directory security groups can affect authenticating to published applications or the management console. The tables that follow contain best practice guidance.

Also, if a user is a member of a domain local group, the group is in the user’s security token only when the user logs onto a computer in the same domain as the domain local group. Trust-based routing does not guarantee that a user’s logon request is sent to a server in the same domain as the domain local group.

Network configurations do not affect authentication to the management console because that console allows only pass-through authentication.

Domain Global Groups  
Authenticating to published applications No adverse effects
Authenticating to management console No adverse effects
Domain Local Groups  
Authenticating to published applications Recommendation: All servers that load balance an application must be in the same domain if a domain local group is authorized to use the application.

Rationale: Domain local groups assigned to an application must be from the common primary domain of all the load balancing servers. When you publish applications, domain local groups appear in the accounts list if the condition above is met and accounts from the common primary domain are displayed. If a published application has users from any domain local groups and you add a server from a different domain, domain local groups are removed from the configured users list, because all servers must be able to validate any user with permission to run the application.

Authenticating to management console Recommendation: If a user is a Citrix administrator only by membership in a domain local group, the user must connect the console to a server in the same domain as the domain local group.

Rationale: If the user connects the console to a server in a different domain than the domain local group, the user is denied access to the console because the domain local group is not in the user’s security token.

Universal Groups  
Authenticating to published applications Recommendation: If universal groups are assigned permission to the application, all servers that manage the application must be in an Active Directory domain.

Rationale: A server in a non-Active Directory domain could authenticate the user to run the application. In this case, universal groups are not in the user’s security token, so the user is denied access to the application. It is possible for a server in a non-Active Directory domain to load balance an application with servers in an Active Directory domain if the domains have an explicit trust relationship.

Authenticating to management console Recommendation: If a user is authenticating to the console and is a Citrix administrator only by membership in a universal group, the console must connect to a server that belongs to an Active Directory domain in the universal group’s forest.

Rationale: Non-Active Directory domain controllers and domains outside a universal group’s forest have no information about the universal group.

Active Directory Federated Services

XenApp supports Active Directory Federated Services (AD FS) when used with the Citrix Web Interface. If you need to provide a business partner with access to published applications, AD FS might be a better alternative than creating multiple new user accounts on the enterprise domain. If you plan to use AD FS with XenApp, Citrix recommends:
  • When installing XenApp on each server in your farm, ensure the port sharing with IIS option and ensure that IIS is configured to support HTTPS; see System Requirements for more information.
  • Set up a trust relationship between the server running the Web Interface and any other servers in the farm communicating with the Web Interface through the Citrix XML Broker. The Web Interface must be able to access the certificate revocation list (CRL) for the Certificate Authority used by the federation servers.
  • If you are provisioning the farm by imaging, configure trust requests on the server before you take the image. These trust requests must be enabled on each server in the farm and cannot be set at a farm level.
  • To prevent external users from having unauthorized access to services on farm servers, configure all XenApp servers for constrained delegation. To provide users with access to resources on those servers, add the relevant services to the Services list using the MMC Active Directory Users and Computers snap-in.

For more information about configuring support for AD FS, see the Web Interface documentation.