Unit

Integrating VMware vCenter Server with Active Directory

Learn how vCenter SSO, Active Directory identity sources, roles, permissions, groups, testing, and troubleshooting work together.

Integrating VMware vCenter Server with Microsoft Active Directory lets administrators use centrally managed domain identities while controlling access through vCenter roles and permissions. This lesson explains the authentication architecture, prerequisites, identity-source configuration, permission design, testing, and common failures.

Why Connect vCenter Server to Active Directory?

vCenter Server is the VMware management platform used to administer ESXi hosts, clusters, inventory objects, and virtual machines. Without directory integration, administrators may need separate local accounts and manually maintained access lists.

Active Directory (AD) is Microsoft's directory service for managing domain identities, groups, authentication, and policy. Connecting vCenter to AD makes directory users and groups available for authentication and authorization decisions.

  • Centralized identity management: user accounts, group membership, disabling, and password policies remain managed in AD.
  • Single sign-on experience: administrators can use their organizational identity instead of maintaining a separate vCenter account.
  • Group-based access: access can be assigned to security groups rather than individual accounts.
  • Easier onboarding and offboarding: adding or removing a user from an AD group changes access without repeatedly editing vCenter permissions.
  • Auditability: named domain accounts and documented groups make administrative activity easier to attribute and review.

Authentication and authorization are different. Authentication answers, “Who are you?” Authorization answers, “What may you do?” Adding AD as an identity source supports authentication and directory lookup, but it does not automatically grant the user access to vCenter inventory.

vCenter Server Authentication Architecture

vCenter Single Sign-On (SSO) is the vCenter authentication service. It validates an identity and issues the authentication information used by vCenter services. SSO can use its internal identity domain and configured external identity sources.

The SSO domain is an internal vCenter identity domain, commonly named something such as vsphere.local. It is separate from the organization's Microsoft AD domain, such as example.com. These names do not need to match, and changing an AD password does not change the SSO-domain administrator account.

An identity source is an identity repository that vCenter SSO can query for users and groups. An AD identity source allows vCenter to search the directory and validate AD identities through the selected directory integration method.

The normal access sequence is:

  1. A user signs in to the vSphere Client.
  2. vCenter SSO determines which identity source contains the identity.
  3. AD or another configured source validates the identity.
  4. vCenter evaluates permissions assigned to the user and the user's groups.
  5. vCenter permits or denies actions on inventory objects according to the effective privileges.

Concept | Primary purpose | Typical technology | What it controls | Common misunderstanding

Authentication | Verify identity | SSO, AD, Kerberos, LDAP, or another provider | Whether a sign-in identity is valid | Successful authentication does not grant inventory access

Identity source | Make users and groups discoverable | AD over LDAP or LDAPS | Where vCenter searches for identities | Adding a source automatically grants no role

Authorization | Decide permitted actions | vCenter roles and permissions | Which operations are allowed on which objects | A directory group alone is not a vCenter permission

SSO domain | Provide internal vCenter identities | vCenter SSO domain | Internal SSO accounts and services | It is the same thing as the AD domain

Prerequisites and Planning

Directory, DNS, and time checks

  • Confirm that the vCenter Server Appliance has a correct hostname and fully qualified domain name.
  • Verify forward DNS resolution from vCenter to the intended domain controllers or LDAP endpoints.
  • Verify reverse lookup where required by the deployment and directory design.
  • Confirm that domain controllers are reachable over the directory services required by the selected integration method.
  • Synchronize vCenter and domain-controller clocks with reliable NTP sources. Large time differences can break authentication and secure directory operations.
  • Check that firewall rules allow the required DNS, NTP, LDAP or LDAPS, authentication, and directory-service traffic for the deployed architecture.

Do not treat one fixed port list as universal. Required traffic varies with vCenter version, identity-source method, domain design, secure LDAP usage, and network architecture. Document the required flows with the current VMware and Microsoft documentation for the versions in use.

