How to audit AD CS certificate templates: Find dangerous templates and fix them safely

A single misconfigured Active Directory Certificate Services template can let any domain user obtain a certificate that authenticates as a domain administrator, and the result survives password resets. Templates are created once, copied for new projects and published to issuing CAs for years, so few organisations know which ones are live, who can enrol in them and what the issued certificates can do. This runbook shows how to inventory published templates, read the attributes that matter, recognise the escalation conditions catalogued as ESC1 to ESC4 and ESC15, and fix each finding with a test and rollback. It is for PKI owners, AD administrators and security teams auditing an internal Microsoft PKI. For the wider architecture and CA hardening, see the AD CS Security Guide.

This is an independent guide from NHI Mgmt Group, based on Microsoft's public documentation and the SpecterOps "Certified Pre-Owned" research as of November 2026. It is not sponsored or reviewed by Microsoft or SpecterOps. Test every change in a non-production PKI first.

Key takeaways

• Only published templates issue certificates. Start from the templates each enterprise CA has enabled (Get-CATemplate or certutil -CATemplates), then read their definitions in the configuration partition.
• Four attributes decide most risk. Who can enrol (the template ACL), who supplies the subject (msPKI-Certificate-Name-Flag), what the certificate can do (EKUs) and whether issuance needs approval (msPKI-Enrollment-Flag and msPKI-RA-Signature).
• The classic finding is ESC1. Low-privileged enrolment plus "Supply in the request" plus an authentication EKU, without manager approval, lets the requester name any account in the certificate.
• Template ACLs are attack surface too. Write, WriteDACL or ownership held by broad groups lets an attacker turn a safe template into an ESC1 template (ESC4).
• Fix with the least disruptive control first. Unpublish unused templates, remove broad enrolment rights, then change subject handling or EKUs, and monitor issued certificates throughout.

When you need this

• Attack path reduction: certificate abuse maps to ATT&CK T1649 Steal or Forge Authentication Certificates. Certificates issued from a vulnerable template stay valid until they expire or are revoked, so they are a persistence route as well as an escalation one.
• Posture findings: Microsoft Defender for Identity includes AD CS assessments for ESC1, ESC2, ESC3, ESC4 (template owner and template ACL), ESC6, ESC7, ESC8, ESC11 and ESC15. Some require a Defender for Identity sensor on the AD CS server.
• Before PKI changes: migrations, new issuing CAs and certificate-based authentication projects are the right moment to remove templates nobody uses.
• Audits: NIST SP 800-53 SC-17 Public Key Infrastructure Certificates and CM-6 Configuration Settings apply directly.

Before you start

The attributes you will read

Microsoft's [MS-CRTD] specification describes CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT as instructing the client "to supply subject information in the certificate request", and CT_FLAG_PEND_ALL_REQUESTS as instructing the CA "to put all requests in a pending state".

Where templates live

• Definitions: template objects are stored forest-wide in CN=Certificate Templates,CN=Public Key Services,CN=Services,CN=Configuration,<forest root DN>.
• Publication: each enterprise CA has an object under CN=Enrollment Services in the same container; its certificateTemplates attribute lists the templates that CA will issue.
• Access: any authenticated user can read these objects, so discovery needs no PKI rights. Changes need Enterprise Admin or delegated PKI administration rights, which should be Tier 0.

Step-by-step

Steps 1 to 4 are read-only. Steps 5 and 6 change configuration but are reversible. Step 7 removes certificates already issued.

1. List published templates on every CA. On each issuing CA, or remotely with the AD CS administration module:

   Get-CATemplate
   certutil -CATemplates

   Get-CATemplate returns the templates set on the CA for issuance, with name and OID. Build one list across all enterprise CAs; a template published on any CA is live.
2. Export each template's settings. Read the template objects with the attributes from the table above:

   $cfg = (Get-ADRootDSE).configurationNamingContext
   Get-ADObject -SearchBase "CN=Certificate Templates,CN=Public Key Services,CN=Services,$cfg" `
     -LDAPFilter "(objectClass=pKICertificateTemplate)" `
     -Properties displayName, msPKI-Certificate-Name-Flag, msPKI-Enrollment-Flag, msPKI-RA-Signature,
                 pKIExtendedKeyUsage, msPKI-Certificate-Application-Policy, nTSecurityDescriptor

   certutil -v -template <TemplateName> prints the same values with flag names decoded, which is easier to read for individual templates. Keep this export: it is your baseline and your rollback record.
3. Evaluate each published template against the escalation conditions. Use the matrix in the next section. A template is an ESC1 finding when all of these hold: a low-privileged group can enrol; manager approval is off; no authorised signatures are required; the subject is supplied in the request; and the EKUs allow client authentication (or Any Purpose or no EKU). Record every condition, not just the verdict, because the fix depends on which condition you remove.
4. Review template and CA permissions. For each template list who holds Enroll, Autoenroll, Write, WriteDACL, WriteOwner, Full Control and ownership. Defender for Identity flags templates owned by, or writable by, built-in unprivileged groups. Also check the CA itself: Manage CA and Issue and Manage Certificates held by unprivileged groups is ESC7, and the CA EditFlags value EDITF_ATTRIBUTESUBJECTALTNAME2 (ESC6) makes subject alternative names requestable on every template:

   certutil -getreg policy\EditFlags

