Active Directory Certificate Services (AD CS) Security Guide

Active Directory Certificate Services (AD CS) quietly issues credentials that can log on as any user or computer in the forest, and a single misconfigured certificate template can turn an ordinary domain account into a Domain Admin. Many enterprise CAs were installed years ago for Wi-Fi, VPN or smart cards and their templates never reviewed. Since 2021, public research has catalogued the misconfiguration classes (ESC1, ESC8, ESC15 and others) that make AD CS one of the shortest routes to tier zero, and Microsoft has changed how domain controllers map certificates to accounts. This guide is for directory, PKI and detection engineers who need to find and fix those weaknesses, harden the CA itself, complete the move to strong certificate mapping and detect abuse. For the wider directory programme see the Active Directory and Entra ID Hardening Guide.

Key takeaways

• A certificate is a credential. A client authentication certificate from a CA in the NTAuth store can obtain Kerberos tickets as the identity it names, and survives password resets.
• Templates are the attack surface. A template that lets the requester supply the subject, carries an authentication EKU and is enrollable by Domain Users is ESC1, one of the most direct paths to Domain Admin.
• The CA is tier zero. Whoever holds an enterprise CA's private key can forge a "golden certificate" for any account, so the CA server, its key and its administrators deserve domain controller level protection.
• Strong mapping is now enforced. KB5014754 moved domain controllers to Full Enforcement in February 2025, and the registry key that allowed a fallback stopped being supported with the September 2025 updates. Certificates without a strong mapping now fail.
• Turn on CA auditing first. Events 4886, 4887, 4899 and 4900 only appear when the CA audit filter is set, and without them there is no record of who requested what.

How AD CS becomes an authentication authority

Microsoft describes AD CS as "a Windows Server role for issuing and managing public key infrastructure (PKI) certificates used in secure communication and authentication protocols." Three design facts make it an identity system.

• Templates live in the directory: only an enterprise CA can issue from certificate templates, and the templates are stored in Active Directory Domain Services "for use by every CA in the forest."
• The NTAuth store decides trust for logon: the object CN=NTAuthCertificates,CN=Public Key Services,CN=Services,CN=Configuration holds CA certificates in its cACertificate attribute. Publishing a CA there means, in Microsoft's words, that "issued certificates from these CA's can be used for authentication." Domain-joined enterprise CAs publish themselves automatically.
• Kerberos accepts certificates: a certificate with a client authentication or smart card logon purpose can be used for PKINIT to obtain a ticket-granting ticket for whichever account the domain controller maps it to.

For certificate inventory, renewal and lifecycle tooling beyond AD CS see the Machine Identity, PKI and Certificate Lifecycle Guide.

The ESC misconfiguration classes

The 2021 research paper "Certified Pre-Owned" gave AD CS weaknesses a shared vocabulary: ESC (domain escalation) classes, THEFT classes for stealing existing certificates, and PERSIST classes for keeping access. Later research extended the numbering, and Microsoft Defender for Identity now ships posture assessments named after the ESC classes, so the labels are safe to use in change tickets. Each class below is a condition to find and fix.

ESC1: enrollee supplies subject

Subject alternative name abuse is the core of ESC1. When a template has the Enrollee Supplies Subject flag set, the CA copies the name the requester asks for into the certificate instead of building it from the requester's directory object. If the template also carries an authentication EKU and Domain Users or Authenticated Users can enrol, any account can obtain a certificate naming a Domain Admin, and the domain controller will issue that admin a ticket. Microsoft's assessment warns that this allows impersonation of any account, including domain admins. Legitimate uses exist, typically web server templates where the subject cannot come from AD: keep them, but without authentication EKUs, with enrolment limited to named server owners and with manager approval.

ESC8: AD CS Web Enrollment and NTLM relay

AD CS Web Enrollment and the Certificate Enrollment Web Service authenticate over HTTP. If they accept NTLM without channel binding, an attacker who coerces a privileged machine, such as a domain controller, into authenticating can relay that authentication and obtain a certificate for it. Microsoft's KB5005413 lists the mitigations: enable Extended Protection for Authentication with "Required", enable Require SSL so only HTTPS is accepted, set extendedProtectionPolicy to Always for the enrolment web service, and optionally restrict incoming NTLM on AD CS servers. If nobody uses the web interfaces, remove the role service.

ESC15: version 1 templates and application policies

Version 1 templates are installed by default and Microsoft notes that "the only property that can be modified on a version 1 template is the set of assigned permissions." ESC15 affected version 1 templates that let the requester supply the subject: on an unpatched CA a requester could also add arbitrary application policies, so a certificate from a template meant for servers could carry client authentication. Microsoft fixed this as CVE-2024-49019 (published 12 November 2024, CVSS 7.8). Patch every CA, then duplicate any still-needed version 1 template into a version 2 or later template you can configure, unpublish the original, and remove enrolment rights for unprivileged groups.

