For more information about Identity Sources in vSphere 5.5, see the Identity Sources for vCenter Server with vCenter Single Sign-On section of the vSphere Installation and Setup guide.

 

For more information about the different trust types and to verify the trust transitivity to see if your vSphere environment is affected, see these Microsoft TechNet articles:

 

Depending on the type of Microsoft Active Directory trusts used in an environment, some features, such as Active Directory user querying and user authentication, may be limited from the vSphere Client and vSphere Web Client.

 

Note: This article is applicable to :

• vCenter Single Sign-On (SSO) 5.5 and Platform Services Controller (PSC) 6.0 on a Windows platform
• vCenter Server Appliance (vCSA) (6.0 and later) with Embedded vCenter Single Sign-On 5.5 and with Embedded Platform Services Controller 6.0
• vRealize Automation Identity Appliance (vRA IA).
• vCSA 6.5 with external PSC(s) 6.5

Due to Windows-based SSO and PSC using native Kerberos while the vCenter Server Appliance and the vRealize Automation (formerly known as vCloud Automation Center) Identity Appliance using Likewise-based Kerberos, there are topology limitations with the vCSA and vRA IA.

This article provides diagrammatic representations and detailed information on:

This table lists the legends or icons used in this article and the corresponding definitions:

 

Icon	Definition
	This object represents an Active Directory domain. For more information about Active Directory version requirements, see the Identity Sources for vCenter Server with vCenter Single Sign-On section of the vSphere Installation and Setup guide.
	This object represents either vCenter Server 5.5 along with all other vSphere 5.5 components installed on a single virtual machine or physical server or the vRealize Automation (formerly known as vCloud Automation Center) Identity Appliance. For vSphere 5.5 instances, this includes: vCenter Server vCenter Server Single Sign-On vCenter Inventory Service vSphere Web Client If different components of vSphere 5.5 are installed on separate systems, they must all be on the same network subnet and in the same Active Directory domain as the vCenter Server and vCenter Single Sign-On service.
	This object represents the vCenter Server and vCenter Single Sign-On service being joined to a specific Active Directory domain. The vCenter Single Sign-On is configured with as Active Directory (Integrated Windows Authentication) identity source for that specific domain using the Machine Account as the service principal account.
	This object represents a two-way transitive or nontransitive trust between two objects within an Active Directory infrastructure
	This object represents a one-way transitive or nontransitive trust between two objects within an Active Directory infrastructure Depending on the direction in which the arrow is represented in the diagram, this will indicate where the inter- or extra-forest trust originates from. The Square-Site of the icon represents the trustee, or the object that has initiated the trust. The Arrow-Side of the icon represents the object being trusted.

 

As all Parent-Child domains use transitive two-way trusts by default, vCenter Server and vCenter Single Sign-On can exist either in the parent domain or the child domain and can access all users from either domain. Also, if there is another Child domain, for example Child Domain B, within the forest, due to the use of native Active Directory APIs and the two-way trust, you can add users from the other Child domain.

 

 

 

 

If a two-way or one-way Shortcut transitive trust exists between child domains, both the Parent-Child trust and the Shortcut trust can still be leveraged to access the user from the other child domain. If a one-way Shortcut trust is used, the Parent-Child trust is leveraged to query and access the other Child domain.

 

 

 

If Tree-Root trusts exist as two-way transitive trusts between two parent domains, vCenter Server and vCenter Single Sign-On can exist in one Parent Domain and can access all users from another Parent domain. If the other parent domain, for example Parent Domain B, has a Child domain, due to the two-way trust, those users are also accessible.

 

In this example, vCenter Server exists in Parent Domain A and can be set up in Parent Domain A, Child Domain A, or Child Domain B and can still access all users from Parent Domain B and Child Domain C due to the use of two-way trusts between all domains.

 

Domain Configurations existing across Forests

There are multiple ways in which a Forest trust can be configured and exist between separate forests within an environment. A Forest trust is a complete trust between two separate forests that can share resources. With a Forest trust established, all Parent and Child domains between the forests can be accessed, depending on the configuration used. This means that if you have multiple Parent Domains within a separate Forest that is trusted, vCenter Server can see all Parent domains if the proper trusts are configured.

 

 

 

• Due to the use of LDAP Query API that requires a bidirectional trust to be established from the Forest B back to Forest A the API does not function properly. Since the configuration is a one-way (unidirectional) trust, this query does not work. This prevents users from performing the following:
  • Fully displaying users in both the vSphere Web Client and vSphere Client, when accessing users from the other forest.
  • Being able to log in using the Use Windows Sessions Credentials (GSSAPI) method on first attempt. For more information see, Logging into VMware vCenter Server using Windows session credentials fails if VMware vCenter Server is not a member of the same domain (2070029). Once a user has manually logged into the vSphere Web Client or vSphere Client, the vCenter Single Sign-On server caches this information for subsequent logins. Due to this caching, customers may be able to use the Use Windows Session Credentials authentication method via either of the clients to log in until the vCenter Single Sign-On server has been restarted. Once the vCenter Single Sign-On server has been restarted, this will clear the cache.
