Active Directory Certificate Services (AD CS) is often the easiest and quietest route to domain admin for an attacker. Sometimes it takes only minutes, because a misconfigured certificate template has been sitting in plain sight all along. In incident reviews and environment audits I've come across ESC1-like vulnerabilities more often than I'd like: templates with "Enrollee supplies subject" enabled, enroll permissions that are far too broad, or legacy settings nobody has touched in years. What separates a compromised domain from a quiet night's sleep is actually monitoring, assessing and hardening AD CS, and that is surprisingly rare even in well-run organizations. Defender for Identity finally gives us practical tools for the job.

ESC1 attack paths turn up in production more often than they should

Anyone who starts looking into AD CS hardening runs into the ESC1 attack path fairly quickly. With the right (or rather, wrong) certificate template, a regular user can request a certificate for any identity in the domain and then use it to escalate privileges on the spot. I still find several at-risk templates in production tenants. Usually they're leftovers from PKI migrations nobody remembers, or quick lab pilots that somehow ended up in production. "Enrollee supplies subject" combined with permissive enrollment rights is a dangerous mix. Most admins don't realize how easy it is to exploit until MDI or a pentest points it out explicitly.

Defender for Identity sensors and posture assessments expose AD CS risks

Microsoft has expanded the Security Posture Assessments in Microsoft Defender for Identity, and AD CS risks are finally visible. Step one is installing the Defender for Identity sensor on every AD CS server, not only on your DCs. Plenty of organizations still miss that part. Once the sensors are running, you'll find clear recommendations under Defender portal → Exposure management → Recommendations or directly in your Secure Score. Look for items such as "Prevent users to request a certificate valid for arbitrary users." Microsoft's documentation on AD CS assessments covers the details.

MDI also monitors your AD CS environment for suspicious activity. If someone tries to request a certificate for another user's account or exploits a known PKI weakness, you get an alert in real time. This fits well with hybrid identity, and if you want background on the role Entra Connect plays here, see my post comparing Entra Cloud Sync and Connect Sync for hybrid identity in 2024.

A single misconfigured template can lead straight to domain admin

The Mermaid diagram below shows how a misconfigured certificate template (ESC1) turns into a shortcut to domain admin when AD CS hardening is skipped:

flowchart TD
    User["User"] --> Template["Misconfigured template"]
    Template --> ADCS["AD CS server"]
    ADCS --> Cert["Certificate for any user"]
    Cert --> AD["Active Directory"]
    AD --> DomainAdmin["Domain admin rights"]

Figure: An ESC1-style AD CS vulnerability without hardening, leading directly to domain admin.

In larger environments especially, the MDI assessments help you keep an overview of all your templates. They flag the obviously dangerous ones, but also templates with subtler problems, such as an "Any Purpose" EKU or enrollment permissions that are broader than they need to be.

These template changes are where I start hardening AD CS

MDI doesn't replace a full PKI review, but it's a good starting point for real AD CS hardening. These are the steps I implement most often:

  • Remove "Enrollee supplies subject" wherever possible
  • Limit enrollment permissions to the smallest group feasible
  • Enable manager approval for sensitive templates
  • Enable StrongCertificateBindingEnforcement (Windows Server 2022+)
  • Remove obsolete templates and enrollment agents

Practical tip: Back up your templates with certutil before you change anything, and test enrollment with non-privileged pilot users. I've seen legacy apps break silently when a field or EKU went missing.

The Defender for Identity guide for AD FS and certificates also explains how sensors interact with the different roles. If you use federated authentication, it's worth reading.

MDI raises alerts when someone tries to abuse a template

Where Defender for Identity really pays off is visibility. Besides flagging risky templates, it actively raises alerts (under "Incidents") when a user or attacker tries to exploit a template to request a certificate for someone else. In several tenants, those alerts were the first sign of a privilege escalation path nobody had been watching. With the right license (Microsoft 365 E5 Security or equivalent), you can also run custom advanced hunting queries in the Defender portal to audit high-privilege certificate requests. There's more on this in What is Defender for Identity?.

AD CS hardening is not optional, and MDI makes it doable

AD CS is still an underestimated risk in 2025. With Defender for Identity's posture assessments, a proper sensor rollout and hands-on template reviews, you can finally bring your PKI under real control. Once you've seen how close your organization came to a domain compromise because of one forgotten template, you'll look at AD CS differently from then on.