AD-ADCS-007: ESC13: issuance policy linked to a group¶

high   Certificate services   MITRE ATT&CK T1649   Reads: LDAP

A published authentication template that broad groups can enroll in carries an issuance policy linked to a group, so every enrollee gets that group's rights.

Also known as: esc13

Why it matters¶

Authentication mechanism assurance lets an administrator link an issuance policy (an msPKI-Enterprise-Oid object under CN=OID) to a universal group through its msDS-OIDToGroupLink attribute. When someone logs on with a certificate that carries that issuance policy, the domain controller adds the linked group to their Kerberos ticket, even though they are not a member of it.

The feature is meant for "this logon used a smart card" style groups. If the template that issues the policy is open to Domain Users, every user can enroll, authenticate with the certificate (PKINIT) and act with the linked group's permissions: its ACL grants, file shares, or whatever it was nested into. The group membership never appears in Active Directory, so group-based reviews miss it.

How ad-doctor detects it¶

ad-doctor reads every msPKI-Enterprise-Oid object under CN=OID,CN=Public Key Services,CN=Services,CN=Configuration that has msDS-OIDToGroupLink set, then reports a template when all of these hold:

Each object names the template and the broad groups that can enroll, for example LabESC13 (enroll: Domain Users). Find the linked group with the read-only command in the remediation.

Severity¶

Always high: ad-doctor does not weigh what the linked group can do. Downgrade by accepting the risk only after confirming the group grants nothing of value.

False positives and limits¶

• A linked group with no rights. If the group is used only as a marker (for example, for conditional access on a file share that holds nothing sensitive), the impact is small. Confirm what the group can do before accepting the risk; see the accepted-risks file.
• Narrower enrollment groups are not reported here; their members still gain the linked group.

Fix¶

1. Find the linked group (read-only):

   $cfg = (Get-ADRootDSE).configurationNamingContext
   Get-ADObject -SearchBase "CN=OID,CN=Public Key Services,CN=Services,$cfg" `
       -LDAPFilter '(msDS-OIDToGroupLink=*)' `
       -Properties 'msPKI-Cert-Template-OID', 'msDS-OIDToGroupLink' |
       Select-Object Name, 'msPKI-Cert-Template-OID', 'msDS-OIDToGroupLink'
   

2. Restrict enrollment in the template to the users who should receive the group, for example the group's intended members, in the template's Security tab.

3. Or remove the link if the feature is not in use:

   Set-ADObject '<DN of the msPKI-Enterprise-Oid object>' -Clear 'msDS-OIDToGroupLink' -WhatIf
   

4. Review what the linked group can do and keep it as small as the design allows.

Verify¶

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

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

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

Related checks¶

• AD-ADCS-001
• AD-ADCS-004
• AD-PATH-001

References¶

Specifications

• msDS-OIDToGroupLink attribute

Research

• ADCS ESC13 Abuse Technique (SpecterOps)

Tools

• Certipy wiki: Privilege escalation (ESC13)

MITRE ATT&CK

• T1649

Available since 0.1.0.