VMware ESXi and vSphere Cluster Management

Configure vCenter Server Authentication with Microsoft Active Directory

Learn how to connect vCenter SSO to Microsoft Active Directory, configure LDAP or LDAPS, and grant AD groups appropriate vCenter permissions.

Integrating Microsoft Active Directory with vCenter Server lets administrators use existing domain users and groups to sign in to the vSphere Client. The integration centralizes identity management, but it does not automatically give every domain user access to vCenter. Authentication and authorization remain separate configuration steps.

Authentication and authorization are different

Authentication verifies who a user is. Authorization determines what that authenticated user may do. vCenter Single Sign-On (SSO) performs or coordinates authentication through configured identity sources, while vCenter permissions and roles enforce authorization.

Adding an Active Directory identity source makes its users and groups available to SSO. It does not grant all domain users access. A user generally needs membership in an appropriate vCenter SSO group or an explicit inventory permission before a successful login provides useful access.

Architecture and identity-source choices

The main components are the vCenter Server Appliance (VCSA), vCenter SSO, the vSphere Client, DNS, and one or more Active Directory domain controllers. The vSphere Client sends a login request to vCenter. SSO validates the identity through the configured identity source, and vCenter then evaluates roles and permissions.

Domain controllers provide directory lookups and, depending on the integration method, authentication services. DNS is essential because vCenter and the domain controllers must locate one another by fully qualified domain name (FQDN). LDAP provides directory queries. LDAPS is LDAP protected with TLS and is preferred for production because it encrypts directory traffic and bind credentials.

• Integrated Windows authentication: Available only in versions and deployment models that support it. It can use the appliance's domain relationship and Windows authentication mechanisms with less manual LDAP path configuration.
• Active Directory over LDAP or LDAPS: A manually defined identity source. This normally requires domain information, user and group search bases, server URLs, and, when required, a bind account.
• Other identity sources: Some vCenter releases support additional directory or federation models. Their administration pages and fields differ from manual LDAP configuration.

Prerequisites and planning

1. Confirm that the VCSA and each selected domain controller resolve each other's FQDNs. Check forward DNS and, where used by the environment, reverse DNS.
2. Confirm network reachability for DNS, LDAP or LDAPS, Kerberos where relevant, and other time or domain services required by the selected integration. Typical references include DNS on TCP/UDP 53, LDAP on TCP/UDP 389 as applicable, LDAPS on TCP 636, and Kerberos on TCP/UDP 88.
3. Synchronize time between vCenter, domain controllers, and supporting infrastructure. Kerberos is sensitive to time differences, and certificate validation also depends on a correct system clock.
4. Identify a primary domain controller and, preferably, a secondary controller in the same or an appropriate resilient directory service.
5. Choose LDAP or LDAPS. Use LDAPS in production and plan how the VCSA will trust the complete certificate chain issued to the domain controllers.
6. Prepare a dedicated least-privilege bind account if the selected identity-source method requires one. It should be able to perform the necessary directory searches, not administer the domain.
7. Identify the containers or organizational units (OUs) holding the users and groups that vCenter must search.
8. Create an AD security group for vCenter administrators. Group-based delegation is easier to audit and change than assigning administrative access directly to individuals.
9. Keep a local SSO or appliance administrative account available as a recovery path. Test and protect this break-glass account.

Before changing authentication, record the intended domain, search bases, endpoints, certificate authority details, bind-account owner, and recovery accounts. This documentation is especially important when service-account passwords or domain-controller certificates are rotated.

Join or enable directory integration on the appliance

Some vCenter workflows first join the VCSA to the Active Directory domain and then separately register Active Directory as an SSO identity source. This historical workflow should not be assumed to be required in every current release; newer versions may expose a different supported identity-provider model.

1. Sign in to the VCSA management interface with an authorized appliance administrator account.
2. Open the directory-service or domain-membership administration page provided by the vCenter release.
3. Supply the AD domain FQDN and credentials authorized to join the appliance to that domain. Use an appropriately delegated account rather than broad Domain Admin membership when organizational policy supports delegated joining.
4. Apply the change. Older deployment workflows may require a service restart or appliance reboot.
5. After the operation, verify domain-membership status, DNS resolution, time synchronization, and connectivity to the domain controllers.

Add Active Directory as an SSO identity source

In the vSphere Client, open the vCenter administration area and locate the SSO identity-source configuration page. When performing manual integration, select the Active Directory LDAP option supported by the release. Enter the values carefully, test the connection, and save only after the test succeeds.

1. Enter the identity-source name, domain name, and domain alias if those fields are provided.
2. Enter separate user and group base DNs. They may be identical when both object types are in the same container.
3. Enter the primary server URL and an optional secondary URL. Use FQDNs rather than IP addresses, particularly for LDAPS certificate validation.
4. Enter the bind account and password if required by the selected method. Protect the credentials and follow the organization's rotation policy.
5. Use the connection-test function. Resolve failures before saving.
6. Save the identity source and confirm that it appears in the configured source list.
7. Review the default domain or default identity-source setting if the vCenter version provides one. Otherwise, select the source explicitly during user or group lookup and login.

LDAP distinguished names and search bases

A distinguished name (DN) is an LDAP path that identifies an object or search location. Active Directory DNS labels become domain components prefixed with DC=. Containers use CN=, and organizational units use OU=. Components are separated by commas.

