TTechniqueActiveDirectory
Learn to identify and exploit certificate templates where a low-privilege user can request authentication certificates for any identity in the domain, and explain why this common misconfiguration creates a direct path from standard domain user to domain compromise.
Misconfigured certificate templates are among the most common and most impactful findings in AD CS assessments. A single template with the wrong combination of settings can allow any domain user to request a certificate that authenticates as Domain Admin — using the CA's own legitimate enrollment process. No exploit code is needed, no vulnerability is being exploited in the traditional sense, and the CA is functioning exactly as configured.
This makes template misconfiguration uniquely dangerous and uniquely difficult to communicate. The finding is not that something is broken — it is that something is configured in a way that grants far more power than anyone intended. Organizations that have never audited their AD CS templates often have this exact misconfiguration, sometimes on templates that have existed since the original deployment.
A valid domain user account with enrollment rights on the vulnerable template. The template must have all of the following: the ENROLLEE_SUPPLIES_SUBJECT flag enabled (allowing the requester to specify the certificate's identity), an Extended Key Usage that permits authentication (Client Authentication, Smart Card Logon, PKINIT Client Authentication, or Any Purpose), no manager approval requirement, and no authorized signature requirement. The CA must be an Enterprise CA listed in NTAuthCertificates.
The CA is designed to follow templates. When a template says the requester can specify the subject identity, the CA does not second-guess that decision — it issues the certificate with whatever identity the requester provides. The attack works because the CA is doing exactly what it was configured to do.
The template combines two things that should not coexist: the ability for any user to enroll and the ability for the enrollee to choose any identity. The resulting certificate is legitimate from the CA's perspective — it is signed by a trusted authority and contains valid authentication properties.
A certificate that authenticates as any identity in the domain. The attacker requests a certificate specifying a privileged identity — typically Domain Admin — and uses PKINIT to obtain a TGT for that identity. This is functionally equivalent to knowing the target's password, but the certificate persists through password resets and can remain valid for the template's entire validity period — often months or years.
This technique typically converts a low-privilege domain foothold into domain compromise in a single step. After gaining any domain user account — through password spraying, Kerberoasting, or initial access — the attacker enumerates AD CS templates for this misconfiguration. If found, it provides the most direct privilege escalation path available: from standard user to Domain Admin through a single certificate request.
When asked about AD CS template abuse, the strongest answer explains why the misconfiguration creates risk rather than listing which settings are dangerous.
A good response: The most common AD CS finding is a template that combines three things: any domain user can enroll, the requester can specify the certificate's identity, and the certificate enables authentication. When all three are present, I can request a certificate claiming to be Domain Admin, and the CA issues it — because the template says to. Then I use that certificate with PKINIT to get a TGT as Domain Admin.
The CA is not compromised. It is doing exactly what the template tells it to do. The fix is changing the template configuration, not patching the CA.
Your certificate authority has a template — essentially an order form — that lets anyone in the organization request an identity document claiming to be any other person, including administrators. The document is automatically issued without review. An attacker with any employee account can use this to obtain credentials for your most privileged accounts. The fix is straightforward: change the template settings so the system verifies the requester's identity rather than letting them choose it. No systems need to be replaced — only the template configuration needs to be tightened.
Finding: Misconfigured Certificate Template Allows Arbitrary Identity Certificate Requests. The certificate template [template name] on CA [CA name] is configured with ENROLLEE_SUPPLIES_SUBJECT enabled, Client Authentication EKU, and enrollment rights granted to [group]. This allows any member of [group] to request a certificate for any identity in the domain, including Domain Admin, without manager approval. An attacker exploiting this misconfiguration can obtain a TGT for any user via PKINIT, achieving immediate domain compromise from a standard domain user account.
Severity: Critical.
Recommendation: Disable the ENROLLEE_SUPPLIES_SUBJECT flag on this template. If subject specification is required for legitimate use, restrict enrollment to a dedicated security group and enable CA manager approval.