Microsoft Active Directory Trusts supported with VMware vCenter Single Sign-On

Products

• VMware vCenter Server

Issue/Introduction

This article provides information on the Microsoft Active Directory trusts that are supported and can be used with vCenter Single Sign-On (SSO) when using an Active Directory (Integrated Windows Authentication) identity source. It also provides information on the limitations of certain trusts.

 

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:

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

 

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.

Resolution

This article provides diagrammatic representations and detailed information on:

• Domain configurations existing within a Forest, which include:
  • Parent-Child Trust
  • Shortcut Trust
  • Tree-Root Trust
• Domain configurations existing across a Forest, which include:
  • Forest Trusts
  • External Trusts
  • Realm Trusts

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 https://docs.vmware.com/en/VMware-vSphere/7.0/com.vmware.vsphere.authentication.doc/GUID-B23B1360-8838-4FF2-B074-71643C4CB040.html
	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.

 

Domain Configurations existing within a Forest

Parent-Child Trust

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.

 

Example

 

 

 

Shortcut Trust

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.

 

Example

 

 

Tree-Root Trust

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.

 

Example

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

You may experience certain limitations with vCenter Single Sign-On when accessing resources via an External domain or Forest trust because these trusts, by default, are one-way configurations. The following section explains the technical limitations that are observed with each trust type. When applicable, VMware always recommends two-way trusts when using External or Forest trusts.

Forest Trusts

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.

 

One-Way Forest Trust from vCenter Server's Forest

 

Examples

 

The use of a one-way Forest trust from the Forest where vCenter Server exists to a separate Forest includes these limitations:

• 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.

Using a one-way Forest trust, however, still allows users to perform a single search and add individual users by entering their full account name. Also, users can log in from Forest B's root domain due to the use of the RPC API, which does not require a two-way trust. In this example, vCenter Server can perform a full query, add and authenticate all users from Forest A, but can perform only individual user queries and add/authenticate users from Forest B.

 

 

Note: VMware is aware of these limitations with vSphere 5.5 and is working towards resolving them.

 

One-Way Forest Trust to vCenter Server's Forest

 

Example

 

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.

 

 

Two-Way Forest Trust between vCenter Server's Forest

 

Examples

 

Due to the use of two-way trusts between both forests, there is no limitation when using a one-way trust*. All inter-forest trusts are still obeyed and vCenter Server can utilize the two-way trust from its forest to the other forest without any issues. Users can be queried/added and users can access vCenter Server from all Parent and Child domains from both forests.

 

*For the vCenter Server Appliance and vRA IA, the use of a two-way Forest trust from the Forest where vCenter Server exists to a separate Forest also includes these limitations:

• 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.

Note: VMware is aware of these limitations on the vCenter Server Appliance with vSphere 5.5 and is working towards resolving them.

VMware recommends using a two-way Forest trust where applicable.

External Trusts

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.

 

One-Way External Trust from vCenter Server's Forest

 

Example

The use of a one-way External trust from the Forest where the vCenter Server exists to a separate domain includes these limitations:

• 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.

Using a one-way External, however, still allows users to perform a single search and add individual users by entering their full account name and the users can log in from Stand-Alone Domain's root domain due to the use of the RPC API, which does not require a two-way trust. In this example, vCenter Server can perform a full query and add/authenticate all users from Forest A, but can only perform individual user queries and add/authenticate users from the Stand-Alone Domain.

 

Note: VMware is aware of these limitations with vSphere 5.5 and is working towards resolving them.

 

One-Way External Trust to vCenter Server's Forest

 

Example

 

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.

 

Two-Way External Trust between vCenter Server's Forest

 

Example

 

Due to the use of two-way trusts between both forest and the Stand-Alone Domain, there are no limitations when using a two-way trust*. All internal forest trusts are still obeyed and vCenter Server can utilize the two-way trust from its forest to the Stand-Alone Domain without any issues. Uses can be queried and added and users can access vCenter Server from all Parent and Child domains from its forests as well as from the Stand-Alone Domain.

 

*For the vCenter Server Appliance and vRA IA, the use of a two-way External trust from the Forest where vCenter Server exists to a separate domain also includes these limitations:

• 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.

Note: VMware is aware of these limitations on the vCenter Server Appliance with vSphere 5.5 and is working towards resolving them.

VMware recommends using a two-way External trust where applicable.

 

Realm Trusts

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

Additional Information

Required Ports for Active Directory Communication

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:

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