VMware ESXi and vSphere Cluster Management

Join an ESXi Host to an Active Directory Domain

Learn how to prepare and join a VMware ESXi host to Microsoft Active Directory in the vSphere Client, then assign secure, group-based permissions and troubleshoot common failures.

Integrating an ESXi host with Microsoft Active Directory (AD) allows the host to use a centralized directory service for user and group authentication. Instead of managing every administrator as a separate local account, you can assign VMware permissions to directory groups and manage membership centrally.

A successful domain join enables directory authentication, but it does not automatically grant VMware administrative rights. After joining the domain, you must assign an appropriate VMware role to the required AD users or groups.

What Active Directory Integration Provides

An ESXi host is VMware's bare-metal hypervisor. When it is joined to an AD domain, it can communicate with the domain and use directory identities for authentication and user or group lookup.

Centralized identity: User accounts and groups are managed in Active Directory rather than separately on each host.
Simpler permission assignment: VMware roles can be assigned to AD groups, such as an operations or virtualization-admins group.
More consistent access: Changes to group membership can update access across multiple hosts or inventory objects without editing each individual user permission.
Reduced local-account dependence: Local ESXi accounts can be reserved for controlled emergency access according to organizational policy.

Authentication and authorization are separate steps. The domain join answers, “Can this host use AD identities?” Permission assignment answers, “What can this particular user or group do?” A domain user may be successfully authenticated and still be denied administration because no VMware permission has been assigned.

For background on VMware permissions and access design, see Assign Permissions and Access Control System.

Terms to Know

Term	Meaning
Active Directory	Microsoft's directory service for centrally managing users, groups, computers, authentication, and identity data.
Domain controller	An AD server that provides directory and authentication services for a domain.
DNS	The name-resolution service ESXi uses to locate the AD domain and domain controllers.
FQDN	A fully qualified domain name containing the host name and DNS domain, such as `esxi1.example.local`.
NTP	Network Time Protocol, commonly used to keep ESXi and domain-controller clocks aligned.
Kerberos	A time-sensitive authentication protocol commonly used by Active Directory.
Authentication proxy	A proxy service that can perform or assist with an ESXi domain join without supplying and retaining AD credentials directly on the host.
Role	A VMware-defined or custom collection of privileges assigned to a user or group.
Lockdown mode	An ESXi access-control feature that restricts direct host administration and must be considered when designing directory-based access.

Prerequisites

Prepare the host and the AD environment before starting the vSphere Client workflow. The most important dependencies are DNS, the host's fully qualified name, time synchronization, network reachability, and authorization to create or reuse the host's computer object.

Requirement	Why It Matters	How to Validate	Typical Failure Symptom
DNS resolution	DNS helps ESXi locate the domain, domain controllers, and directory-related services.	Review the DNS servers configured on ESXi and test forward lookups for the domain and controller names.	The domain cannot be located or the join dialog cannot validate the domain.
ESXi FQDN	The host name and DNS suffix must identify the expected host in the AD DNS namespace.	Confirm that the host name is configured as a name such as `esxi1.example.local`.	The join fails, the host is registered under an unexpected name, or the computer object cannot be created or reused correctly.
Time/NTP synchronization	Kerberos authentication is sensitive to clock differences between the host and domain controllers.	Check the current ESXi time, configured NTP source, and synchronization status.	The join or later authentication fails with a time, Kerberos, or authentication error.
Domain-controller network reachability	The host must communicate with the required AD infrastructure across the network.	Confirm routing, firewall policy, and connectivity from the ESXi management network.	The join times out or cannot contact a controller.
Authorized join account or authentication proxy	The join operation must be allowed to create or reuse the ESXi computer object.	Verify delegated AD rights for the account or validate the approved proxy address and service.	Credentials are rejected or the operation fails while creating or reusing the computer object.

Validate DNS, FQDN, and Time Before Joining

Check the ESXi DNS configuration

