vCenter Server LDAPS identity source cannot find users or groups outside the configured Base DN

Products

VMware vCenter Server

Issue/Introduction

You configure an Active Directory over LDAPS identity source in vCenter Server (Administration > Single Sign-On > Configuration > Identity Sources), and depending on the Base distinguished name (Base DN) you enter, you hit one or more of the problems below.
The Add Identity Source wizard rejects the Base DN and does not let you save it. For example, an organizational unit path such as OU=ExampleAccounts,DC=example,DC=com is not accepted.
The wizard accepts the Base DN, but when you assign a Global Permission, a known group such as Domain Admins does not appear or cannot be selected. For example, the wizard accepts OU=ExampleGroups,OU=ExampleAccounts,DC=example,DC=com, but then Domain Admins cannot be found.
The wizard accepts the Base DN and the group appears, but a specific user account cannot be found or cannot log in, because that account is stored in a different branch of the directory. For example, CN=Users,DC=example,DC=com exposes Domain Admins but not a user account that lives in a separate organizational unit.
Narrowing the Base DN to one organizational unit makes some objects visible and others disappear, and no single organizational unit exposes both the groups and the users you need.

Environment

VMware vCenter Server 7.0
VMware vCenter Server 8.0
Active Directory environment

Cause

When you add an Active Directory over LDAPS identity source, vCenter Server searches for users and groups only within the subtree defined by the Base DN you provide. vCenter uses a Base DN for users and a Base DN for groups, and it can only see objects that live at or below those distinguished name (DN) paths. Any account or group stored in a different branch of the directory is invisible to vCenter, both for login and for permission assignment.

Two directory details commonly produce the symptoms above:

Default Active Directory containers such as Users, Computers, and Builtin use the CN= prefix, while administrator-created organizational units use the OU= prefix. A Base DN that uses the wrong prefix, or that points to a path which does not exist as written, fails the wizard's validation search and is rejected.
Built-in groups and accounts, for example Domain Admins, live under CN=Users,DC=..., while custom user accounts are often placed in separate organizational units. When no single container holds both the groups and the users you need, a narrowly scoped Base DN always excludes one or the other.

The only DN guaranteed to contain every user and group in the domain is the domain root, DC=<domain>,DC=com. The domain root is the common ancestor of all containers and organizational units, so scoping the Base DN there exposes both the built-in groups and the custom user accounts at the same time.

Resolution

Complete the base Active Directory over LDAPS identity source setup first (LDAPS certificate, bind account, and server URLs), as described in KB 316596 linked under Additional Information. The steps below address Base DN scope problems encountered during that setup.
List every object vCenter must see: the bind/service account, the Active Directory groups you will grant vCenter permissions to (for example, Domain Admins), and the user accounts that will log in.
In Active Directory, read the exact distinguished name of each object from step 2, including whether each container is CN= or OU=. Use ADSI Edit, or run from a domain-joined Windows host:
```
dsquery user -name "<user-account>"
dsquery group -name "Domain Admins"
```
Choose a Base DN that is a common ancestor of all the objects from step 2:
- If every required user and group lives under one organizational unit, set the Base DN to that organizational unit.
- If the users and groups live in separate branches with no shared container, set the Base DN to the domain root, DC=<domain>,DC=com.
If the wizard offers a separate Base DN for users and Base DN for groups, scope each to the narrowest container that still holds all required objects of that type. For example, set the groups Base DN to CN=Users,DC=<domain>,DC=com and the users Base DN to the organizational unit that holds your accounts.
Match the container prefix to the object's actual type in Active Directory: use CN= for the default containers (Users, Computers, Builtin) and OU= for organizational units. A mismatched prefix is rejected or returns no results.
Save the identity source, then validate the scope: assign a Global Permission to a known group, and confirm that a known user in that group can log in to the vSphere Client.

Note: Setting the Base DN to the domain root is the most reliable choice when the required objects are spread across the directory. It searches the entire domain, which is acceptable in most environments. In very large directories, prefer correctly scoped user and group Base DNs for faster lookups.

Additional Information

For further information for dealing with scope issues when setting up AD over LDAP see Considerations when migrating a vCenter Identity Source from Integrated Windows Authentication to AD over LDAP / OpenLDAP
For the full identity source setup procedure, see Configuring a vCenter Single Sign-On Identity Source using LDAP with SSL (LDAPS). Use that article as the primary how-to; this article covers the Base DN scope problems that can come up while following it.
Choose a Base DN that contains all intended users and groups. When the objects are spread across multiple organizational units, use the domain root DC=<domain>,DC=com.
Active Directory over LDAPS is the recommended identity source in place of Integrated Windows Authentication (IWA), which is removed as of vSphere 9.0.