FFoundationalActiveDirectory
Understand how certificate templates control what certificates get issued and who can request them, and why template configuration and enrollment permissions are the primary attack surface in AD CS — not the certificate authority itself.
Certificate templates are the blueprints that define every certificate an AD CS enterprise CA can issue. Each template specifies the certificate's properties — its purpose, its validity period, its key usage, and crucially, whether the requester can specify the identity the certificate claims. Enrollment rights determine who is allowed to request a certificate using each template. Together, these two controls — what the template allows and who can use it — determine whether a certificate request path is safe or dangerous.
The CA itself does not decide what to issue based on its own judgment. It follows the template. If the template says anyone in the domain can request a certificate that authenticates as any user, the CA will do exactly that. The most common AD CS vulnerabilities are not bugs in the CA — they are templates configured in a way that grants more power than the administrator intended.
Think of a certificate template as an order form at the passport office. The form determines what kind of passport you get: how long it is valid, what permissions it grants, and whether you can fill in someone else's name on the application. Enrollment rights determine who is allowed to pick up and submit that form.
A dangerous template is one where the form lets you write in any name you want, the resulting passport grants full access, and any employee is allowed to submit the form. The passport office processes it correctly — the problem is that the form should never have been designed that way. When auditing AD CS, the question is always: what can this template produce, and who can trigger it?
Microsoft · Official Microsoft reference for certificate template architecture, version differences, and security permissions
Microsoft · Microsoft AD CS overview providing broader context for how templates fit within the certificate services architecture
Templates and enrollment rights matter because they are the exact point where AD CS misconfiguration turns into exploitable risk. A template that combines three properties — the requester can specify the subject identity, the certificate enables authentication, and low-privilege users can enroll — creates a direct path from a standard domain account to any identity in the domain, including Domain Admin.
This is not theoretical. Misconfigured templates are among the most common findings in AD CS assessments. They are also among the most impactful, because exploiting them requires no special tools, no elevated privileges, and no interaction with the target user. The attacker simply requests a certificate, specifies the target identity, and authenticates as that user — using the CA's own legitimate enrollment process.
In practice, many organizations have certificate templates that were created during initial AD CS deployment — sometimes years or even a decade ago — and have never been reviewed. Default templates and templates created by following outdated Microsoft documentation often include overly permissive settings that were not considered dangerous at the time but are now well-understood attack paths.
The SpecterOps research that categorized AD CS abuse paths found that template misconfiguration accounts for the majority of exploitable findings. In penetration tests, it is common to find templates where standard domain users can request certificates with authentication EKUs and enrollee-supplied subject names. The organizations affected are often surprised because the CA is functioning correctly — the issue is that the template was designed in a way that grants far more power than anyone realized.
When asked about certificate templates, the strongest answer explains why template settings create risk rather than just listing which settings are dangerous.
A good response: Certificate templates define what a certificate can do and who can request it. The dangerous combination is when a template allows the requester to specify the subject identity, includes an EKU that enables authentication, and grants enrollment rights to low-privilege users. When all three are present, any domain user can request a certificate as any other user — including Domain Admin — and the CA issues it because it is following the template exactly as configured.
The risk is not a bug in the CA. It is a template that was designed to be more permissive than the administrator intended.