Credentials, certificates, and directory design

  • Prepare an account with the administrative rights required by the chosen configuration method.
  • If a bind or service account is used, grant only the directory-read access needed to locate and validate users and groups.
  • For LDAPS, which is LDAP protected with TLS encryption, confirm that vCenter trusts the issuing certificate chain and that certificates are valid for the selected endpoint names.
  • Identify the AD domain, domain controllers, organizational units, and security groups that will be used.
  • Determine a search location. A Base DN is the starting directory location for searches, for example DC=example,DC=com. A Distinguished Name (DN) is the complete LDAP path identifying an object or search location.
  • Decide whether the default domain should be enabled. It is convenient for users who sign in with a short name, while fully qualified names such as user@example.com make the selected identity source explicit.

Adding an Active Directory Identity Source

The exact labels vary by vSphere release, but the workflow is performed in the vSphere Client administration area under SSO or identity-source management.

  1. Sign in with an account authorized to manage vCenter authentication or identity sources.
  2. Open the administration area and locate the SSO identity-source configuration.
  3. Choose the applicable Active Directory integration type. Depending on the release and design, this may use AD over LDAP, secure LDAP, or a directory integration that uses domain membership.
  4. Enter the AD domain name and the LDAP search settings, including the Base DN.
  5. Specify approved domain controllers or LDAP endpoints. Use names that match the certificate identity when LDAPS is enabled.
  6. Provide a delegated bind or service-account credential when the selected method requires one. Protect this credential and document its owner and rotation process.
  7. Save the configuration and use the available validation or test function.
  8. Test discovery of both a known AD user and a known AD security group before assigning any vCenter role.
  9. Set the default domain only after confirming that short-name sign-in will not create ambiguity between identity sources.

A conceptual configuration might contain:

Identity source: Active Directory over LDAP or LDAPS
Domain: example.com
Base DN: DC=example,DC=com
Directory endpoint: dc01.example.com
Bind account: CN=vc-directory-reader,OU=Service Accounts,DC=example,DC=com
Default domain: optional; enable only after validation

Values above are placeholders. Use the names, search bases, endpoints, and account format supplied by the directory team. Validate lookup before granting access.

Identity Source Versus Appliance Domain Membership

Adding AD as an SSO identity source and joining the vCenter Server Appliance to an AD domain are related but different operations.

  • Adding an identity source: tells vCenter SSO where to find and validate users and groups. This can be sufficient when the goal is directory-backed vCenter sign-in and authorization.
  • Joining the appliance to an AD domain: makes the appliance a domain member and can affect machine identity, host naming, authentication mechanisms, and related service configuration.

An environment may use neither when only local SSO identities are appropriate, one of them when directory-backed sign-in is needed without appliance membership, or both when the deployment and authentication design require domain membership as well as an SSO identity source. Do not assume that joining the appliance automatically creates the required vCenter permissions, or that adding an identity source changes the appliance hostname.

Before changing domain membership, review dependencies involving DNS, certificates, service accounts, host naming, domain-controller availability, and recovery procedures. Test the change in a controlled environment or under approved change control.

vCenter Roles, Privileges, and Permissions

A privilege is permission to perform one specific vCenter action. A role is a named collection of privileges. A permission assigns a user or group a role on an inventory object.

For example, a permission can assign the AD group VG-VCENTER-ADMINS the Administrator role on the vCenter root object. The role supplies the actions, while the inventory object supplies the scope.

  • Built-in roles provide common privilege sets such as Administrator, Read-only, and other operational roles. Review their privileges and scope before assigning them.
  • Custom roles combine only the privileges required for a defined job function.
  • Administrator is powerful and should not be assigned broadly. A compromised account or group with this role can affect the entire managed environment.
  • Least privilege means granting only the access needed for assigned duties, at the smallest practical inventory scope.

Designing a custom role

  1. Describe the job responsibility in operational terms.
  2. List the actions required, such as powering on a VM, opening a console, viewing events, or editing a defined configuration.
  3. Start with no privileges and add only those required.
  4. Exclude host, datastore, network, cluster, and security-management privileges unless the job requires them.
  5. Test with a non-administrative account and a nonproduction object.
  6. Document the role owner, review date, and intended assignment scope.

