ESXi host joined to Active Directory via vSphere Authentication Proxy cannot perform Kerberos authentication. Filepath /etc/krb5.keytab shows empty

Products

• VMware vSphere ESXi

Issue/Introduction

ESXi host joined to AD through vSphere Authentication Proxy (CAM) cannot perform Kerberos-dependent operations.

• User/group searches from the vCenter Server UI (hostd's vim.UserDirectory.retrieveUserGroups) fail silently or return no results.
• The esxAdminsGroupAutoAdd feature does not function on the host.
• kinit -k fails on the host with: "Pre-authentication failed: Preauthentication failed while getting initial credentials"
• klist -kte /etc/krb5.keytab on the host reports: "Unsupported key table format version number while starting keytab scan"
• /etc/krb5.keytab on the host is 0 bytes or empty.

Environment

• vCenter Server 9.1 and later with vSphere Authentication Proxy enabled
• ESXi 8.0.3, 9.1, and later hosts joined to Active Directory via the Authentication Proxy

Cause

The vSphere Authentication Proxy join path (LikewiseJoinDomainWithMachineAccount) saves the machine password only to the local credential store (LsaPstoreSetPasswordInfoA) but does not write the Kerberos keytab. The alternative credential-based join path (LikewiseJoinDomain → DJRunJoinProcess → LsaJoinDomain) additionally calls LsaSavePrincipalKey, which writes /etc/krb5.keytab. Because AD login authenticates through the credential store (lsass), it is unaffected.

However, any operation that shells out to kinit -k  including hostd's directory user/group search and the esxAdminsGroupAutoAdd feature depends on the keytab and fails when it is empty.

Resolution

Preferred method :

Join the Esxi host using domain credentials instead of Authentication Proxy:
1. Rejoin the ESXi host to Active Directory using domain administrator credentials (interactively via Host UI or vCenter remediation).

Note : This join path writes the keytab and fully restores both AD user/group search and esxAdminsGroupAutoAdd functionality.

Workaround :

Manage permissions through vCenter instead of the ESXi Host UI:
1. Use the vCenter Server UI to assign permissions directly to AD users and groups (Add Permission dialog).

• Log in to the vSphere Client as an administrator.

• Navigate to Administration and click Global Permissions.

• Click Add to open the Add Permission dialog box.

• From the Domain drop-down menu, select the appropriate Active Directory domain for the user or group.

• Enter a name in the Search box and select the target AD user or group.

• Select the appropriate role (e.g., Administrator) from the Role drop-down menu.

• Select the Propagate to children check box to apply to child objects.

• Click OK to apply the permissions.

 

 

Note: vCenter's permission engine does not invoke kinit -k and is unaffected by the empty keytab. vCenter permissions are separate from the host's local permission store. A permission granted this way works only when connecting through vCenter, not when connecting directly to the host.

Additional Information

The empty keytab is not a transient state or a customer AD topology issue. it is a consistent outcome of the Authentication Proxy join path and occurs identically across ESXi versions (8.0.3, 9.1.0) and vCenter versions (9.1.1). The defect resides in the Authentication Proxy join implementation itself. Until a fix is released, hosts that require functional keytab-dependent features (direct host AD authentication, local permission assignment to AD users) must be re-joined using domain credentials.