Hardening Active Directory Certificate Services

The short version

Active Directory Certificate Services is the most common private certificate authority in the enterprise, and its default and convenience settings are a frequent weak point in an otherwise well-run domain. A certificate issued by AD CS can act as a logon credential, so a template or CA that issues the wrong certificate to the wrong person has consequences well beyond the certificate itself.

In 2021, researchers at SpecterOps published a taxonomy of eight AD CS misconfigurations, named ESC1 through ESC8, that are now standard checks in any PKI assessment. None of them is a software vulnerability. Patching does not address them. Every one is a configuration choice you own and can change, and this guide is about the changes.

If you operate AD CS and have never audited it against this list, treat that as the finding. The rest of this guide is the remediation.

Audit before you change anything

You cannot harden what you have not measured, and you should not change a production template blind. Start with a read-only assessment.

• Microsoft’s own tooling. The certutil command, the Certification Authority and Certificate Templates consoles, and PowerShell’s PKI module expose every setting discussed below. A domain user can read most template and CA configuration from the AD CS objects published in the configuration partition.
• Purpose-built auditors. Open-source defensive tools read the same configuration and flag the known weaknesses for you. PSPKIAudit and Locksmith are PowerShell toolkits written for exactly this review, and Locksmith can propose remediations. Run them from an account with normal privileges first, so you see what an ordinary user sees.
• Record a baseline. Export every certificate template, its enrollment permissions, and each CA’s configuration before you touch anything. You will want the before-and-after, and a rollback.

Produce one inventory: every published template, who can enroll in it, what it can be used for, whether it requires manager approval, and whether it lets the requester influence the subject. That table is where the findings live.

The eight weaknesses and their fixes

The names are worth keeping, because every assessor and tool uses them. Each entry below is the dangerous condition and the setting that removes it.

ESC1 — templates that let the requester name the subject

The condition. A template permits client authentication, allows low-privileged users to enroll, does not require manager approval, and lets the requester supply the subject name in the request. The combination means the person asking for the certificate also decides whose certificate it is.

The fix. On any template that can be used for authentication, do not allow the subject to be supplied in the request; build the subject from Active Directory instead. If a template genuinely needs a requester-supplied subject, require manager approval and restrict enrollment to a trusted, auditable group. Review the “supply in the request” setting on every template, not just the ones you think are sensitive.

ESC2 — templates usable for any purpose

The condition. A template grants the Any Purpose extended key usage, or no EKU at all, which produces a certificate that can be used for client authentication among everything else. Broad enrollment on such a template is broad authentication.

The fix. Give every template the narrowest extended key usage that its job requires. A template for encrypting files does not need client authentication. Remove Any Purpose. Where a subordinate CA certificate is involved, constrain it.

ESC3 — enrollment agent templates

The condition. The Certificate Request Agent capability lets one account request certificates on behalf of others, which is how smart card enrollment stations work. Left unrestricted, it becomes a way to obtain a certificate for another identity.

The fix. Restrict who can enroll in enrollment agent templates to the specific staff who run enrollment. On the CA, configure enrollment agent restrictions so an agent can request only for defined groups and only on defined templates. Require manager approval where the workflow allows it.

ESC4 — templates ordinary users can edit

The condition. The access control on a certificate template grants write, full control, or equivalent to a broad group such as authenticated or domain users. Whoever can edit a template can turn a safe template into an ESC1 template at will.

The fix. Set template permissions so that only PKI administrators can write to or own a template. Authenticated users should have read and, where appropriate, enroll, never write. Audit every template’s ACL, including ones no longer in use.

ESC5 — weak permissions on the PKI objects

The condition. The misconfiguration is one level up from the template: overly broad rights on the CA’s computer object, its AD containers under the configuration partition, or the objects that define trust. Control of those objects is control of the CA.

The fix. Treat the CA server as a Tier 0 asset, the same tier as a domain controller. Lock down the public key services containers in Active Directory, the CA computer object, and local administrative access to the CA host. Only PKI and domain administrators belong there.

ESC6 — the requester-supplied-subject CA flag

The condition. A CA-wide flag, EDITF_ATTRIBUTESUBJECTALTNAME2, lets any requester add an arbitrary subject alternative name to any certificate, regardless of what the template allows. It turns well-behaved templates into ESC1 templates across the whole CA.

