VMware ESXi and vSphere Cluster Management

Integrate an ESXi Host with Active Directory

Learn how to prepare, join, verify, and secure an ESXi host with Active Directory using the vSphere Client, including DNS, NTP, permissions, proxy joining, and troubleshooting.

Integrating an ESXi host with Active Directory lets the host use centralized domain identities for authentication. Instead of creating and maintaining separate local accounts for every administrator, you can assign vSphere roles to Active Directory users or groups.

This guide covers the prerequisites, preparation, vSphere Client workflow, two domain-join methods, permission assignment, verification, security considerations, and common failures.

What Active Directory integration provides

ESXi is VMware's bare-metal hypervisor. It can use a directory service, such as Microsoft Active Directory, as an identity source for domain-based authentication.

Active Directory is Microsoft's directory service for managing users, groups, computer accounts, authentication, and organizational policies. A domain controller is a Windows server that provides Active Directory and authentication services.

  • Administrators can authenticate with their existing domain accounts.
  • Domain groups can receive shared access without assigning permissions to users individually.
  • Access can be managed centrally when staff join, leave, or change teams.
  • Local ESXi accounts can be reserved for emergency or break-glass access.

A domain join registers the ESXi host with an Active Directory domain and establishes the relationship needed for directory authentication. Authorization is a separate step. After the join, you still need to add an AD user or group to the appropriate vSphere inventory object and assign a vSphere role.

Prerequisites before joining the domain

Prepare the management network and identity services before opening the Join Domain dialog. Most failed joins are caused by DNS, routing, time, or permissions rather than by the dialog itself.

Active Directory integration prerequisites

  • DNS resolution: ESXi must use DNS servers that can resolve the Active Directory domain, domain controllers, and relevant service records.
  • ESXi FQDN: The host name must be a valid fully qualified domain name (FQDN), such as esxi1.corp.example. An FQDN is the complete DNS name of a host.
  • Domain-controller reachability: The ESXi management interface needs a working route to domain controllers and other required services.
  • Accurate time: Kerberos, the primary Active Directory authentication protocol, is sensitive to clock differences. ESXi and the domain controllers must use closely synchronized time.
  • Join permissions: The account used for a credential-based join must be allowed to create or join computer accounts in the target domain or organizational unit.
  • Firewall access: Network security controls must permit the required DNS, Kerberos, LDAP, SMB/RPC, and NTP traffic for the environment.
  • Local recovery access: Keep a tested local ESXi administrator account available before changing domain membership or access controls.

Services and network paths

The exact requirements depend on the ESXi version, Active Directory design, firewall policy, and whether an authentication proxy is used. Common services include the following:

  • DNS, commonly UDP or TCP 53.
  • NTP, commonly UDP 123.
  • Kerberos, commonly TCP or UDP 88.
  • LDAP, commonly TCP 389, or secure LDAP where configured.
  • SMB, commonly TCP 445.
  • RPC endpoint mapping, commonly TCP 135, plus any dynamic RPC ports required by the environment.

Do not open these services broadly by default. Restrict traffic to the ESXi management network, domain controllers, DNS servers, NTP sources, and authentication proxy as appropriate.

Review the ESXi network identity

Before joining, verify the host's management-network configuration in the vSphere Client or through your approved ESXi administration method.

  • Confirm that the management interface has the expected IP address and VLAN connectivity.
  • Confirm the default gateway and routing to DNS servers and domain controllers.
  • Confirm the configured DNS server addresses are internal DNS servers that know the AD namespace.
  • Confirm the host name and DNS suffix produce the intended FQDN.
  • Confirm that the FQDN is unique and is registered in the correct DNS namespace.
  • Check forward DNS resolution from the ESXi management environment.
  • Check reverse DNS where your organization or authentication design requires it.

For example, a host configured with the host name esxi1 and the suffix corp.example should identify as esxi1.corp.example. The Active Directory domain in this example is corp.example.

Test resolution and reachability

Use the tools approved for your ESXi version and operational procedures. From an ESXi shell, where shell access is permitted, basic checks can include:

nslookup corp.example
nslookup dc01.corp.example
nslookup esxi1.corp.example
nslookup 192.0.2.25

These tests help identify forward and reverse lookup problems. A successful lookup does not prove that every required AD service is reachable, so also test routing and firewall paths from the management network to the selected domain controllers.

Configure reliable time synchronization

NTP, or Network Time Protocol, synchronizes clocks between systems. Kerberos uses time-based tickets, so excessive clock skew can cause authentication or domain-join failures even when DNS is correct.

  • Choose NTP servers that are reachable from the ESXi management network.
  • Prefer a time source consistent with the Active Directory environment and organizational time hierarchy.
  • Configure one or more appropriate NTP servers.
  • Start the ESXi NTP service.
  • Set the startup policy so the service starts as required after a host reboot.
  • Compare the ESXi clock with a domain controller before attempting the join.

