FFoundationalActive Directory
Understand how certificates are used for authentication in Active Directory through PKINIT and Schannel, why certificate-based authentication creates unique security implications, and why controlling certificate issuance can be functionally equivalent to controlling domain authentication.
Certificate-based authentication matters because it creates a parallel authentication path that is often less monitored and less restricted than password-based authentication. Passwords can be rotated, accounts can be locked, and password policies can enforce complexity, but certificates issued by a trusted CA are valid for their entire validity period regardless of password changes.
This has three critical implications. First, a certificate obtained through a misconfigured template works as a credential even after the target user changes their password. Second, certificates are often valid for months or years, creating a persistence window far longer than most credential theft techniques. Third, certificate authentication through PKINIT looks like legitimate Kerberos traffic, making it harder to distinguish from normal authentication.
For defenders, this means that a compromised AD CS deployment is not fully remediated by resetting passwords. The certificates themselves must be revoked, and the issuance path must be closed.
Active Directory supports authenticating users with certificates instead of passwords. The primary mechanism is PKINIT: an extension of the Kerberos protocol that allows a client to present a certificate during the initial authentication exchange and receive a Ticket Granting Ticket in return. Once a user has a TGT, the rest of the authentication flow is identical to password-based Kerberos: the certificate simply replaces the password as the proof of identity.
This means that anyone who can obtain a certificate that the domain trusts for authentication can authenticate as the identity that certificate claims. If the certificate says you are a Domain Admin, and the domain trusts the CA that issued it, you get a Domain Admin TGT. The certificate does not need to be legitimately issued; it only needs to be signed by a trusted CA and contain the right identity and key usage properties.
Think of certificate-based authentication as an alternative door to the same building. Password-based Kerberos is the front door: you prove your identity with a password, and the KDC gives you a TGT. PKINIT is a side door: you prove your identity with a certificate, and the KDC gives you the same TGT.
Once you are inside the building, it does not matter which door you used. The TGT works the same way regardless of whether it was obtained through a password or a certificate. This is why certificate-based authentication is so significant for attackers: it provides an alternative path to the same Kerberos credentials, and that alternative path may have weaker controls than the password-based one.
IETF · The authoritative IETF specification for PKINIT: the Kerberos extension that enables certificate-based authentication covered in this lesson
Microsoft · Microsoft Kerberos overview providing context for how PKINIT integrates with the standard Kerberos authentication flow
Schannel provides a third door: certificate authentication over TLS, primarily via LDAPS. When PKINIT is not available, an attacker with a certificate can still authenticate through Schannel and perform actions over LDAP, including granting themselves privileges or resetting passwords.
Common misunderstandings
Certificate-based authentication is increasingly used in enterprise environments for smart card logon, VPN authentication, and Wi-Fi access. In organizations that have deployed AD CS, the infrastructure for PKINIT authentication already exists; the question is whether the certificate issuance controls are strong enough to prevent abuse.
In penetration testing, the combination of misconfigured certificate templates and PKINIT authentication is one of the most reliable domain compromise paths. An attacker with a standard domain account can request a certificate claiming a privileged identity, use PKINIT to obtain a TGT for that identity, and then operate with full privileges. The entire chain uses legitimate AD CS and Kerberos infrastructure: no exploits, no malware, no unusual network traffic.
When PKINIT is not supported, which occasionally happens in environments where the KDC lacks the required EKU on its own certificate, Schannel over LDAPS provides a fallback path. Tools like PassTheCert enable LDAP operations with certificate authentication, allowing an attacker to grant themselves DCSync rights, configure delegation, or reset passwords, all authenticated through a certificate rather than a password.
Interview answer
When asked about certificate-based authentication, the strongest answer connects certificates to the Kerberos authentication flow the interviewer already understands.
A good response: AD supports authenticating with certificates through PKINIT, which is a Kerberos extension. Instead of proving identity with a password during the AS-REQ, the client presents a certificate. If the certificate is signed by a trusted CA and has the right EKU, the KDC issues a TGT, the same TGT you would get with a password.
This matters because it means a certificate is functionally a credential. If an attacker can get a certificate claiming a privileged identity, through a misconfigured template, for example, they can authenticate as that user. And unlike a password, the certificate survives password resets and can be valid for months or years.