AD CS ESC1: The Most Common Misconfiguration That Hands Attackers Domain Admin

Active Directory Certificate Services is one of those roles that gets deployed once and then never touched again. That's the problem. A misconfigured certificate template—specifically the ESC1 flaw—gives any unprivileged domain user the ability to request a certificate in the name of any identity in the domain, including Domain Admins. No local admin rights needed: enrollment permission on the template is enough. No exotic tooling required. No zero-day. Just a setting nobody bothered to audit.

This post is for MSP technicians and IT administrators running hybrid environments with AD CS deployed. If you run the Certificate Connector for Microsoft Intune (formerly the NDES connector) for Intune, pay close attention—the templates associated with it are a common source of exactly this misconfiguration.

What ESC1 Actually Means

Certificate templates in AD CS can be configured to allow the subject name to be supplied in the request rather than built from Active Directory. This is legitimate for certain use cases—web server certificates, for example, where the CN needs to match a specific FQDN. The problem is when three things line up: Supply in the request is on, enrollment rights are overly permissive, and the template carries an EKU that permits authentication (Client Authentication, Smartcard logon, PKINIT client authentication or Any purpose) with no mitigation such as Manager approval or a required authorized signature in place.

That third condition matters when you audit. A template with Supply in the request and nothing but Server Authentication in its EKUs—the NDES web server template is exactly that—is not an ESC1 finding. Skip the EKU check and your audit will be full of false positives.

If "Domain Users" or "Domain Computers" appears in the enrollment rights of an authentication-capable template that allows subject name supply in the request, any user in the domain can request a certificate claiming to be anyone else. Including a Domain Admin. That certificate can then be used for Kerberos authentication via PKINIT, which returns a Ticket Granting Ticket—effectively a complete credential for the target account.

The attacker doesn't need to crack a password. They just need to know a username.

How to Find Vulnerable Templates in Your Environment

There is a supported way to do this that most people don't know about. Defender for Identity ships a built-in ESC1 security posture assessment. With a sensor deployed on the AD CS server, open Microsoft Secure Score, go to Recommended actions, and look for Prevent users to request a certificate valid for arbitrary users based on the certificate template (ESC1). The Exposed entities pane lists every affected template in the environment. Microsoft documents the same assessment series for ESC2, ESC3, ESC4, ESC6, ESC7, ESC8, ESC11 and ESC15—so once the sensor is there, you get the whole family, not just ESC1.

Without that sensor, do it by hand in the Certificate Templates console (certtmpl.msc) on the issuing CA. For every template, check three tabs:

• Subject Name — is Supply in the request selected?
• Extensions > Application Policies — does it contain Client Authentication, Smart Card Logon, KDC Authentication / PKINIT, or Any Purpose? A template with only Server Authentication is not an ESC1 candidate.
• Security — do Domain Users, Domain Computers, Authenticated Users or Everyone hold Enroll?

All three together, with no Manager approval or authorized-signature requirement on the Issuance Requirements tab, is an ESC1 finding. Then cross-reference against which templates are actually published to a CA: a template that isn't published can't be requested and therefore can't be exploited—but clean it up anyway, because republishing is one click.

For the Intune certificate templates, get the distinction right, because the blanket advice "scope it to the NDES computer account, nothing else" will break your SCEP issuance. On the server authentication template used by IIS on the NDES box, the computer account of the NDES server needs Read and Enroll—that one really is just the machine. On the SCEP template itself, Microsoft requires more principals: the NDES application pool account (the NDES service account) with Read and Enroll, the Certificate Connector service account with Read and Enroll, and Read for the Intune admins who author SCEP profiles. Nobody else. Seeing Domain Users or Domain Computers on either template is your first fix.

What to Fix

Microsoft lists five remediations for ESC1, and any one of them closes the hole. In order of impact:

1. Remove Domain Users and Domain Computers from enrollment rights on any authentication-capable template with Supply in the request enabled. This is the critical remediation. If a template genuinely needs to allow subject name supply (e.g., a web server template), restrict who can enroll. The set of accounts that legitimately need that capability is always small.

2. Turn off Supply in the request entirely wherever the use case allows it—or, if the certificate is not meant to authenticate anything, remove the authentication EKUs (Client Authentication, Smartcard logon, PKINIT client authentication, Any purpose). Either one alone takes the template out of scope.

3. Turn on the CA's Manager approval requirement as a compensating control on templates that have to stay as they are. It costs you a manual approval step per request, which is exactly the point.

4. Review which templates are published to your CAs. Open the Certification Authority console, navigate to Certificate Templates, and remove any template that has no active, justified use case. Unpublish first, delete after you've confirmed nothing breaks.

5. Check whether the EDITF_ATTRIBUTESUBJECTALTNAME2 flag is set—and turn it off if it is. If this flag is set on the CA itself, it overrides template settings and allows SAN attributes to be supplied in any request. Check with:

certutil -getreg policy\EditFlags

If EDITF_ATTRIBUTESUBJECTALTNAME2 appears in the output, that's a separate, CA-level ESC6 issue and needs immediate attention. Turn it off and restart the service:

certutil -setreg policy\EditFlags -EDITF_ATTRIBUTESUBJECTALTNAME2
net stop certsvc & net start certsvc

Test that in a controlled environment first—something else in your PKI may be relying on it.

The Broader Context

ESC1 is documented in the Certified Pre-Owned research by SpecterOps, and Microsoft documents the whole ESC1–ESC15 series itself in the Defender for Identity security posture assessments. The tooling to exploit it—Certipy, among others—is publicly available and not complicated to use. Any attacker who has landed on a single endpoint will run this check as a standard step. If the template is there, they will use it.

The AD CS role is frequently treated as infrastructure that "just works." It does—until it doesn't. Adding a quarterly AD CS audit to your client review process takes, in my experience, about 20 minutes per tenant and surfaces misconfigurations before attackers do. Combine this with a broader Zero Trust posture to minimize the blast radius of any single compromised identity.

Key Takeaway

A misconfigured AD CS template is not a theoretical risk. In a documented incident we analyzed recently, it was the direct path from a compromised standard user to full Domain Admin in 180 minutes. The fix is not complicated—but it requires someone to actually look.

Action Items

• Run the ESC1 audit on every client tenant with AD CS deployed — Secure Score if a Defender for Identity sensor is on the AD CS server, certtmpl.msc by hand if not
• Remove Domain Users/Domain Computers from enrollment rights on authentication-capable Supply in the request templates
• Scope the NDES server authentication template to the NDES computer account; scope the SCEP template to the NDES application pool account, the Certificate Connector service account, and Read for Intune admins
• Publish only templates with active, documented use cases
• Check for EDITF_ATTRIBUTESUBJECTALTNAME2 at the CA level