Theft, persistence and the golden certificate

MITRE ATT&CK covers this activity as T1649 Steal or Forge Authentication Certificates.

• AD CS certificate theft: user and machine certificates with exportable private keys can be copied from certificate stores, files and backups. Prefer non-exportable keys for authentication templates, use TPM key attestation where supported (the CA verifies the key is protected by a trusted TPM), and keep certificate files and PFX backups out of shares and repositories.
• AD CS account persistence: a certificate enrolled for a compromised account stays valid until it expires or is revoked. Resetting the password does nothing to it. Incident response for any account compromise must include listing certificates issued to that account in the CA database and revoking them.
• AD CS domain persistence: an attacker with enough rights can add a rogue CA certificate to NTAuth, loosen a template, or grant themselves CA officer rights to approve their own requests later.
• Golden certificate: with a stolen enterprise CA private key, an attacker can sign certificates offline for any identity. Forged certificates never pass through the CA, so they are absent from the CA database and from event 4887. ATT&CK lists forged certificates as a persistence route. The realistic remedy is to retire the compromised CA certificate, remove it from NTAuth and the trusted root stores, and re-issue from a new key. Prevention depends on key protection.

Microsoft's PKI guidance recommends a hardware security module for all production CAs and warns that "marking a software-based key as 'not exportable' is not considered a security feature." By default a software CA key can be exported by anyone with local administrator rights on the CA. The Mimecast certificate compromise showed in a different setting how a stolen authentication certificate grants access that outlives every password change.

Strong certificate mapping and KB5014754

KB5014754 closed CVE-2022-26923, CVE-2022-26931 and CVE-2022-34691, which let certificates be mapped to the wrong account through name spoofing (for example, machine names without the trailing dollar sign and UPN or sAMAccountName collisions). From the May 2022 updates, enterprise CAs add a non-critical SID security extension (OID 1.3.6.1.4.1.311.25.2) to certificates issued from online templates, and domain controllers check it.