Configure DNS servers that can resolve the AD domain and its domain controllers. Pointing ESXi only to a public DNS service or to a DNS server that lacks the internal AD zone commonly causes domain discovery to fail.

Validate both the domain name and individual domain-controller names. A successful lookup of a general internet name does not prove that AD DNS is working.

AD domain:       example.local
Domain controller: dc1.example.local
dc2.example.local
ESXi DNS servers: 10.10.10.10, 10.10.10.11

Confirm the host FQDN

Set a meaningful host name and the correct DNS domain suffix. For example:

Host name:   esxi1
DNS domain:  example.local
Expected FQDN: esxi1.example.local

The expected FQDN should resolve consistently in the organization's DNS. Correct an incorrect host name or suffix before attempting the join.

Check NTP and clock status

Configure a reliable NTP source and confirm that synchronization has completed. The ESXi clock should agree closely with the domain controllers. If NTP is unavailable, correct routing, firewall rules, or the NTP configuration and wait for the host to synchronize before retrying.

Collect the Required Values

Active Directory domain name, such as example.local.
ESXi host FQDN.
DNS server addresses used by the ESXi host.
NTP source and current synchronization status.
An authorized domain-join account, or the address of an approved authentication proxy.
The AD group that should receive VMware permissions after the join.

Choose a Domain-Join Method

Method	Information Required	Credential Exposure Consideration	Appropriate Use Case
Using credentials	AD domain name and an authorized AD account with its credentials.	Credentials are supplied during the join workflow. Protect them and use an account with only the required delegated rights.	Suitable when the organization permits direct credential-based joins and the workflow is operationally simplest.
Using authentication proxy	AD domain name and the approved authentication proxy server address.	Designed to avoid supplying and retaining AD join credentials directly on the ESXi host.	Suitable when security policy requires centralized credential handling or a proxy-based join process.

Use the credential method when delegated account use is acceptable and the environment does not require a proxy. Use the proxy method when the organization has deployed and approved an authentication proxy and wants to reduce direct credential handling on individual hosts.

Join the ESXi Host in the vSphere Client

The exact labels can vary slightly by vSphere release, but the workflow follows the same sequence.

Sign in to the vSphere Client with an account that can manage the target host.
Select the target ESXi host in the inventory. This can be a standalone host or a host managed by vCenter Server.
Open the host's management settings.
Locate the Authentication, Directory Services, or similarly named configuration section.
Start the action to join the host to a domain.
Enter the target AD domain name, for example example.local.
Select the applicable join method: credential-based joining or authentication-proxy joining.
For credential-based joining, provide the authorized AD account and required authentication information.
For proxy-based joining, provide the approved authentication proxy server address and any fields requested by the client.
Submit the operation and wait for the task to complete. Do not treat the dialog closing as proof of success; inspect the task result.
Reopen or refresh the directory-service settings and verify that the selected directory service type reports Active Directory.

Post-Join Access Control

Assign permissions to groups

After the directory service reports Active Directory, add AD identities to the host or vCenter permission model. Prefer groups over individual users. For example, assign the required role to VMware-ESXi-Admins rather than adding every administrator separately.

Open the permissions management view for the intended host, cluster, folder, or other inventory scope.
Choose the option to add a user or group.
Search the configured AD identity source and select the appropriate group.
Assign the minimum VMware role required for the group's duties.
Confirm whether the permission should propagate to child inventory objects.
Save the permission and document the scope and justification.

Use separate groups and least-privilege roles for operators, auditors, and full administrators. A user who can be found in AD but cannot perform a task usually has an authorization problem, not a domain-join problem.

Test access safely

Test with a non-administrative directory account or an appropriate test group. Confirm both authentication and authorization:

Can the identity sign in through the intended management path?
Can the identity perform the permitted operations?
Are restricted operations correctly denied?
Does the permission apply at the intended inventory scope?

Maintain a controlled local emergency access method in accordance with policy. Directory integration should not eliminate the ability to recover a host when directory services or network connectivity are unavailable. Review the design together with local-account controls and lockdown mode, because lockdown mode can restrict direct host administration even when directory authentication is configured.