Assigning AD Users and Groups Permissions

To assign access, navigate to the intended inventory object, open its permissions management, add a user or group from the configured identity source, select a built-in or custom role, and choose propagation deliberately.

Prefer AD security groups over individual accounts. Group-based assignments provide consistent onboarding, offboarding, separation of duties, and access review. Individual assignments should be exceptions with documented justification.

Inventory object | Typical use case | Effect of propagation | Example AD group | Recommended role type

vCenter root | Environment-wide administration or auditing | Can reach child datacenters and inventory | VG-VCENTER-ADMINS or VG-VCENTER-AUDIT | Carefully reviewed Administrator or Read-only

Datacenter | Manage or inspect one datacenter | Reaches folders, clusters, hosts, and VMs below it when enabled | VG-DC1-OPS | Custom operations or Read-only

Folder | Control a VM or workload boundary | Reaches contained VMs and folders | VG-APP-PAYMENTS-OPERATORS | Custom workload role

Cluster or host | Platform or compute operations | Reaches children according to the object hierarchy and propagation | VG-VCENTER-PLATFORM | Platform role

Virtual machine | Manage one VM or a small exception set | No broad folder access is created by a VM-level assignment | VG-APP-OWNER-VM1 | Limited VM operator role

Datastore | Storage inspection or management | Applies to objects below the datastore where relevant | VG-STORAGE-OPS | Storage-specific role

Network | Network inspection or assignment | Applies within the selected network object scope | VG-NETWORK-OPS | Network-specific role

Propagation is inheritance from a parent inventory object to child objects. Enabling it at the vCenter root can expose the role to a very large scope. Disabling it may be appropriate for an object-specific permission.

When permissions overlap, vCenter evaluates permissions from the user and the user's groups, along with inheritance and explicit assignments. The resulting effective access can be difficult to predict when broad roles and exceptions overlap. Review all relevant assignments rather than assuming that the most recent assignment wins. Use narrow scopes, consistent groups, and a test account to verify the result.

Administrative Access Design

A practical design separates platform administration from workload administration. One possible mapping is:

AD security group | vCenter role | Assignment scope | Allowed responsibilities | Restrictions

VG-VCENTER-ADMINS | Reviewed Administrator role | vCenter root, tightly controlled | Full platform administration, configuration, and access management | Membership limited, monitored, and reviewed

VG-VCENTER-PLATFORM | Custom infrastructure role | Clusters, hosts, datastores, and networks | Platform operations and host or storage tasks | No unnecessary identity-management privileges

VG-VM-OPERATORS | Custom VM operator role | Selected VM folders | Power operations, console access, guest-tools tasks, and approved VM actions | No host, cluster, or broad datastore administration

VG-VCENTER-AUDIT | Read-only or audit role | Datacenter or vCenter | View inventory, configuration, tasks, and events | No changes

VG-APP-OWNERS | Custom application-owner role | Dedicated application VM folders | Operate and inspect assigned workloads | No platform administration or unrelated workload access

VG-BACKUP-OPS | Vendor- and task-specific custom role | Required backup inventory scope | Perform approved backup-related operations | No general Administrator access

Keep a protected, documented local SSO administrator account as a break-glass recovery path when AD, DNS, or network services are unavailable. Store its credentials securely, restrict its use to emergencies, monitor use, and test the recovery procedure. Normal daily administration should use named AD accounts and controlled groups.

Perform periodic access reviews. Confirm group ownership, remove stale memberships, review nested groups, validate role assignments, and record exceptions. Separation of duties is especially important for identity management, platform administration, backup operations, and workload ownership.