• Due to the trust only being established with Domain B's Root domain, you cannot enumerate any of the child domains' users and users from Child Domain B so users cannot be added.
• For the vCenter Server Appliance and vRA IA (in the latter diagram): Due to the additional Tree-Root forest hop from Child Domain A via Parent Domain B's Root domain, after the parent-child trust hop from from Child Domain A to Parent Domain A you cannot enumerate or authenticate any of the users from Forest B's domain. This only applies when the vCenter Server Appliance is in a child domain requiring more than one Parent Domain hop to another domain.

 

 

The use of a one-way Forest trust to the forest where vCenter Server exists from a separate Forest does not work. A trust is always required to be established from the Forest where vCenter Server exists to the separate forest, so that the users can be accessed. In this example, vCenter Server can only access users from Forest A.

 

 

 

There are multiple ways in which an External trust can be configured and exist between a separate or legacy domain within an environment. An External trust can be configured to establish a specific trust to a specific domain within a separate Forest that is not joined via a Forest Trust. An External trust can also be configured to establish a trust with a legacy (Windows NT 4.0) domain. The limitations for External trusts are similar to Forest trusts. The following examples provide any limitations that currently exist on specific External trust configurations.

 

 

• Due to the use of LDAP Query API which requires a bidirectional trust to be established from the separate domain back to Forest A, the API does not function properly. Since the configuration is a one-way (unidirectional) trust, this query does not work. Since the configuration is a one-way (unidirectional) trust, this query does not work. This prevents users from performing the following:
  • Fully displaying users in both the vSphere Web Client and vSphere Client, when accessing users from the other forest.
  • Being able to log in using the Use Windows Sessions Credentials (GSSAPI) method on first attempt. For more information see, Logging into VMware vCenter Server using Windows session credentials fails if VMware vCenter Server is not a member of the same domain (2070029). Once a user has manually logged into the vSphere Web Client or vSphere Client, the vCenter Single Sign-On server caches this information for subsequent logins. Due to this caching, customers may be able to use the Use Windows Session Credentials authentication method via either of the clients to log in until the vCenter Single Sign-On server has been restarted. Once the vCenter Single Sign-On server has been restarted, this will clear the cache.
• Due to the trust only being established with the stand-alone domain's Root, you cannot enumerate any of the child domains' users. If there is a child domain attached to the external trust, the users from the child domain cannot be added according to the preceding example.
• For the vCenter Server Appliance and vRA IA (in the latter diagram): Due to the additional Tree-Root forest hop from Child Domain A via Parent Domain B's Root domain, after the parent-child trust hop from from Child Domain A to Parent Domain A you cannot enumerate or authenticate any of the users from the stand-alone domain. This only applies when the vCenter Server Appliance is in a child domain requiring more than one Parent Domain hop to another domain.

 

 

 

The use of a one-way External trust to the Forest where vCenter Server exists from a separate, Stand-Alone Domain does not function. A trust is always required to be established from the Forest where vCenter Server exists to the separate domain, so that the users can be accessed. In this example, vCenter Server can only access users from Forest A.

 

 

 

Currently, the use of Realm Trusts with vCenter Single Sign-On is not supported.

The following ports are required for proper communications between the SSO system when using using an Active Directory (Integrated Windows Authentication) identity source and all Active Directory Domain Controllers who's domain need to be accessed.

 

Port	Protocol	Usage
53	UDP/TCP	DNS
88	UDP/TCP	Kerberos
123	UDP	NTP, Trusts
135	UDP/TCP	RPC Endpoint Mapper
137	UDP	NetBIOS Name Service
139	TCP	NetBIOS Sessions (SMB)
389	UDP/TCP	LDAP
445	TCP	SMB over TCP
464	UDP/TCP	Machine password changes
636	TCP	LDAP (SSL)
3268	TCP	Global Catalog Search
3269	TCP	Global Catalog Search (SSL)

For more information about Kerberos authentication, the types of traffic each port provides and cross-domain connectivity, see:

• For Appliance-based SSO systems, see the Ports and Libraries section of the Likewise Enterprise Installation and Administration Guide.
• For Windows-based SSO systems, see the Communication to Domain Controllers section of the Microsoft Article Active Directory and Active Directory Domain Services Port Requirements.

For additional information about the different trust types and to verify the trust transitivity for difference Active Directory Functional Levels, see the following Microsoft TechNet articles:

Articles applicable to Windows Server 2003 Domain Functional Level:

• Trust Types - Active Directory
• Trust Transitivity - Active Directory

Articles applicable to Windows Server 2008 and later Domain Functional Level: