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 user with local admin rights the ability to request a certificate in the name of any identity in the domain, including Domain Admins. No exotic tooling required. No zero-day. Just a default setting nobody bothered to audit.

This post is for MSP technicians and IT administrators running hybrid environments with AD CS deployed. If you have an NDES connector for Intune, pay close attention—the template associated with it is 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 this flag is combined with overly permissive enrollment rights.

If "Domain Users" or "Domain Computers" appears in the enrollment rights of a 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.

Stylized illustration of a public key infrastructure security shield over a circuit board, representing Active Directory Certificate Services
AD CS issues the certificates that underpin domain authentication—which is exactly why a single misconfigured template is such a high-value target.

How to Find Vulnerable Templates in Your Environment

Install the PSPKI PowerShell module if you don't have it:

Install-Module -Name PSPKI -Force

Then run:

Get-CertificationAuthority | Get-CATemplate | Get-CertificateTemplate |
  Where-Object { $_.Settings.SubjectName -match "SupplyInRequest" } |
  Select-Object Name, @{N="EnrollmentRights";E={ $_.Settings.Permission.Permissions }}

Any template where SupplyInRequest is set and the enrollment rights include Domain Users, Domain Computers, or Authenticated Users is a candidate for ESC1. Cross-reference against which of those templates are actually published to a CA—unpublished templates are lower risk, but should still be cleaned up.

For the NDES/Intune connector template specifically: enrollment rights should be scoped to the computer account of the NDES connector server only. Nothing else. If you see Domain Users or Domain Computers in there, that's your first fix.

What to Fix

Three things, in order of impact:

1. Remove Domain Users and Domain Computers from enrollment rights on any template with SupplyInRequest 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. 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.

3. Enable the EDITF_ATTRIBUTESUBJECTALTNAME2 flag check. 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.

The Broader Context

ESC1 is documented in the Certified Pre-Owned research by SpecterOps. The tooling to exploit it—Certipy, among others—is publicly available and not complicated to use. Any attacker who has compromised a single endpoint with local admin rights 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 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 PSPKI audit on every client tenant with AD CS deployed
  • Remove Domain Users/Domain Computers from enrollment rights on SupplyInRequest templates
  • Restrict the NDES/Intune template to the NDES connector computer account only
  • Publish only templates with active, documented use cases
  • Check for EDITF_ATTRIBUTESUBJECTALTNAME2 at the CA level