VMware ESXi and vSphere Cluster Management

Configure vCenter Server Authentication with Microsoft Active Directory

Learn how to connect vCenter Server SSO to Active Directory, configure LDAP or LDAPS, assign AD groups permissions, and test domain sign-in.

What Active Directory integration does

vCenter Server can authenticate users through Microsoft Active Directory (AD), a Windows directory service that stores users, groups, computers, and authentication information. This lets administrators use existing domain identities instead of creating a separate account for every vSphere user.

The vCenter Server Appliance (VCSA) is the appliance-based deployment of vCenter Server. Its services include vCenter Single Sign-On (SSO), the authentication component that validates identities from configured identity sources. An identity source is a directory from which SSO can retrieve and authenticate users and groups.

Authentication and authorization are separate:

• Authentication verifies that a username and password belong to a valid identity.
• Authorization determines what that identity may do in vCenter Server.

Adding AD does not automatically grant vCenter privileges. After authentication is configured, assign an AD user or, preferably, an AD group to an SSO administrative group or to a vSphere role at the required inventory scope.

Components and responsibilities

Joining the appliance versus adding an identity source

These are related but different operations. Joining the VCSA to an AD domain makes the appliance a domain member and can support directory-related appliance functions. Registering Active Directory over LDAP as an SSO identity source tells vCenter how to query and authenticate AD users and groups through LDAP or LDAPS.

Depending on the vSphere release and authentication design, you may use one or both workflows. Neither operation by itself grants inventory access. Permissions or SSO group membership must still be configured.

Plan prerequisites before configuration

1. Use consistent FQDNs. An FQDN, or fully qualified domain name, identifies a host in the complete DNS namespace, such as vcsa.example.com or dc01.example.com. Use FQDNs consistently for vCenter and domain controllers, especially with LDAPS.
2. Verify DNS. Confirm forward and reverse resolution between the VCSA and domain controllers. AD-integrated DNS is normally preferable to public or unrelated DNS servers.
3. Check network access. Confirm that vCenter can reach the selected domain controllers and directory service ports. Typical LDAP uses TCP 389, while LDAPS commonly uses TCP 636. Other AD functions may require additional ports.
4. Synchronize time. Keep vCenter, domain controllers, and client systems synchronized with reliable NTP sources. Excessive clock skew can break Kerberos authentication and contribute to certificate validation failures.
5. Prepare directory credentials. If the selected identity-source method requires a bind account, use a least-privilege account intended for directory lookup. Protect its password and rotate it according to organizational policy.
6. Identify search locations. Determine the organizational units (OUs) or containers holding the users and groups that vCenter must find.
7. Choose LDAP or LDAPS. Use LDAPS when organizational requirements call for encrypted directory traffic. Plan certificate trust, certificate name matching, renewal, and CA management before enabling it.
8. Choose a secondary controller. Where supported, configure a second domain controller so the identity source has an alternate directory endpoint.
9. Keep recovery access. Retain a tested local or SSO administrative account. It provides a recovery path if AD is unavailable or an identity-source change is incorrect.

Configure appliance-level Active Directory membership

When your design requires domain membership, open the VCSA management interface at:

https://<vcenter-appliance-fqdn>:5480

1. Sign in with an appliance administrator account.
2. Open the directory-services, authentication, or similarly named settings area. The exact location varies by vCenter release.
3. Enable or configure Active Directory membership.
4. Enter the AD DNS domain name, such as example.com, and provide the authorized account credentials requested by the interface.
5. Apply the change. Some releases require an appliance reboot or a restart of affected services.
6. After the restart, return to the management interface and verify that the appliance reports successful domain membership.

Add Active Directory as a vCenter SSO identity source

For current vSphere Client workflows, open:

https://<vcenter-fqdn>/ui

1. Open Administration.
2. Open the Single Sign-On administration area.
3. Select Configuration or the identity-source section, then choose Identity Sources.
4. Select Add.
5. Choose Active Directory over LDAP when entering explicit LDAP parameters.
6. Complete the fields, test the connection, and save the source.

Older environments may expose a different workflow in the legacy Web Client, for example:

https://<web-client-fqdn>:9443/vsphere-client

Identity-source types and screens vary considerably between legacy and current clients. Use the equivalent SSO identity-source configuration in the installed release.

Identity-source fields

Build correct distinguished names

A Distinguished Name (DN) is the LDAP-formatted path to an object or container. A Base DN is the search root below which vCenter looks for users or groups. In a DN, DC components represent domain labels, OU represents an organizational unit, and CN commonly represents a container or named object.

For example, if both accounts and groups are in the default container, the base can be CN=Users,DC=mydomain,DC=local. If the objects are in custom OUs, using CN=Users is incorrect and the objects may not be found.

Choose LDAP URLs

• ldap://dc01.mydomain.local:389 uses ordinary LDAP on TCP 389.
• ldap://dc02.mydomain.local:389 provides a secondary non-TLS endpoint.
• ldaps://dc01.mydomain.local:636 uses LDAP protected by TLS.