• Strong mappings: the SID extension, or an explicit altSecurityIdentities value of type X509IssuerSerialNumber (Microsoft's recommendation), X509SKI or X509SHA1PublicKey.
• Weak mappings: X509IssuerSubject, X509SubjectOnly and X509RFC822. Microsoft states that "all mapping types based on usernames and email addresses are considered weak."
• Events to watch: in the System log, source Kdcsvc, event 39 means a certificate could not be mapped in a strong way, 40 means the certificate predated the account (Compatibility mode only) and 41 means the SID in the certificate does not match the mapped account. Event 41 deserves an alert in its own right.
• Third-party CAs: the SID extension is added only by Microsoft enterprise CAs. Certificates from other CAs used for smart card or device logon need explicit strong mappings. See the Smart Card and PIV/CAC Authentication Guide.
• Template opt-out: bit 0x00080000 in msPKI-Enrollment-Flag stops the CA adding the SID extension; treat it as a finding unless documented.

Hardening the enterprise CA and its templates

Enterprise CA hardening

• Tier zero placement: administer CAs only from privileged access workstations with tier zero accounts, restrict local administrators, and keep backup operators for CA servers in the same tier.
• Key protection: keep the root CA offline, protect issuing CA keys in an HSM, and require more than one person for HSM key operations. Microsoft's guidance is that "no single person can access a quorum of objects."
• Role separation: separate CA Administrator (Manage CA) from Certificate Manager (Manage Certificates) and remove both rights from any built-in or broad group (ESC7).
• NTAuth hygiene: NTAuth should contain only CAs you intend to trust for logon. Review its cACertificate values on a schedule and alert on changes.

Certificate template enforcement

• Unpublish what you do not use: it is reversible and the quickest risk reduction.
• Name from Active Directory: prefer "Build from this Active Directory information" over Supply in the request for any template with an authentication EKU.
• Issuance requirements: where requesters must supply names, require CA certificate manager approval or an authorised signature so a human or enrolment agent checks the request.
• Enrolment rights: grant Enroll and Autoenroll to named groups, not Domain Users, Domain Computers or Authenticated Users, unless the template genuinely serves every account and builds the subject from AD.
• Template ownership and ACLs: owners and write permissions belong to the PKI team's admin group only (ESC4).

Decoy certificate template

A decoy certificate template is a deception control: a published template with an attractive name and an apparently risky configuration that no legitimate process uses. Configure it so it cannot actually issue (for example, require CA certificate manager approval so requests stay pending) and alert on any request against it: no legitimate user has a reason to try, so an attempt is a strong reconnaissance signal. See the Deception Technology Guide.

Implementing the clean-up

1. Turn on visibility. Enable the Audit Certification Services subcategory on CA servers and set the CA audit filter to cover issue and manage requests and changes to CA security settings and configuration. Forward events centrally first.
2. Inventory. List every CA and published template with its EKUs, subject name source, schema version, enrolment ACL, owner and issuance requirements, plus NTAuth contents and web enrolment services. Defender for Identity's ESC6, ESC7, ESC8, ESC11 and ESC15 assessments need a sensor on the AD CS server.
3. Measure real use. From the CA database and 4887 events, find which templates issued certificates in the last 12 months; unused ones are candidates to unpublish.
4. Fix the critical classes first. ESC1, ESC4, ESC6, ESC7 and ESC8 give the fastest paths to Domain Admin. Patch every CA for CVE-2024-49019 in the same window.
5. Change safely. Duplicate a template, tighten the copy, pilot it with one application owner, then supersede the old template, keeping it unpublished until the pilot ring renews successfully.
6. Close strong mapping gaps. Review Kdcsvc events 39 and 40 history, re-issue certificates that lack the SID extension, and add X509IssuerSerialNumber mappings for third-party CA certificates.
7. Harden the CA with role separation now and HSM-backed keys at the next renewal.
8. Roll back by republishing the original template or reverting CA flags. There is no longer a registry rollback for strong mapping enforcement.

Choosing between options

Small organisations with one CA can unpublish unused templates, fix ESC1 and ESC8 and enable auditing in a day. Large organisations with several forests need a template owner register, change control for template edits and periodic NTAuth and CA ACL reviews under tier zero governance.

Detection and measurement

CA security events depend on the CA audit filter. Microsoft's PKI monitoring appendix lists these as the most useful:

Two correlations catch what single events miss: certificate logons by privileged accounts that rarely use certificates, and PKINIT logons whose certificate serial is in no CA database (a forged certificate). See the ITDR Guide for wider identity detection.

• Templates with ESC conditions: count of published templates meeting any ESC1 to ESC15 condition; target zero.
• Published but unused templates: templates with no issuance in 12 months; trend down.
• Broad enrolment: percentage of templates with authentication EKUs enrollable by Domain Users, Domain Computers or Authenticated Users.
• Mapping health: Kdcsvc 39 and 41 events per week; target zero after remediation.
• Audit coverage: CAs forwarding 4886 to 4900 events; target all.

Common failure patterns

• Default templates never reviewed: version 1 templates such as Web Server and User stay published with broad rights for a decade.
• Password reset treated as containment: responders reset a compromised admin's password but never revoke its certificates.
• CA run as an ordinary server: managed from standard admin accounts and backed up to general storage with an exportable key.
• Auditing off by default: nobody set the CA audit filter, so the investigation has no record of which certificates were issued.
• Strong mapping postponed: teams kept Compatibility mode until the registry key stopped being honoured, then discovered third-party smart card certificates without strong mappings during an outage.

Framework mapping

The Five Eyes guidance "Detecting and Mitigating Active Directory Compromises", led by ASD's ACSC with CISA, NSA and partners, covers 17 common Active Directory compromise techniques and is a useful companion for tier zero programmes.

Practitioner checklist

• Enable the CA audit filter and Audit Certification Services on every CA, and forward events 4882 to 4900 centrally.
• Flag every published template meeting an ESC condition; fix or unpublish it.
• Patch all CAs for CVE-2024-49019 and replace needed version 1 templates with configurable copies.
• Confirm EDITF_ATTRIBUTESUBJECTALTNAME2 is off and IF_ENFORCEENCRYPTICERTREQUEST is on.
• Remove AD CS Web Enrollment or enforce HTTPS and EPA Required per KB5005413.
• Treat CA administrators as tier zero and remove CA officer rights from broad groups.
• Review NTAuth contents and alert on any change to the NTAuthCertificates object.
• Clear Kdcsvc 39 and 41 events and strongly map third-party CA certificates.
• Add certificate revocation for the affected account to every account-compromise runbook.
• Plan HSM-backed keys and an offline root for the next CA renewal.

Standards and references

• Microsoft: KB5014754 Certificate-based authentication changes on Windows domain controllers
• Microsoft: KB5005413 Mitigating NTLM Relay Attacks on Active Directory Certificate Services
• Microsoft Learn: Defender for Identity certificates security posture assessments
• Microsoft Learn: Certificate template concepts in Windows Server
• Microsoft Learn: Securing PKI, Appendix A Events to Monitor
• Microsoft Learn: Import third-party CA certificates into the Enterprise NTAuth store
• MITRE ATT&CK: T1649 Steal or Forge Authentication Certificates
• CISA: Detecting and Mitigating Active Directory Compromises

Related NHI Mgmt Group resources: Active Directory and Entra ID Hardening Guide · Machine Identity, PKI and Certificate Lifecycle Guide · Kerberos Security Guide · ITDR Guide