A base DN limits where searches begin. If users are in OU=Virtualization Users,DC=example,DC=local and groups are in OU=Virtualization Groups,DC=example,DC=local, configure those separate paths rather than using the default Users container.

Domain:              example.local
Users base DN:      OU=Virtualization Users,DC=example,DC=local
Groups base DN:     OU=Virtualization Groups,DC=example,DC=local
Primary endpoint:   ldaps://dc01.example.local:636
Secondary endpoint: ldaps://dc02.example.local:636
Bind user:          svc_vcenter_ldap@example.local

An LDAP server URI identifies the protocol, host, and usually the port. Common forms are ldap://dc01.example.local:389 and ldaps://dc01.example.local:636. The hostname must resolve from vCenter and should match the name on the domain controller certificate when using LDAPS.

A secondary server improves resilience when the primary controller is unavailable, but it is not a complete high-availability solution. DNS, network paths, certificates, directory replication, account status, and time synchronization must also remain healthy.

Grant AD users and groups access to vCenter

After the identity source is configured, verify that vCenter can search for representative users and groups. In the vCenter administration interface, locate the SSO users and groups or permissions area and select the configured AD source.

1. Create an AD security group such as GG-vCenter-Administrators.
2. Add designated administrators to that group in Active Directory.
3. For full administrative access, add the AD group to the applicable vCenter SSO administrative group when supported, or assign the built-in Administrator role at the required vCenter scope.
4. For ordinary operations, assign a narrower vCenter role to an AD group at a specific inventory scope.
5. Enable permission inheritance only when child objects should receive the permission. Review inheritance and conflicting permissions before testing.

Prefer groups over individual accounts. Useful role-based groups might include GG-vCenter-Administrators, GG-vCenter-VM-Operators, GG-vCenter-ReadOnly-Auditors, and GG-vCenter-Backup-Operators.

• Administrators: Reserved for trusted personnel who require broad vCenter control.
• VM operators: Assigned approved virtual-machine tasks at a VM folder or resource-pool scope.
• Read-only auditors: Granted inventory visibility and inspection without change privileges.
• Backup operators: Granted only the privileges required by the backup workflow.

For example, assign a VM operations group a constrained role on a VM folder instead of granting global administration. Test that members can perform approved VM tasks but cannot change hosts, SSO settings, or global permissions.

Validate the configuration

1. Run the identity-source connection test.
2. Search for a known AD user and a known AD group. Confirm that both resolve from the intended identity source.
3. Sign in to the vSphere Client with a non-personal test account that has the intended group membership.
4. Verify the account receives only the expected role and inventory visibility.
5. Attempt an operation that should be allowed and one that should be denied.
6. If a secondary directory server is configured, test behavior with the primary endpoint unavailable during an approved maintenance window.
7. Record search bases, endpoints, bind-account ownership, certificate details, recovery accounts, and the date of the test.

Keep the recovery account independent of the AD dependency. This account is essential if directory connectivity, domain membership, certificates, or bind credentials fail.

Security and lifecycle practices

• Prefer LDAPS and validate the domain-controller certificate name, validity period, issuing CA, and complete intermediate chain.
• Do not use Domain Admin membership as the normal way to grant vCenter access.
• Use dedicated AD groups and least-privilege vCenter roles.
• Protect bind credentials, restrict their directory rights, and rotate them according to policy. Update the identity source immediately after a password change.
• Monitor certificate expiration, bind-account status, domain-controller availability, DNS records, and time synchronization.
• Maintain local break-glass administrative access and document emergency procedures.
• Review permissions when AD users or groups are disabled, deleted, renamed, or moved. A moved object may no longer fall within the configured search base, while a deleted or disabled identity may leave permissions that need cleanup.

Troubleshooting

Common bind-account failure

If previously working lookups stop after a service-account password change, the identity source may still contain the old password. Update the stored bind credential, confirm that the account is not locked, disabled, or expired, and run the connection test again. Document ownership and rotation procedures so this dependency is not missed.

Common DN failure

Incorrect OU names, missing commas, incorrect capitalization in environments that validate names strictly, or an unsuitable search level can prevent discovery. Compare the configured DN with the actual distinguished name of a known user and group, then test each base separately.

Exam-relevant notes

• Authentication answers “who are you?”; authorization answers “what may you do?”
• Adding an AD identity source does not automatically grant vCenter access.
• Users and groups can have different base DNs.
• LDAPS requires both a reachable endpoint and a trusted, correctly named certificate.
• Group-based permissions support least privilege, auditing, and lifecycle management.
• Permission scope and inheritance determine which inventory objects a role affects.
• A local recovery account should remain available even when AD is unavailable.

Configuration workflow summary

1. Confirm DNS, time, reachability, certificates, directory paths, and recovery access.
2. Join or enable appliance directory integration only when required by the vCenter release and chosen method.
3. Configure Active Directory as an SSO identity source.
4. Test and save the connection.
5. Add an AD security group to the appropriate SSO group or assign it a scoped vCenter role.
6. Test sign-in, allowed actions, denied actions, inventory scope, and secondary-server behavior.
7. Document the configuration and monitor its certificates, accounts, controllers, DNS, and time.

For related administration guidance, see vCenter Server and Active Directory.