5. Unpublish templates nobody uses (reversible). Check the CA database for recent issuance from each template, confirm with the owner, then remove it from the CA. In the Certification Authority console, under Certificate Templates, choose Delete on the template, which removes it from that CA only, or use Remove-CATemplate -Name <TemplateName>. The template definition stays in the directory, so republishing with Add-CATemplate is the rollback.
6. Fix the templates you keep (reversible). Change the smallest thing that breaks the escalation path, in this order of preference:
   • Narrow enrolment: replace Domain Users or Authenticated Users with a specific security group of the users or computers that need the certificate.
   • Stop subject supply: switch Subject Name to Build from this Active Directory information. Templates for web server certificates often need supplied names; keep those without authentication EKUs, and enrol through a restricted group or approval.
   • Remove authentication EKUs: a TLS server template needs Server Authentication, not Client Authentication or Any Purpose.
   • Require approval: turn on CA certificate manager approval where supplied subjects and authentication must coexist.
   • Remove write rights: template owner and write permissions belong to PKI administrators only.
   • Enrolment agents: restrict Certificate Request Agent templates and configure enrolment agent restrictions on the CA.
   Template changes apply to new requests only; existing certificates are unaffected.
7. Review and revoke risky issued certificates. In the CA database, filter issued certificates by template and look for subjects or subject alternative names that differ from the requester, especially privileged accounts. Revoke suspicious certificates and publish a new CRL. Where abuse is suspected, follow the Active Directory Domain Compromise Response Playbook: revocation alone does not remove persistence an attacker created with the certificate.

Escalation conditions to check

The ESC names come from the SpecterOps "Certified Pre-Owned" whitepaper (Schroeder and Christensen, 2021), which also defines defensive guidance such as auditing published templates and hardening template settings. Microsoft's Defender for Identity uses the same names for its assessments, and its ESC15 description ties the finding to CVE-2024-49019 on unpatched servers.

Verify it worked

• Configuration: re-export the templates and confirm that no published template meets any row of the matrix.
• Function: the template's legitimate users can still enrol, and autoenrolment completes on a pilot machine (certutil -pulse triggers autoenrolment on a client).
• Posture tools: the corresponding Defender for Identity assessments no longer list the template; scores refresh every 24 hours.
• Negative test: in a test environment, a standard user requesting a certificate with a different subject is refused or held pending approval.

Rollback and common errors

Always duplicate a production template before major edits. Editing a template in place affects every CA that publishes it.

Small and large estates

Single CA, few templates: a manual review of each published template in the Certificate Templates console with certutil -v -template output takes an afternoon and is enough. Several CAs, hundreds of templates, multiple forests: script the export in step 2, compare it with the previous month's baseline, and treat any new template or permission change as a change request. Assign each published template an owner and a purpose in a register; the Certificate Inventory Register Template can hold this. Open-source auditing tools can speed up evaluation, but confirm their findings against the attributes above before changing anything.

Where identity fits

A certificate from an authentication-capable template is a credential, and when it is issued to a computer, service or automation it is a non-human identity credential that often outlives the password of the account it represents. Treat certificate templates as entitlements: each one defines who can mint which credential. Strong certificate mapping on domain controllers is what ties a certificate to the right account; the Kerberos PKINIT and Certificate Mapping Guide covers it.

Detection and measurement

Metrics:

• Published templates meeting any ESC condition: target zero.
• Published templates without a named owner: target zero.
• Published templates with no issuance in 12 months: falling; unpublish them.
• Templates enrollable by Domain Users, Domain Computers or Authenticated Users: a short, justified list.
• Time from template change to review: within one working day.

Framework mapping

Common failure patterns

• Auditing all templates instead of published ones: effort goes into unused definitions while a live template with Domain Users enrolment is missed. Start from Get-CATemplate on every CA.
• Copying the Web Server template and adding Client Authentication: combined with Supply in the request and broad enrolment, this creates ESC1.
• Fixing templates but not the CA flag: EDITF_ATTRIBUTESUBJECTALTNAME2 on the CA re-opens subject supply on every template.
• Not reviewing certificates already issued: a fixed template does not invalidate certificates an attacker obtained before the fix.
• Leaving template ownership with the person who created it: that account, or anyone who compromises it, can quietly reconfigure the template later.
• Skipping the patch: ESC15 depends on unpatched AD CS servers; template fixes alone leave the CA exposed to future template mistakes.

Practitioner checklist

• List published templates on every enterprise CA.
• Export name flags, enrolment flags, RA signatures, EKUs and ACLs for each published template and keep the baseline.
• Evaluate every published template against ESC1, ESC2, ESC3, ESC4 and ESC15 conditions.
• Check CA EditFlags and CA permissions for ESC6 and ESC7.
• Unpublish unused templates after owner confirmation.
• Narrow enrolment, stop subject supply or remove authentication EKUs on the templates you keep.
• Restrict template ownership and write rights to PKI administrators.
• Review and revoke suspicious certificates already issued from vulnerable templates.
• Enable Certification Services auditing and alert on template and CA permission changes.

Standards and references

• Microsoft: [MS-CRTD] msPKI-Certificate-Name-Flag Attribute
• Microsoft: [MS-CRTD] msPKI-Enrollment-Flag Attribute
• Microsoft: Defender for Identity security posture assessments for AD CS
• Microsoft: Get-CATemplate
• Microsoft: Audit Certification Services
• SpecterOps: Certified Pre-Owned, Abusing Active Directory Certificate Services
• NIST: SP 800-53 Rev. 5
• MITRE ATT&CK: Steal or Forge Authentication Certificates

Related NHI Mgmt Group resources: AD CS Security Guide · Kerberos PKINIT and Certificate Mapping Guide · PKI and Certificate Lifecycle Maturity Model · BloodHound and Active Directory Attack Path Guide · How to Find unconstrained delegation in active directory