With LDAPS, vCenter must trust the certificate chain issued to the domain controller. The hostname in the URL should match a valid name in the certificate, and TCP 636 must be reachable.

Use the built-in Test Connection control before saving. After the source is added, search for a known user and group to confirm that the configured bases and domain settings work.

Authorize AD users and groups

Directory authentication only proves identity. Authorization requires a separate assignment. The safer operating pattern is to manage access through AD security groups rather than individual users.

SSO-level administration

Open the SSO users-and-groups area when a directory group must administer SSO-related functions. Select the AD identity source, search for a group such as VCenter-Admins, and add it to the appropriate SSO administrative group. Adding an individual user can work, but group membership is easier to review, change, and audit.

Membership in the SSO Administrators group is powerful and is separate from an ordinary inventory role. Grant it only to a tightly controlled administrative group.

Inventory-level permissions

A vCenter permission combines an AD principal, a vCenter role, and an inventory scope. Roles contain privileges such as viewing objects, powering on virtual machines, or changing configuration. Common examples include administrator, read-only, and custom roles.

1. Use an AD group such as VCenter-Admins for administrators who need broad access.
2. Use a separate group such as VCenter-ReadOnly for auditors.
3. Select the correct inventory object, such as the vCenter root, a datacenter, cluster, folder, or virtual machine.
4. Assign the required role to the group.
5. Enable propagation or inheritance when child objects should receive the permission.

Permission inheritance is the propagation of a permission from a parent inventory object to its children. Assigning a read-only role at a datacenter is different from assigning it to one VM. Always verify the selected scope and whether propagation is enabled.

Validate domain-account sign-in

1. Sign out of the vSphere Client.
2. Sign in with a test domain account using an accepted qualified format, such as MYDOMAIN\jdoe. Some releases or configurations also accept a user principal name such as jdoe@example.com.
3. Confirm that authentication succeeds.
4. Check the inventory objects visible to the user.
5. Test an administrative account separately from a restricted account.
6. Use a non-administrative account, such as a member of VCenter-ReadOnly, and verify that it cannot perform prohibited actions.

A successful login does not prove that authorization is correct. Confirm both the allowed actions and the actions that should be denied.

Verification commands

Run these examples from a suitable Windows administrative system. They test basic DNS and network reachability; they do not replace the vCenter identity-source test.

Resolve-DnsName dc01.example.com
Test-NetConnection dc01.example.com -Port 389
Test-NetConnection dc01.example.com -Port 636

Common troubleshooting checks

Join or domain lookup failure

• Confirm that vCenter uses AD-integrated DNS.
• Check forward and reverse resolution for vCenter and every domain controller.
• Verify the domain name, account credentials, and network route.
• Check time synchronization and clock skew.

Identity-source test failure

• Validate the LDAP or LDAPS scheme, FQDN, and port.
• Verify the bind username and password.
• Check every CN, OU, and DC component in the base DNs.
• For LDAPS, confirm that vCenter trusts the issuing CA and that the certificate name matches the server name in the URL.

Users or groups cannot be found

• Point the search base at the actual container or OU.
• Confirm that the object is a user or security group within the configured scope.
• Check the domain alias and selected identity source.
• Confirm that the source was saved and remains enabled.

Authentication succeeds but access is wrong

• Confirm AD group membership and allow time for directory membership changes to take effect.
• Verify SSO administrative membership or the inventory permission assigned to the group.
• Check the object where the role was assigned and whether propagation is enabled.
• Review the role for missing or excessive privileges.

Sign-in or LDAPS failure

• Try the username format expected by the installed vCenter release.
• Confirm the account is enabled, unlocked, and permitted by directory policy.
• Verify that the user is below the configured user base DN.
• After a certificate change, check the CA chain, certificate expiry, server name, and TCP 636 reachability.
• Review SSO and vCenter service logs for directory or certificate errors.

Recovery after administrative lockout

Use the retained local or SSO recovery administrator account. Verify that at least one known-good administrative principal remains configured. Restore group membership or permissions only after confirming directory connectivity and the identity-source settings.

Security and operations checklist

• Prefer AD groups over direct permissions on individual users.
• Use LDAPS when encrypted directory traffic is required.
• Protect bind-account credentials and rotate them under the organization’s credential-management policy.
• Limit user and group search bases to required directory locations where practical.
• Document the identity source, domain controllers, aliases, group mappings, and recovery method.
• Keep a tested local or SSO administrative recovery account outside the normal AD dependency.
• Review and audit SSO administrative membership and vCenter permissions regularly.
• Test both an administrator group and a least-privilege group after changes.

Exam-relevant distinctions

• Joining the VCSA to an AD domain is not the same as registering AD as an SSO identity source.
• Authentication does not grant authorization.
• LDAP uses directory queries; LDAPS adds TLS and certificate-trust requirements.
• A DN identifies a directory path, while a base DN defines the search root.
• SSO Administrators membership is distinct from a vCenter inventory role.
• Permission scope and inheritance determine which inventory objects a principal can access.
• A secondary domain controller improves endpoint resilience but does not correct DNS, AD, routing, or certificate problems.