The fix. Confirm the flag is off and keep it off. Check it explicitly, because it has historically been set by well-meaning administrators to solve an enrollment problem, and because it is easy to miss. After clearing it, restart the CA service and verify.

ESC7 — users who can administer the CA

The condition. A non-PKI account holds a CA management role, such as the ManageCA or ManageCertificates right. Those roles can change CA policy, enable dangerous flags, or approve pending requests.

The fix. Review the CA’s security settings and remove management roles from anyone outside the PKI administration team. The ManageCA right in particular should be tightly held, because it can be used to change the very settings this guide tells you to fix.

ESC8 — web enrollment open to credential relay

The condition. The AD CS web enrollment and certificate enrollment web service roles accept Windows-integrated authentication over a channel that can be relayed, which lets a coerced machine account’s authentication be forwarded to the enrollment endpoint.

The fix. If you do not use the web enrollment roles, remove them. If you do, require HTTPS, enable Extended Protection for Authentication on the enrollment endpoints, and disable NTLM to those endpoints in favor of Kerberos. Reducing machine-account coercion across the domain, by patching and by restricting the relevant RPC paths, closes the on-ramp.

Detection, not just prevention

Hardening reduces the ways misissuance can happen. Detection tells you if it already has.

• Enable CA auditing. AD CS can log certificate issuance, approvals, and configuration changes to the Windows event log. It is off or partial by default on many installations. Turn on auditing for issued certificates and for CA configuration changes, and forward those events to your SIEM.
• Watch the certificate-authentication events. Domain controllers log certificate-based logons. A certificate authentication for a privileged account, issued by a template that account has no business using, is the signal you are looking for. The relevant events include certificate issuance on the CA and certificate-mapping events on the domain controller.
• Alert on the dangerous changes. Any change to a template’s subject settings, any toggle of the EDITF flag, any new CA management role, and any new enrollment agent is worth an alert. These are rare in a stable environment, so the noise is low.
• Re-run the assessment on a schedule. Templates drift. A quarterly re-run of your chosen auditor catches the convenience change someone made to unblock a project.

The strong certificate mapping change

In 2022, Microsoft began closing a related weakness in how a certificate is matched to an account. Historically a domain controller could map a certificate to an account weakly, for example by a name in the certificate, which let a certificate for one identity be accepted for another. The update identified as KB5014754 introduced strong, unforgeable mapping based on an identifier the CA embeds at issuance, and a staged enforcement timeline.

What this does and does not do:

• It does make the mapping from certificate to account harder to abuse, which blunts several of the paths above even where a bad certificate was obtained.
• It does not fix the templates or CA settings. A template that issues the wrong certificate still issues it; strong mapping only governs how that certificate is matched to an account at logon.
• Enforcement is on. The compatibility period has passed, so domain controllers in full enforcement reject weakly mapped certificates. If you have older certificates or non-Microsoft issuers in the mix, confirm they carry the strong mapping, or you will see authentication failures rather than a silent fallback.

Treat strong mapping as the floor, not the ceiling. It is necessary, it is already enforced, and it does not substitute for fixing the templates.

A remediation sequence

Order matters, because some fixes are higher leverage and lower risk than others.

1. Audit with a read-only tool from an unprivileged account. Produce the template and CA inventory.
2. Clear the CA-wide problems first: the EDITF flag (ESC6) and CA management roles (ESC7). These are single changes with broad effect.
3. Fix template subject settings and enrollment permissions (ESC1, ESC2, ESC3) on authentication-capable templates, highest-privilege first.
4. Repair the access control on templates and PKI objects (ESC4, ESC5). Bring the CA host into Tier 0.
5. Address web enrollment (ESC8): remove it, or enforce HTTPS with Extended Protection and disable NTLM.
6. Confirm strong mapping is satisfied across all issuers, then verify enforcement is not breaking legitimate logons.
7. Turn on auditing and alerting, and schedule the re-assessment.

Each step is reversible from the baseline you exported, and most can be staged in a lab against copies of your real templates before they touch production.

Where we can help

An AD CS security assessment runs the read-only audit, delivers the prioritized findings against this list, and gives your team a sequenced remediation plan with the specific template and CA changes for your environment. Because the fixes touch authentication, we stage them so issuance keeps working while the risk comes down. If you are also planning the post-quantum or lifecycle changes, this is a natural time to review the whole PKI.

Talk to us about an AD CS assessment