Troubleshooting vCenter Authentication Proxy Join Failure (LDAP Error 50)
search cancel

Troubleshooting vCenter Authentication Proxy Join Failure (LDAP Error 50)

book

Article ID: 445996

calendar_today

Updated On:

Products

VMware SDDC Manager / VCF Installer

Issue/Introduction

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 50

Environment

vSphere 8.x

vSphere 9.x

Cause

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.

Resolution

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:

  1. Log into a Domain Controller and open Active Directory Users and Computers (dsa.msc).
  2. Click View on the top menu bar and ensure Advanced Features is checked. (Crucial: Without this, the Security tab will be hidden for default containers).
  3. Locate the target container (e.g., the default Computers container).
  4. Right-click the container and select Properties.
  5. Switch to the Security tab, then click the Advanced button near the bottom.
  6. In the Permissions tab, look for entries assigned to the Service Account (identified in Step 1).
  7. Double-click the entry (or select it and click Edit) to open the Permission Entry window. Inspect the granular checkboxes to ensure they match the mandatory requirements from KB https://knowledge.broadcom.com/external/article?articleNumber=322859 :

    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

Additional 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.