FFoundationalActive Directory

Certificate-Based Authentication

Foundationsbeginner12 min

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.

This lesson builds on

Why it matters

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.

Key Concepts

  • PKINIT — a Kerberos extension that allows certificate-based initial authentication; the client presents a certificate instead of a password during the AS-REQ, and the KDC returns a TGT if the certificate is valid and trusted
  • Trust requirements — for PKINIT to work, the certificate must be signed by a CA listed in the NTAuthCertificates AD object and must contain an EKU that permits client authentication (Client Authentication, Smart Card Logon, or PKINIT Client Authentication)
  • Identical TGT — the TGT obtained through PKINIT is functionally identical to one obtained through password authentication; once issued, it provides the same access and capabilities
  • Certificate persistence — certificates survive password changes; a certificate issued before a password reset remains valid and can still be used to obtain TGTs until it expires or is revoked
  • Schannel fallback — when PKINIT is unavailable, Schannel provides an alternative certificate authentication path via TLS; an attacker can authenticate over LDAPS and perform privileged actions through LDAP operations

Theory

Core idea

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.

Mental model

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.

Diagram

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.

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 the same as smart card authentication. Smart cards are one delivery mechanism for certificates, but PKINIT works with any certificate that meets the trust and EKU requirements, not just those stored on physical smart cards.
  • Password rotation invalidates certificates. Changing a user's password does not affect certificates already issued for that identity. The certificate remains a valid authentication credential until it expires or is explicitly revoked.
  • PKINIT is a separate authentication system from Kerberos. PKINIT is an extension of Kerberos, not a replacement. It changes how the initial authentication happens but produces the same TGT that standard Kerberos does.
  • Schannel authentication is rarely useful. While fewer protocols support Schannel by default, LDAPS is commonly available in AD CS environments, and LDAP access is sufficient to escalate privileges through ACL modifications, RBCD attacks, or password resets.

Real-world context

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.

Communication

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.

Follow-up questions

  • If you compromise a certificate for a Domain Admin, and the organization resets that account's password, can you still use the certificate? Why?
  • What is the difference between PKINIT authentication and Schannel authentication, and when would an attacker use one over the other?
  • How would you explain to a stakeholder why revoking certificates is part of incident response when they have already reset all compromised passwords?

Further Reading

Next upAbusing Misconfigured Certificate Templates