Verification and Operational Checks

The join task completed successfully without an error.
The host's directory-service type displays Active Directory.
The configured domain is the intended domain.
Expected AD users and groups can be searched or selected during permission assignment.
An authorized directory identity can authenticate.
The identity receives the intended VMware role and no more privilege than required.
An unauthorized or insufficiently privileged test identity is denied the expected operations.
Monitoring and support documentation identify the domain, groups, join method, and emergency access procedure.

Practical Examples

Credential-based join

An administrator prepares a host named esxi1.example.local. The host uses DNS servers that resolve example.local and its domain controllers, and NTP keeps the host clock aligned with directory-service time. In the host authentication settings, the administrator joins example.local using an account delegated to add computer objects. After the directory service changes to Active Directory, the administrator assigns a suitable role to the VMware-ESXi-Admins group.

Proxy-based join

A security policy prohibits presenting domain-join credentials directly to individual hosts. The administrator enters the AD domain and the approved authentication proxy address, confirms proxy reachability, and completes the join. Group-based VMware permissions are then assigned in the same way as for a credential-based join.

Successful join but denied access

The host reports Active Directory as its directory service, and an AD user can be located, but the user cannot administer the host. The domain join is working. The corrective action is to assign that user or, preferably, an appropriate AD group a VMware role at the intended host or inventory scope.

Domain Join Troubleshooting Guide

Symptom	Likely Cause	Validation Step	Corrective Action
Domain cannot be resolved	Incorrect ESXi DNS settings, an incorrect domain name, or missing domain-controller records.	Review DNS server settings and verify forward resolution for the AD domain and controller names.	Correct the DNS configuration or domain name, then retry the join.
Join fails with an authentication-related error	Invalid credentials, a disabled or locked account, insufficient join rights, or an existing computer-object conflict.	Check account status, credentials, delegated permissions, and the target computer object.	Use a valid, appropriately delegated account or resolve the existing computer-object condition.
Join fails because of time mismatch	ESXi time differs materially from domain-controller time, or NTP is not synchronized.	Check current time, NTP configuration, synchronization state, and reachability of the NTP source.	Correct NTP and network configuration, wait for synchronization, and retry.
Join succeeds but AD users cannot administer the host	No VMware permission exists, the role lacks required privileges, or the permission is applied at the wrong scope.	Inspect the host or vCenter permissions and verify the user's group membership.	Add the intended AD group at the correct scope and assign the appropriate role.
Proxy-based join fails	Incorrect proxy address, blocked network path, unavailable proxy service, or incorrect proxy configuration.	Verify the address, service availability, routing, and firewall policy between ESXi and the proxy.	Correct the proxy configuration or network path, then retry the join.

Security and Administration Considerations

Assign permissions to AD groups whenever possible; group membership is easier to review and revoke consistently than many individual assignments.
Use least-privilege VMware roles for operators and auditors. Reserve full administrative roles for personnel who require them.
Restrict the domain-join account's rights through delegation. Do not use a highly privileged domain administrator account when a narrower permission set is sufficient.
Protect any credentials used during the join and follow the organization's secret-handling requirements.
Keep local ESXi accounts, directory identities, host access controls, vCenter permissions, and lockdown mode in one access-control design rather than treating them as independent features.
Document emergency access and test it under controlled conditions before relying on directory integration for all administration.

Final Checklist

DNS servers can resolve the AD domain and domain controllers.
The ESXi host has the expected FQDN, such as esxi1.example.local.
NTP is configured and the host clock is synchronized.
The management network can reach the required AD infrastructure or authentication proxy.
The join account is authorized, or the proxy is approved and available.
The host is joined through its authentication or directory-services settings.
The task result reports success and the directory service type reports Active Directory.
AD groups receive appropriate VMware roles at the correct scope.
A test identity can authenticate and perform only its intended operations.
A controlled local emergency access method remains available.