Active Directory Certificate Services (AD CS): Auditing Templates Before They Become Domain Admin

1. Introduction

Active Directory Certificate Services (AD CS) is Microsoft’s enterprise PKI. It issues the certificates used for smart-card logon, TLS, code signing, VPN and more. Since 2021, AD CS has been recognised as one of the most impactful attack surfaces in Active Directory: a single misconfigured certificate template can let a low-privileged user obtain a certificate that authenticates as a domain administrator. Because certificate-based authentication is trusted deeply by the domain and because certificates can remain valid for years, an AD CS foothold is both powerful and persistent. Defenders must treat the CA as tier-0 infrastructure.

2. How It Works

An Enterprise CA is integrated with AD and publishes certificate templates — blueprints that define who may enroll, what the certificate can be used for, and how the subject is determined. A client requests a certificate for a template it is permitted to enroll in; the CA validates the request against the template and issues a signed certificate.

Requester ---(enroll for template)---> Enterprise CA
   ^                                       |
   |                                       | checks template ACL + policy
   |----------(issued certificate)---------|

Certificate can then be used to authenticate to AD (PKINIT / smart-card logon)
if it has an appropriate EKU (e.g. Client Authentication, Smart Card Logon).

Key concepts:

• EKU (Extended Key Usage): what the certificate is valid for. Client Authentication, Smart Card Logon, or Any Purpose allow domain authentication.
• Subject supply: whether the requester may specify the subject / SAN (subject alternative name). If the requester can set the SAN to another user, they can request a cert that authenticates as that user.
• Enrollment rights: the template ACL controlling who can request it, and whether manager approval is required.

3. The Security Problem

The dangerous combination is: an authentication-capable EKU, the requester allowed to supply an arbitrary SAN, and enroll permission granted to a broad group — with no manager approval. A user meeting those conditions can request a certificate as any account, including a domain admin, then use it to log on. Other weaknesses include over-broad enrollment ACLs, dangerous control over template or CA objects, vulnerable CA web-enrollment endpoints susceptible to relay, and certificates that persist even after a password reset (a stealthy persistence mechanism). These are the family of issues catalogued as ESC1–ESC-N; here we treat them at the configuration/defence level.

4. How Attackers Abuse It

Concept: An attacker enumerates published templates, identifies one that both permits low-privileged enrollment and allows an attacker-supplied SAN with a logon-capable EKU, and requests a certificate naming a privileged user. Because the domain trusts the certificate for PKINIT, the attacker can then authenticate as that user. Separately, coercion + relay to the CA’s HTTP enrollment endpoint can yield a certificate for a coerced machine account.

In an authorized assessment, this is validated in a lab against a deliberately misconfigured template; the report lists each vulnerable template, the exact permission at fault, and the remediation — it does not target production identities.

5. How to Detect / Inventory It

Command

certutil -TCAInfo

What it does: Lists the enterprise CAs registered in the forest and their status.

What to look for: Unexpected or forgotten CAs — every trusted CA expands the attack surface and must be inventoried and governed.

Defensive use: Establishes the authoritative list of CAs to audit.

Command

Get-ADObject -SearchBase ("CN=Certificate Templates,CN=Public Key Services,CN=Services," + (Get-ADRootDSE).configurationNamingContext) -Filter * -Properties displayName, msPKI-Certificate-Name-Flag, pKIExtendedKeyUsage, msPKI-Enrollment-Flag | Select-Object displayName, msPKI-Certificate-Name-Flag, pKIExtendedKeyUsage, msPKI-Enrollment-Flag

What it does: Enumerates every certificate template and the flags that matter for abuse: the name flag (whether the requester supplies the subject/SAN), the EKUs, and the enrollment flags (e.g. manager approval).

What to look for: A template where msPKI-Certificate-Name-Flag includes the “supply in request” bit (value 1 / 0x1) and the EKU list includes Client Authentication / Smart Card Logon / Any Purpose and the enrollment flag does not require manager approval. That is the classic escalation template.

Defensive use: Produces the precise list of templates to remediate, ranked by which flags are set.

Command

certutil -v -template > templates.txt

What it does: Dumps full template definitions including permissions and flags to a file for offline review.

