Tools · Active Directory defense · 17 / 23
Active Directory Certificate Services security: risky certificate templates explained
Understand why AD CS is Tier 0, recognize templates that let requesters choose the subject, audit them with defensive tools, and turn on CA auditing.
Why certificates are identities
AD CS issues certificates that can be used for Kerberos authentication through PKINIT. A certificate that names a user and includes the Client Authentication purpose is as good as that user’s password for logging on, and it stays valid until it expires or is revoked, even after the password changes. The CA and its templates are therefore Tier 0.
Research published in 2021 grouped AD CS misconfigurations into categories often labelled ESC1 onward. The most common is a template that lets the requester supply any subject name.
The risky template pattern
A template is dangerous when all of these are true: low-privileged users such as Domain Users can enroll; the template allows the enrollee to supply the subject or subject alternative name (CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT); the template includes an authentication EKU such as Client Authentication or Any Purpose; and manager approval and authorized signatures are not required. With such a template, any user could request a certificate naming an administrator.
Other categories involve overly permissive template ACLs, CA-wide settings like EDITF_ATTRIBUTESUBJECTALTNAME2, and web enrollment without Extended Protection.
Lab: audit templates defensively
Install AD CS in the lab with an enterprise CA. Duplicate the User template, allow “Supply in the request” on the Subject Name tab, and grant Domain Users enroll. Then audit with a defensive tool such as Locksmith, an open-source PowerShell module built to find and fix AD CS misconfigurations, or by reading template flags with PowerShell. Confirm the template is flagged, then fix it by removing enrollee-supplied subject or restricting enrollment and requiring manager approval.
Enable CA auditing so requests and issuance are logged: certutil -setreg CA\AuditFilter 127, then restart the service. Events 4886 (request received) and 4887 (issued) appear in the CA’s Security log.
Get-ADObject -SearchBase "CN=Certificate Templates,CN=Public Key Services,CN=Services,$((Get-ADRootDSE).configurationNamingContext)" -LDAPFilter '(objectClass=pKICertificateTemplate)' -Properties msPKI-Certificate-Name-Flag, pKIExtendedKeyUsage, msPKI-Enrollment-Flag |
Where-Object { ($_.'msPKI-Certificate-Name-Flag' -band 1) -and ($_.pKIExtendedKeyUsage -match '1.3.6.1.5.5.7.3.2|2.5.29.37.0') } | Select Name
certutil -setreg CA\AuditFilter 127
Restart-Service certsvcFixes and monitoring
Remove enrollee-supplied subject from authentication templates, restrict enrollment to the groups that need it, require manager approval where subjects must be supplied, and unpublish templates nobody uses. Apply recent Windows updates that enforce strong certificate mapping on DCs.
Alert on 4887 events where the requester differs from the subject on authentication templates. Inventory issued certificates and revoke any you cannot explain.
Diagram
Ingredients of a risky template
All four together make any user able to request an admin’s certificate.
- Broad enrollment
Domain Users or Authenticated Users can enroll.
- Enrollee supplies subject
The requester chooses the name in the certificate.
- Authentication EKU
Client Authentication, Smart Card Logon, or Any Purpose.
- No approval
No manager approval or authorized signatures.
Check yourself
1. Why is a certificate with Client Authentication for a user as sensitive as their password?
2. Which template setting lets the requester choose whose name goes in the certificate?
3. Which CA events record certificate requests and issuance?