In the vSphere Client, open the host's time configuration, add the approved NTP servers, start the service, and verify that the displayed host time is correct. The exact labels can differ between vSphere releases.

# Illustrative configuration values; use your organization's approved servers
NTP server: ntp01.corp.example
NTP server: ntp02.corp.example
Service: Running
Startup policy: Start and stop with host

Join the ESXi host to Active Directory using vSphere

The vSphere Client is the management interface used to configure ESXi hosts and vCenter-managed inventory. The usual workflow is:

  1. Select the target ESXi host in the inventory.
  2. Open Manage and then Settings.
  3. Locate Authentication Services or the similarly named directory-services area.
  4. Select Join Domain.
  5. Enter the Active Directory domain name.
  6. Select the desired join method.
  7. Provide the required credentials or authentication proxy address.
  8. Submit the operation and wait for confirmation.
  9. Refresh the authentication-services view and confirm that the directory service type is Active Directory.

For the example environment, use the following non-production values:

  • Host FQDN: esxi1.corp.example
  • Active Directory domain: corp.example
  • Join account: a delegated account permitted to add computer accounts

Choose a domain-join method

Method 1: Join using credentials

Credential-based joining requires the domain name and an authorized Active Directory user name and password. The account does not necessarily need to be a domain administrator; delegated permission to create or join the required computer account is preferable.

  1. Enter the AD domain, such as corp.example.
  2. Select the option to join using credentials.
  3. Enter the authorized domain user name and password.
  4. Submit the join request.
  5. Confirm that the host reports a successful join.

Use a dedicated, controlled account for this operation when possible. Limit who can use it, avoid sharing the password, and follow your organization's credential rotation and auditing procedures.

Method 2: Join using an authentication proxy

An authentication proxy is a separately configured service that assists ESXi with the domain-join process. With proxy-based joining, the workflow uses the domain name and the proxy server address rather than entering AD credentials directly on the ESXi host.

  1. Enter the Active Directory domain name.
  2. Select the authentication-proxy join method.
  3. Enter the IP address of the configured authentication proxy server.
  4. Submit the request and monitor the result.

This method is appropriate when security policy prefers not to enter or retain domain-join credentials on the host. It requires a healthy authentication proxy that is configured for the target domain and reachable from ESXi.

Join-method comparison

  • Using credentials: Requires the domain name and an authorized AD account. It is straightforward for environments that permit controlled credential-based joins.
  • Using an authentication proxy: Requires the domain name and proxy address. It reduces direct credential handling on the host but adds a dependency on the proxy service.

Verify the domain join

Do not treat the completion message as the only validation. Check both the ESXi directory configuration and the resulting access path.

  • Confirm that the host's directory service type is shown as Active Directory.
  • Confirm that the expected computer object appears in Active Directory, where applicable.
  • Search for a domain user or group when adding a vSphere permission.
  • Assign a test permission before testing domain-user access.
  • Test with a non-administrative domain account that has only the intended role and scope.
  • Verify that the local ESXi administrator account still works as an emergency access path.

Post-join validation checklist

  • Directory service status: Expected result is Active Directory. If not, review the join result, DNS, and host identity.
  • Computer account: Expected result is a matching computer object in the intended AD location. If absent or conflicting, check permissions and naming.
  • Domain group lookup: Expected result is that the vSphere permission picker can find the intended group.
  • Permission assignment: Expected result is that the group has the intended role at the intended host, cluster, or vCenter scope.
  • Domain-user access: Expected result is successful access with the assigned role and no unexpected privileges.
  • Local emergency access: Expected result is a documented, protected local account that has been tested without weakening normal controls.

Assign Active Directory permissions

Authentication answers “Who is this user?” Authorization answers “What may this user do?” After the domain join, configure authorization through vSphere roles and permissions.

A permission assigns a vSphere role to a user or group at a selected inventory scope. A role is a collection of privileges, such as viewing objects, operating virtual machines, or administering hosts.

  1. Create or select a dedicated AD security group, such as VSPHERE-ESXI-OPERATORS.
  2. Add approved users to the group through normal AD change-control procedures.
  3. Select the appropriate ESXi host, cluster, or vCenter inventory object.
  4. Add the AD group to the object's permissions.
  5. Assign the least-privilege role that supports the group's duties.
  6. Decide whether the permission should propagate to child objects.
  7. Test with a member of the group.

Prefer groups over direct user assignments. For example, an operations group might receive an operations-oriented role rather than the full Administrator role. Broad administrator privileges should be limited to people and tasks that genuinely require them.

