AD-ADCS-005: ESC5: non-tier-0 control over PKI objects¶

high   Certificate services   MITRE ATT&CK T1649   Reads: LDAP

Principals outside tier 0 control a PKI object in the configuration partition (NTAuthCertificates, a template or CA container, or a CA object).

Also known as: esc5

Why it matters¶

Active Directory's PKI configuration lives under CN=Public Key Services,CN=Services,CN=Configuration, and these objects decide which certificates the forest trusts for logon:

• NTAuthCertificates lists the CAs whose certificates domain controllers accept for Kerberos (PKINIT) and smart card logon. Whoever can write it can add a CA they run themselves and then mint a logon certificate for any account.
• Certificate Templates container: control over it lets the holder create a new template, or take over existing ones through inheritance, and build an ESC1 template.
• Enrollment Services container and each CA object (pKIEnrollmentService): writing a CA object's certificateTemplates publishes any template on that CA, and the container controls which CAs exist.

Because these objects sit in the configuration partition, they are forest-wide and are often missed by audits that only look at the domain partition.

How ad-doctor detects it¶

ad-doctor reads the DACL of CN=NTAuthCertificates, CN=Certificate Templates, CN=Enrollment Services and every pKIEnrollmentService object over LDAP, and reports each principal that holds GenericAll, GenericWrite, WriteDacl, WriteOwner, or WriteProperty on all attributes, unless it is:

• tier 0 (Domain Admins, Enterprise Admins, Administrators, SYSTEM, domain controllers and the other built-in tier-0 principals), or
• Cert Publishers, which CA servers are members of and which manages these objects by design, or
• on a CA object, that CA server's own computer account.

Each object names the PKI object and the principals, for example NTAuthCertificates (helpdesk) or CA adlab-CA (svc_pki).

Severity¶

Always high: control over these objects lets the holder add a trusted CA or a vulnerable template.

False positives and limits¶

• Not covered: the CN=Public Key Services container itself, the AIA, CDP and OID containers, the CA server's computer object and the CA's local administrators. Control of the CA host is ESC7-equivalent; see AD-ADCS-013.
• Cert Publishers members are trusted here; unexpected members of that group are reported by AD-PRIV-009.
• A dedicated PKI admin group may hold these rights on purpose. Treat it as tier 0 rather than accepting the finding repeatedly.

Fix¶

1. List the grants on the reported object (read-only):

   $cfg = (Get-ADRootDSE).configurationNamingContext
   $dn  = "CN=NTAuthCertificates,CN=Public Key Services,CN=Services,$cfg"
   (Get-Acl "AD:$dn").Access |
       Where-Object ActiveDirectoryRights -match 'GenericAll|GenericWrite|WriteDacl|WriteOwner|WriteProperty' |
       Select-Object IdentityReference, ActiveDirectoryRights, IsInherited
   

2. Remove the write rights for the reported principals. dsacls has no dry run, so review the output of step 1 first:

   dsacls "CN=NTAuthCertificates,CN=Public Key Services,CN=Services,CN=Configuration,DC=corp,DC=example" /R "CORP\helpdesk"
   

3. Check what the principal may already have done: compare the CA certificates in NTAuth with the CAs you run (certutil -viewstore -enterprise NTAuth), and look for templates or published templates you did not create.

Verify¶

ad-doctor scan dc01.corp.example --ldaps -u 'CORP\auditor' --only AD-ADCS-005

To accept the risk instead, add an entry to the file passed with --accept (see accepted risks):

[[accept]]
check = "AD-ADCS-005"
objects = ["..."]        # optional; without it the whole check is accepted
reason = "..."
expires = 2027-03-31

Related checks¶

• AD-ADCS-004
• AD-ADCS-013
• AD-PRIV-009
• AD-PATH-001

References¶

Microsoft and vendors

• certutil

Research

• Certified Pre-Owned: Abusing Active Directory Certificate Services (whitepaper, ESC5)

Tools

• Locksmith: find and fix AD CS misconfigurations

MITRE ATT&CK

• T1649

Available since 0.1.0.