Troubleshooting ESXi AD Join

Troubleshooting ESXi AD Join
February 2, 2022 No Comments Active Directory,ESXi,Microsoft,VMware neudorfer

I’ve made a lot of progress but after successfully adding 200+ hosts to the domain using the steps in this article here, I started to run into errors. A ton of trial and error later, I’ve included most of the common problems to what I found below. These are not necessarily all the issues you will run into. They are also presented without liability if you try running the fixes. It’s worked in my environment and applied after testing in non-prod along with implementing normal change controls used by my organization. 



Default limit to number of workstations an account can join to the domain –

  – add image of error here – 

One of the first errors I ran into was that my account had a set number of Joins. Reaching out to VMware pointed me to check with my Server (active directory{?}) team. They updated the service account being used to have a max number of joins. This cleared up the first issue but I was still running into errors.


Active Directory (AD) domain permissions an AD user needs –

Some businesses may leverage a security concept of “least permissions”,”least privileged user” or “least privilege model”. In that case, the use of Domain Administrator accounts may not be desirable.
This article defines the least amount of Active Directory (AD) domain permissions an AD user needs on an Organizational Unit (OU) or Computers container to successfully join a vCenter Server appliance in to an AD domain.

Microsoft has documented minimally required permissions.

Reset Password
Read and write Account Restrictions
Validated write to DNS host name
Validated write to service principal name
Create and Delete Computer objects
The additional permission required is Read/Write public information and Description.

I want to make note of this last line. It’s not very obvious in the KB or any other article. Read/Write Description is the second permission that the account needs. We’re doing testing now to see if this is one of the fixes. 


Network Firewall –

This issue may occur when the network firewall is blocking the required ports.

Firewall access: Make sure that there is no firewall blocking the following ports both UDP and TCP:

88 – Kerberos authentication
123 – NTP
135 – RPC
137 – NetBIOS Name Service
139 – NetBIOS Session Service (SMB)
389 – LDAP
445 – Microsoft-DS Active Directory, Windows shares (SMB over TCP)
464 – Kerberos – change/password changes
3268- Global Catalog search



This is the current error I’m dealing with. Googling it leads to articles talking about permissions. You should definitly double check permissions but working with our server team we’ve proven that they are not an issue. Vmware has been going back and fourth working on getting more logs. 


These are the steps VMware requested we go through to get better logging. The commands in red to set logging levels DID NOT work. I’ve included the one that did below in green.

Enabling logging for Likewise agents on ESXi/ESX (1026554) —
  • In an SSH session to the host, run:  /usr/lib/vmware/likewise/bin/domainjoin-cli leave
  • Then restart the likewise agent, run: /etc/init.d/lwsmd restart
  • Set the log file location, run /usr/lib/vmware/likewise/bin/lwsm set-log file /var/log/likewise.log
  • Then set the logging levels, run the following:
    • /usr/lib/vmware/likewise/bin/lwio set-log-info trace

    • /usr/lib/vmware/likewise/bin/lw set-log-level trace
    • /usr/lib/vmware/likewise/bin/lwnet set-log-level trace
    • /usr/lib/vmware/likewise/bin/lwsm set-log-level trace


  • Then immediately try joining the domain, run: /usr/lib/vmware/likewise/bin/domainjoin-cli join [the AD domain] [your user name] [your password]
  • If the domain join command produces an error, grab a screenshot of that error, and produce new host logs with our new levels set. This should all be done together.


About The Author