What to look for: Templates granting enroll (and especially enroll + autoenroll) to broad principals such as Domain Users or Authenticated Users when the template is authentication-capable.

Defensive use: A thorough, scriptable audit artifact you can diff over time to catch drift.

Command

Get-CATemplate

What it does: On a CA, lists the templates currently published (available for enrollment).

What to look for: Unnecessary or legacy templates still published; unpublishing a risky template immediately removes its enrollment path.

Defensive use: Lets you shrink the attack surface by unpublishing templates that are not needed.

6. How to Audit the Environment

• Inventory all CAs and all published templates.
• For each authentication-capable template, confirm the requester cannot supply the SAN unless strictly required and manager-approved.
• Review enrollment ACLs — no broad group should be able to enroll in a privileged/authentication template.
• Check who has write/owner rights on template objects and on the CA object itself.
• Confirm the CA denies EKU/SAN manipulation and that the “EDITF_ATTRIBUTESUBJECTALTNAME2” CA flag is not set (it lets requesters add arbitrary SANs to any template).
• Verify web enrollment / NDES endpoints are protected against relay (HTTPS, Extended Protection for Authentication).

Command

certutil -getreg policy\EditFlags

What it does: Reads the CA policy EditFlags, which reveal whether the CA allows requesters to specify the SAN globally.

What to look for: The EDITF_ATTRIBUTESUBJECTALTNAME2 flag being present — a forest-wide escalation enabler that should be removed.

Defensive use: Confirms one of the most dangerous CA-level misconfigurations is absent.

7. How to Fix / Harden It

• Remove the “supply in request” SAN option from authentication templates; derive the subject from AD instead.
• Require manager approval for sensitive templates.
• Tighten enrollment ACLs to specific, small groups.
• Remove EDITF_ATTRIBUTESUBJECTALTNAME2 from the CA if present.
• Unpublish unused templates; retire legacy/duplicate CAs.
• Enable strong certificate mapping and enforce it (per Microsoft’s certificate-based authentication hardening) so weak implicit mappings cannot be abused.
• Protect web enrollment/NDES with HTTPS and Extended Protection for Authentication.

8. Detection & Monitoring

• Enable CA auditing and monitor the CA Security log: Event ID 4886 (certificate request received) and 4887 (certificate issued) — correlate issued certs with the requester and the SAN.
• Alert on certificates issued where the SAN identity differs from the requesting account — a strong abuse indicator.
• Watch for enrollment in sensitive templates by unexpected principals.
• Monitor for PKINIT logons (Kerberos 4768 with certificate info) by accounts that do not normally use smart cards.

9. MITRE ATT&CK Mapping

Technique	ID
Steal or Forge Authentication Certificates	T1649
Valid Accounts: Domain Accounts	T1078.002
Account Manipulation	T1098
Exploitation for Privilege Escalation	T1068

10. Practical Lab

In an isolated lab:

1. Stand up an Enterprise CA and duplicate a User template.
2. Deliberately set it to allow “supply subject in request”, add Client Authentication EKU, and grant enroll to Domain Users — then run the template-enumeration commands above and confirm your audit script flags it.
3. Remediate the template (remove SAN supply, require approval, tighten ACL) and re-run the audit to confirm it is no longer flagged.
4. Enable CA auditing and observe Events 4886/4887 for a benign issuance.
5. Verify certutil -getreg policy\EditFlags does not contain the dangerous SAN flag.

11. Key Takeaways

• One template that combines requester-supplied SAN + auth EKU + broad enrollment can equal domain compromise.
• Inventory every CA and template; audit the name flag, EKUs, enrollment flags and ACLs.
• Remove EDITF_ATTRIBUTESUBJECTALTNAME2 and require manager approval on sensitive templates.
• Monitor CA Events 4886/4887 and alert when the certificate SAN does not match the requester.
• Treat the CA as tier-0; certificates persist through password resets, making cleanup harder than it looks.

Continue learning: Active Directory security

This guide is part of our Active Directory Security series. Related guides:

• SMB Signing and NTLM Relay: Closing the Quiet Path to Lateral Movement
• LDAP and LDAP Signing in Active Directory: Channel Binding, Relay, and Hardening
• NTLM Authentication: Pass-the-Hash, Relay, and Why Enterprises Are Retiring It