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

This article provides diagrammatic representations and detailed information on:

  • Domain configurations existing within a Forest, which include:
  • 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:

IconDefinition
Microsoft Active Directory Trusts supported with VMware vCenter Single Sign-On (1)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.
Microsoft Active Directory Trusts supported with VMware vCenter Single Sign-On (2)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.
Microsoft Active Directory Trusts supported with VMware vCenter Single Sign-On (3)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.

Microsoft Active Directory Trusts supported with VMware vCenter Single Sign-On (4)This object represents a two-way transitive or nontransitive trust between two objects within an Active Directory infrastructure
Microsoft Active Directory Trusts supported with VMware vCenter Single Sign-On (5)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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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.

Microsoft Active Directory Trusts supported with VMware vCenter Single Sign-On (2024)
Top Articles
Latest Posts
Article information

Author: Chrissy Homenick

Last Updated:

Views: 5890

Rating: 4.3 / 5 (54 voted)

Reviews: 85% of readers found this page helpful

Author information

Name: Chrissy Homenick

Birthday: 2001-10-22

Address: 611 Kuhn Oval, Feltonbury, NY 02783-3818

Phone: +96619177651654

Job: Mining Representative

Hobby: amateur radio, Sculling, Knife making, Gardening, Watching movies, Gunsmithing, Video gaming

Introduction: My name is Chrissy Homenick, I am a tender, funny, determined, tender, glorious, fancy, enthusiastic person who loves writing and wants to share my knowledge and understanding with you.