Bypassing Microsoft KB5014754 and KDC_ERR_PADATA_TYPE_NOSUPP in Certipy

2026-03-24

This was an internal pentest structured as a purple team exercise. I conducted the attacks while the client's SOC monitored for visibility gaps in real time. The environment was large and I had roughly one day to work through it. During this project I encountered an obstacle for the first time and I thought of documenting it, in case anyone else might come across this.

Getting credentials

One of the client's requests was to find and leverage any accounts that use a specific password provided by my point of contact. The methodology for finding these accounts was simple:

OSINT -> list of employees -> find the email address username convention -> test usernames and the password against Kerberos with kerbrute

After conducting some quick recon (remember, I had one day)

fping to find alive hosts -> nmap for SMB/HTTP/DNS/KRBS/FTP/TELNET -> categorize workstations and DCs

I came across their ADCS, which was handled by their DCs, which is also the usual case. Not to my surprise, some templates where vulnerable to multiple issues, one of which was ESC1. To those unfamiliar with this, ESC1 is a vulnerability that arises when a template is misconfigured and allows the certificate requester to define the Subject Name in their request themselves. This basically allows a user with valid credentials to request a certificate as another user, even one with administrative rights.

Round one: KDC_ERR_CLIENT_NAME_MISMATCH

The tool of the trade for these vulnerabilities is by far Certipy. It enables you to attack the ESC vulnerabilities tied to ADCS. The usual path for ESC1 is the following command:

certipy req -u '[USERNAME]' -p '[PASSWORD]' -dc-ip '[DC_IP]' -target '[CA_HOSTNAME]' -ca '[CA_NAME]' -template '[VULNERABLE_TEMPLATE_NAME]' -upn '[DOMAIN_ADMIN]'

followed by authenticating to the CA with the resulted pfx certificate to gain a TGT:

certipy auth -pfx DOMAIN_ADMIN.pfx -dc-ip [DC_IP]

Nevertheless, the authentication command wouldn't succeed, returning an "KDC_ERR_CLIENT_NAME_MISMATCH: Object SID mismatch" error. After some digging, I found out this was the result of the following Microsoft patch: https://support.microsoft.com/en-us/topic/kb5014754-certificate-based-authentication-changes-on-windows-domain-controllers-ad2c23b0-15d8-4340-a468-4d4f3b188f16

Prior to this patch, the KDC mapped a certificate to an AD account purely on name-based fields, specifically the UPN in the SAN. ESC1 abuses exactly this: spoof the UPN, the KDC trusts it, you get a TGT as the target account. Weak, name-based mappings are inherently spoofable because names can be forged.

KB5014754 introduced two mechanisms that break this:

  1. SID Extension on issued certificates
  2. Patched Enterprise CAs now embed a new non-critical extension in every issued certificate containing the Object SID of the account the cert was issued to.
  3. KDC-side SID validation during PKINIT
  4. When the patched KDC processes a PKINIT AS-REQ, it now checks whether the SID in this extension matches the SID of the account the certificate is being used to authenticate as

The fix for this command is simply to append the -sid [DOMAIN_ADMIN_SID] flag to the certipy req command. This way, the requester adds to the certificate the spoofed account's SID. Then it complies with the patch's guidelines.

Round two: KDC_ERR_PADATA_TYPE_NOSUPP

After doing this, the auth command returned a different error, namely "KDC_ERR_PADATA_TYPE_NOSUPP". This basically means that the DC does not support PKINIT (which for a bit made me think this was all for nothing). After some digging I found that even though a DC might not support PKINIT, LDAPS does. Thus, one can connect to LDAPS. LDAPS authentication uses Schannel, the Windows TLS stack, at the transport layer. LDAPS and KDC PKINIT are entirely separate authentication pathways.

Fortunately, Certipy is kind enough to provide us this functionality through the auth command:

certipy auth -ldap-shell -pfx DOMAIN_ADMIN.pfx -dc-ip [DC_IP]

This gave me access to LDAP as a domain admin. From this point, the choices are to change a DA's password, add a new DA etc.

If you've landed here with the same errors, hope this gets you unstuck.