Security and operational considerations

  • Use dedicated AD groups for host or vSphere administration.
  • Use separate groups for different responsibilities, such as read-only monitoring, VM operations, and host administration.
  • Protect the account used to join hosts and limit its delegated permissions.
  • Maintain a break-glass local ESXi administrator account with controlled storage, auditing, and periodic testing.
  • Document the expected access path: direct host access, vCenter access, or both.
  • Review how Active Directory authentication interacts with ESXi Lockdown Mode.
  • Plan for loss of domain controllers, DNS, NTP, or an authentication proxy.

Lockdown Mode restricts direct host access and changes how administrators connect to and manage ESXi. A domain account that works in one access path may not be usable in another when Lockdown Mode is enabled. Test the intended vCenter-managed workflow and retain the documented emergency procedure before enabling or changing Lockdown Mode.

Leave or change domain membership

To remove a host from Active Directory, return to the same Authentication Services or Directory Services area and use the action for leaving or changing the domain. The wording varies by vSphere version.

  1. Review current AD-based permissions and identify which users will lose access.
  2. Confirm that a local ESXi administrator account is available and tested.
  3. Schedule the change because domain-based sessions and management access may be interrupted.
  4. Use the leave-domain action and provide any required information.
  5. Verify the resulting directory service status and local access.
  6. Review or clean up the corresponding computer account in Active Directory according to organizational policy.
  7. Remove obsolete permissions and document the change.

Troubleshoot common join failures

The domain cannot be resolved

Likely causes include incorrect DNS server addresses, an incorrect domain name or suffix, missing AD DNS forwarding, or an unavailable network path to DNS.

  • Verify the DNS servers configured for the ESXi management network.
  • Confirm that the domain and domain-controller names resolve through those servers.
  • Check the host FQDN and correct the DNS suffix if it does not match the intended namespace.
  • Confirm routing and firewall access between ESXi and DNS.

The join returns an authentication, Kerberos, or clock error

Compare ESXi time with the domain-controller time. Confirm that NTP is configured, reachable, and running. Correct time synchronization before retrying. Also verify that the join account has valid credentials and delegated permission to create or join the computer account.

DNS works, but the join cannot complete

Name resolution alone is not enough. Firewall or routing restrictions may block Kerberos, LDAP, SMB, RPC, or other required services. Validate the network path from the ESXi management interface to available domain controllers. Also check for a stale or conflicting computer account in Active Directory and resolve it according to policy.

The host shows Active Directory, but a domain user cannot log in

  • Confirm that the user or group has a vSphere permission.
  • Confirm that the permission is assigned at the correct host, cluster, or vCenter scope.
  • Check the assigned role and inheritance setting.
  • Confirm the user is a member of the expected AD group and that directory lookups work.
  • Review Lockdown Mode and use the intended vCenter-managed access path where applicable.

Authentication-proxy joining fails

Verify the proxy IP address, proxy service health, domain configuration, and network filtering. The ESXi host must be able to communicate with the proxy, and the proxy must be configured to support the target Active Directory domain.

Practical example: grant operations access through an AD group

  1. Create or use the AD group VSPHERE-ESXI-OPERATORS.
  2. Add approved operations staff to the group.
  3. In the vSphere Client, select the intended host, cluster, or vCenter inventory object.
  4. Add the group to the object's permissions.
  5. Assign an operations-oriented role rather than Administrator unless full administration is required.
  6. Set inheritance according to the required scope.
  7. Test access with a member of the group and confirm that prohibited actions remain unavailable.

Exam-relevant distinctions

  • Domain join is not permission assignment: Joining makes AD an identity source; it does not grant universal administration.
  • DNS is foundational: ESXi must resolve the AD namespace and domain controllers using its own configured DNS servers.
  • Kerberos requires accurate time: NTP problems can appear as authentication or join failures.
  • Groups support least privilege: Assign roles to managed AD groups instead of individual users whenever practical.
  • Local access remains important: Retain and test a local emergency administrator account.
  • Lockdown Mode affects access paths: Domain authentication and direct host access must be evaluated together.

Summary

A reliable ESXi-to-Active Directory integration begins with a correct FQDN, functional DNS, reachable domain controllers, synchronized time, and an appropriately delegated join account or configured authentication proxy. Use the vSphere Client's host Authentication Services settings to join the domain, verify the directory service status, and then assign least-privilege roles to AD groups at the required inventory scope.

Finally, test both the intended domain-user workflow and the local emergency access path. Treat DNS, NTP, domain-controller availability, authentication-proxy availability, permissions, and Lockdown Mode as operational dependencies.