Testing and Verification

  1. Use a non-administrative AD test account whose group memberships are documented.
  2. Sign in with the intended domain-qualified identity.
  3. Confirm that the expected inventory objects are visible.
  4. Attempt an allowed action and verify that it succeeds.
  5. Attempt a prohibited action and verify that it is denied.
  6. Check a child object to confirm whether propagation works as designed.
  7. Compare explicit and inherited permissions at the tested levels.
  8. Review vCenter events and tasks for authentication, authorization, and attempted-operation evidence.
  9. Record the test result, account, group membership, role, scope, and propagation setting.

Test both positive and negative cases. A successful login proves authentication only; it does not prove that the authorization model is correct.

Security and Operational Practices

  • Use secure LDAP where organizational requirements call for encrypted directory communication.
  • Protect bind-account credentials and use a dedicated service account with directory-read access only when required.
  • Maintain accurate DNS and NTP settings on vCenter and directory infrastructure.
  • Use AD security groups, least privilege, narrow scopes, separation of duties, and documented ownership.
  • Review certificates before enabling or changing LDAPS and plan for certificate renewal.
  • Monitor authentication and administrative events and retain logs according to organizational policy.
  • Maintain a tested recovery path for SSO, local emergency administration, DNS, directory outages, and certificate failures.
  • Make permission changes through approved change control, especially at the vCenter root.

Common Integration Failures

Symptom | Likely cause | Verification step | Corrective action

Identity source cannot be added or validated | Incorrect domain or Base DN; unreachable controller; bad bind credentials; DNS failure; untrusted LDAPS certificate | Resolve the endpoint, check network access, verify the DN and credentials, and inspect certificate trust | Correct directory settings, firewall access, credentials, DNS, or certificate chain

Users or groups do not appear in the permission search | Search base excludes the OU; query account lacks read access; wrong domain selected | Test lookup, inspect Base DN, verify read access, and search with the correct qualified name | Expand or correct the search base, fix read access, or select the correct identity source

User authenticates but has no inventory or insufficient privileges | No vCenter permission; wrong scope; propagation disabled; missing group membership; incomplete role | Review group membership, explicit and inherited permissions, role privileges, scope, and propagation | Assign the correct group and role at the narrowest correct object, then retest

Authentication fails after an infrastructure change | Time drift, changed DNS, controller outage, expired certificate, or changed service-account password | Check NTP, DNS, endpoint availability, certificate validity, and stored credentials | Restore time and name resolution, renew or trust certificates, or update credentials under change control

Safe troubleshooting sequence

  1. Start with read-only checks and record the current configuration.
  2. Verify hostname resolution, reverse lookup where applicable, time, and endpoint reachability.
  3. Confirm the domain, Base DN, distinguished names, and account format with the directory team.
  4. Test directory user and group discovery before changing vCenter permissions.
  5. Check certificate validity and trust when LDAPS is involved.
  6. Verify the user's group membership and nested-group behavior.
  7. Review the vCenter permission, role, object scope, inheritance, and propagation.
  8. Use a controlled nonproduction object for effective-access testing where possible.
  9. Change one variable at a time and use approved change control for production.

Exam-Relevant Notes

  • AD integration provides identity lookup and authentication; it does not automatically authorize a user in vCenter.
  • The vCenter SSO domain is distinct from the Microsoft AD domain.
  • A role is a collection of privileges, while a permission assigns a role to a user or group on an inventory object.
  • Propagation controls whether a parent permission is inherited by child objects.
  • Group-based, least-privilege assignments are safer and easier to audit than broad individual assignments.
  • DNS and time synchronization are foundational dependencies for directory authentication.
  • Authentication success combined with missing inventory access usually indicates an authorization or scope problem.
  • Failure to find a user or group usually indicates an identity-source, Base DN, directory-query, or search-domain problem.

Summary

Active Directory integration centralizes identity management, while vCenter SSO and the vCenter permission model determine how those identities are used. Configure and validate the identity source, distinguish it from appliance domain membership, assign roles through tightly controlled AD groups, choose inventory scope and propagation deliberately, retain break-glass access, and verify both allowed and denied actions with a non-administrative test account.