Certificate Templates and Enrollment Rights

ActiveDirectoryFoundationsbeginner12 min

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.

This lesson builds on

Theory

Core Idea

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.

Mental Model

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?

Why It Matters

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.

Key Concepts

  • Certificate templates — AD objects that define what a certificate will contain: purpose (EKU), validity, key properties, and whether the requester can specify the subject identity
  • Enrollment rights — ACL-based permissions on the template object that control who can request certificates; if Domain Users or Authenticated Users has Enroll rights, any domain account can use that template
  • Extended Key Usage (EKU) — determines what a certificate can be used for; the critical EKUs for attackers are Client Authentication, PKINIT Client Authentication, Smart Card Logon, and Any Purpose, because these allow the certificate to function as an authentication credential
  • ENROLLEE_SUPPLIES_SUBJECT flag — the most dangerous single template setting; when enabled, the person requesting the certificate can specify whose identity the certificate claims, rather than the CA enforcing that the certificate matches the requester
  • Issuance requirements — controls like CA manager approval and authorized signatures can add review gates, but many templates have these set to zero, meaning the CA issues certificates automatically without human review

Common Misunderstandings

  • The CA decides who gets what certificate. The CA follows the template. If the template allows it, the CA issues it, regardless of whether the result is dangerous.
  • Enrollment rights and template configuration are the same thing. Enrollment rights control who can submit a request, but the template controls what the resulting certificate can do. Both must be restrictive for the template to be safe.
  • All templates are equally risky. The combination of specific settings determines risk. A template that requires manager approval or does not allow subject specification is fundamentally different from one that does.
  • Having many templates is inherently dangerous. The number of templates is not the issue. The configuration of each template and its enrollment permissions are what matter.

In Real Engagements

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.

Communication

How to Explain It in an Interview

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.

Likely Follow-Up Questions

  • If you found a template with Client Authentication EKU and enrollee-supplied subject enabled, but enrollment was restricted to Domain Admins, would this be a finding? Why or why not?
  • What is the difference between a template where the CA enforces the subject identity versus one where the enrollee supplies it, and why does this distinction matter for security?
  • How would you explain to a client that their CA is not compromised but their certificate templates still represent a critical risk?

Further Reading