When attempting to join an ESXi host to an Active Directory domain via the vCenter Authentication Proxy service (vmcamd), the operation fails.
Reviewing the vCenter Server logs at /var/log/vmware/vmcamd/vmcamd.log reveals the following error signatures:
INFO: Creating machine account for Host '<ESXi_FQDN>', OU ''
INFO: VmCamSrvCreateMachineAccount failed. (50)
INFO: VmCam HTTPS request Handler failed with 50vSphere 8.x
vSphere 9.x
LDAP Error 50 stands for LDAP_INSUFFICIENT_ACCESS. This explicitly indicates a permission denial from the Active Directory (AD) side.
The Service Account bound to the vCenter Authentication Proxy does not have sufficient administrative privileges on the target Active Directory container (typically the default Computers container) to create the computer object or modify its mandatory attributes.
To resolve this issue, the Active Directory team must verify the current permissions of the Service Account and ensure it strictly aligns with Broadcom’s official security requirements.
Step 1: Identify the Service Account in Use
Before checking AD permissions, log into the vCenter via SSH and run the following command to verify the exact Service Account username configured for the proxy:
/usr/lib/vmware-vmcam/bin/camconfig status
Note down the username from the output to use in the verification steps below.
Step 2: How to Verify Existing Permissions in Active Directory
Active Directory does not display advanced security tabs by default. Follow these steps to audit what permissions the Service Account currently holds on the target container:
Reset Password
Read and write Account Restrictions
Validated write to DNS host name
Validated write to service principal name (SPN)
Read and write public information
Note: Granting 'Public Information' automatically satisfies the official requirement for Read/Write Description.
Step 3: Rectify Permissions according to KB 322859
If the Service Account is missing critical rights during your inspection in Step 2, the AD Team must update the delegation on the target OU/Container to include the following mandatory permissions:
Reset Password
Read and write Account Restrictions
Validated write to DNS host name
Validated write to service principal name (SPN)
Read and write public information
If the AD team denies any permission gaps, engage the AD team to enable temporary failure auditing to capture the exact failure signature in the Windows Security Event Log (Event ID 4662):
* Access Mask 0x1 (Create Child): The account lacks rights to create the computer object shell.
* Access Mask 0x20 (Write Property): The account can create the object but lacks rights to write required attributes such as the SPN or dNSHostName.
Note: While Access Masks 0x1 and 0x20 are the most common signatures encountered during this vCenter Proxy join failure, other codes (e.g., 0x2 for Delete Child during overwrites) may appear and should be investigated based on standard Active Directory authorization behavior.