What is AD CS?

Active Directory Certificate Services (AD CS) is Microsoft's public key infrastructure (PKI) for issuing and managing digital certificates. Certificates enable encryption, digital signatures, and, most importantly for this post, authentication of users, computers, and services.

Why leaders should care: When templates or web enrollment are set up loosely, a normal user can use a valid certificate to turn a small foothold into complete domain control.

---

How AD CS Works (at a Glance)

Users or computers generate a key pair and send a Certificate Signing Request (CSR) to an Enterprise Certificate Authority (CA). The CA checks template rules in Active Directory, and if the requester is allowed, it issues a certificate that inherits the template's permissions and usage (EKUs).

In short:

• Enterprise CA issues and signs certificates.
• Certificate templates (AD objects) define who can enroll and for what purposes (e.g., client authentication, smart card logon).
• If the template is permissive or the web enrollment path is exposed, attackers can leverage it to authenticate as someone else.

---

Why AD CS Misconfigurations Matter

Certificates map to AD identities (often via Subject Alternative Name, SAN). If a template allows a requester to supply the SAN and has authentication EKUs, that requester can get a certificate that authenticates as a different user, possibly a Domain Admin. Certificates also outlive passwords and are harder to spot, which makes them ideal for stealthy escalation and persistence.

---

Three Common Attack Paths (Plain English)

1) ESC1: Misconfigured Certificate Template

What it is: A template that lets low-privileged users enroll, has authentication EKUs, requires no approval or signatures, and allows the requester to supply the SAN.

Why it's bad: A normal user can request a certificate that says, "I am Domain Admin," then use it to get Kerberos tickets and act as that admin. This is a direct path from standard user access to a complete domain compromise.

Fast fixes:

• Restrict enroll rights to specific groups; remove "Domain Users/Authenticated Users → Enroll."
• Disable "Supply in request." Build the subject from AD instead.
• Require manager approval for sensitive templates.
• Review cloned templates that inherited risky settings.

Tell‑tale signs to monitor:

• CA events 4886 (request received) and 4887 (certificate issued), where the Requester and SAN do not match, especially when SAN is a privileged account.

---

2) ESC4 : Weak Access Control on Templates

What it is: Anyone with rights like WriteProperty, WriteDACL, WriteOwner, FullControl, or being Owner on a template can edit it. Attackers use that to flip safe templates into ESC1 and then enroll a forged identity.

Why it's bad: It turns a configuration mistake into a reliable domain escalation. A harmless template becomes a "mint a Domain Admin certificate" machine.

Fast fixes:

• Remove broad Write or FullControl rights from templates (e.g., remove them from "Domain Users"). Least privilege only.
• Regularly audit template ACLs and ownership.
• Track template changes and approvals.

Tell‑tale signs to monitor:

• CA event 4899 (template attribute updated) and 4887 (issued). Correlate who changed the template with who enrolled and for whom.

---

3) ESC8: NTLM Relay to AD CS Web Enrollment

What it is: AD CS web endpoints (e.g., /certsrv, CES/CEP, NDES) can be abused with NTLM relaying. An attacker coerces a machine or user to authenticate to them, relays that to the CA's web service, and gets a valid client‑auth certificate as the victim.

Why it's bad: A one‑time coerced auth becomes long‑lived access via a legitimate certificate. This often bypasses network signing restrictions and enables high‑impact lateral movement. Techniques like printer bug or PetitPotam help coerce authentication.

Fast fixes:

• Prefer to turn off legacy Web Enrollment where possible.
• If you must keep web services, enable Extended Protection for Authentication (EPA) with channel binding, require HTTPS, and prefer Kerberos.
• Segment and restrict access to AD CS web endpoints; monitor them for strange inbound requests.
• Keep coercion paths patched (spooler service, EFSRPC/PetitPotam, etc.).

Tell‑tale signs to monitor:

• Sudden issuance of user or machine client‑auth certificates near the time of suspicious NTLM activity.
• Certificates issued to high‑value machines (DCs, Exchange) from web endpoints.

---

What "Good" Looks Like

• Inventory and owners for every template. Sensitive templates are locked down and require approval.
• No "Supply in request" on authentication‑capable templates.
• Tight ACLs on templates. Periodic review for Owner/WriteDACL/WriteProperty.
• Web enrollment minimized or hardened with EPA and strict access controls.
• Auditing on: CA events 4886, 4887, 4899, with alerts for Requester ≠ SAN or privileged SANs.
• Periodic AD CS assessments are included in your AD security reviews.

---

Bottom Line

AD CS often flies under the radar, yet it directly controls who can prove identity in your domain. The three scenarios above, ESC1, ESC4, and ESC8, are common, well‑documented, and regularly exploited during real assessments. A focused review and a few targeted configuration changes close the door on high‑impact, low‑noise attack paths.

Our Active Directory Security Hardening & Hygiene Checklist covers the most common issues we see during internal assessments and how to properly address them.

---

Have a question about this article or a security challenge of your own?

Vilkas Cybersecurity helps organizations uncover and fix real-world exposures, not just theoretical ones. Fill out the form and we'll get back to you shortly.