Who can obtain a certificate on whose behalf? CA/template permissions, enrollment, and issuance controls

1. Core mechanism

Lesson 11.02 showed what a template defines. This lesson looks at the same object through its authorization model: which gates a request passes, what a flag says about client-supplied names, and why issuance is a separate decision.

Interfaces and specifications

• Certificate template object: An AD DS directory object under Public Key Services in the Configuration naming context, with its own security descriptor. Read its permissions using AD ACL semantics, not filesystem semantics.
• Certificate-Enrollment: The control access right with CN Certificate-Enrollment, Display-Name Enroll, Rights-GUID 0e10c968-78fb-11d2-90d4-00c04f79dc55, and Applies-To PKI-Certificate-Template.
• Certificate-AutoEnrollment: A separate control access right with rightsGuid a05b8cc2-17bc-4802-a710-e7c15ab866a2. It is distinct from Enroll and is represented by a separate ACE.
• msPKI-Enrollment-Flag: A bit field for enrollment and issuance behavior. CT_FLAG_PEND_ALL_REQUESTS (0x00000002) ordinarily makes the CA return a pending response and require CA manager approval. MS-WCCE documents a qualifying previous-approval renewal path where the CA ignores this flag.
• msPKI-Certificate-Name-Flag: Client and CA processing must be kept separate. MS-CRTD tells the client to include Subject information when CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT (0x00000001) is set, or SAN information when CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT_ALT_NAME (0x00010000) is set. On the CA side, MS-WCCE says to ignore the ALT_NAME bit by itself; when ENROLLEE_SUPPLIES_SUBJECT is set, the CA uses the request's Subject and SAN information. The client flag alone does not prove that the CA will issue the requested SAN. Review the separate CA-wide SAN setting as well.
• CA enrollment surface: the request service and the CA's own security descriptor. Its Request Certificates permission is separate from Read/Enroll/AutoEnroll on the AD template object; the template's Enroll GUID does not represent this CA-level permission.

CA permission and template permissions

Reaching a CA, being authorized to request a certificate from it, and being permitted to use the chosen template are separate requirements. Check Request Certificates in the CA's Security settings separately from Read and Enroll on the AD template. The default CA permission may come through Authenticated Users; no explicit grant for an individual account does not mean the check is absent.

For example, an NDES service account has Read and Enroll on its template but lacks effective Request Certificates permission on the CA. Its template permissions do not fill that gap. Conversely, Request Certificates on the CA does not grant Enroll on every template. Identify the account used for the request and assess its effective permissions in both places.

Enroll on a template is a control access right: its ACE carries the Enroll GUID in ObjectType together with the CR access mask. Read does not grant it. AutoEnroll is another right used by the client for automatic enrollment; it does not bypass the CA's template Enroll check. After authorization requirements are met, issuance conditions still need to be evaluated.

Request Certificates
  CA Security

Read / Enroll
  AD certificate template ACL

AutoEnroll
  Template ACL; client automation

Approval / pending
  CA issuance condition; not a right

Who supplies the Subject?

A template can use two broad models. In one, the CA derives Subject and SAN values from the requestor's directory object according to the template settings. In the other, the client is instructed to put identity fields into its request. MS-CRTD documents the client behavior: CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT requests a client-supplied Subject; CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT_ALT_NAME asks the client to supply SAN information.

Keep the client and CA rules separate. The MS-WCCE CA-side rule says to ignore CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT_ALT_NAME by itself. When CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT is set, the CA uses the Subject and SAN information in the request. So a client sending a SAN does not prove that the CA will copy that SAN into an issued certificate. Review the flag and the CA's issuance behavior together. Separately record the CA-wide EDITF_ATTRIBUTESUBJECTALTNAME2 setting: when enabled, it can permit requester-supplied SAN values regardless of the template’s Supply in the request setting. This does not establish actual issuance or account mapping.

The identity consequence depends on the certificate that is actually issued and where it is accepted. Broad Enroll permission on a template whose CA processing uses requester-supplied identity fields can create a path to identity material; the certificate's later use and acceptance policy remain separate decisions.

Issuance is a separate decision

Enroll permission lets a requester submit a request under a template; it does not promise immediate issuance. For an ordinary request, CT_FLAG_PEND_ALL_REQUESTS tells the CA to return pending and require a CA manager to approve before issuing.

Pending is a separate issuance decision, not an edit to the template ACL or a guarantee of safety. There is a documented renewal exception: when the previous-approval validation conditions apply, the CA ignores CT_FLAG_PEND_ALL_REQUESTS. Always inspect the full renewal context before treating the flag as a universal approval gate.

State and data flow

1. The client discovers an available template and submits a request to an enterprise CA configured to issue it. The account used for the request also needs CA-level Request Certificates permission.
2. The CA identifies the template and checks the requesting account’s Enroll permission in its security descriptor. CA-level permission does not replace template Enroll; a request without Enroll is rejected.
3. AutoEnroll is a separate client-side permission used by autoenrollment. It can trigger automatic enrollment, but the CA still checks Enroll when it receives the request.
4. Distinguish how the Name-Flag affects client request construction and CA name processing. The ALT_NAME bit alone does not establish acceptance under template processing; the CA-wide SAN setting is a separate control.
5. For ordinary requests, CT_FLAG_PEND_ALL_REQUESTS makes the CA return pending and require manager approval; qualifying previous-approval renewals are an exception.

2. Exploitation

Broken trust assumption

This is a defensive analysis of an ordinary user or machine principal that can read template ACLs. It describes no enrollment attempt against a real environment and claims no executed attack.

Technical prerequisites

• The account used for the request must have Request Certificates on the CA and Read/Enroll on the template. Review AutoEnroll separately for client-driven automatic enrollment; it replaces neither the CA nor the template permissions.
• Review template and CA rules together: client-supplied name information is not assumed to be identical to what the CA places in a certificate. Assess the separate CA-wide setting when reviewing SAN sourcing.
• Verify the issued certificate’s purpose and account-mapping requirements at the accepting system; issuance does not prove that acceptance.
• Assess approval on the ordinary issuance path separately from the qualifying previous-approval renewal exception.

Exploitation mechanism

Enroll grants permission to request under a template; it does not grant permission to choose the certificate identity or have it accepted by another system. In a defensive review, record permission scope, name sourcing, CA processing, issuance approval and verifier acceptance requirements separately. The same permission list can carry different risk as those conditions change. Assess AutoEnroll independently: it affects client automation but does not remove the CA’s Enroll check.

Why the permission list alone is not a risk score

Counting accounts in an Enroll list alone is not a risk assessment. Who supplies Subject and SAN, how the CA processes them, whether approval is required and where the certificate is accepted change the consequence.

Review the template security descriptor, Name-Flag values and CA-wide SAN setting together. Record which decision each affects; do not equate a field in the client’s request with a field in the issued certificate.

AutoEnroll and Enroll affect different decisions

AutoEnroll is a separate right used when a client creates automatic requests without an interactive user action. It does not replace Enroll, which the CA checks for a submitted request. Read the automation scope from the AutoEnroll ACE and template-use authorization from the Enroll ACE.

In the fixture, AutoEnroll alone does not fill the missing Enroll requirement. Granting a right also does not establish that a successful request or distribution was observed.

3. Defense & Detection

Telemetry scope

• Record effective Request Certificates permissions from CA Security settings separately. Inspect Read scope and Enroll/AutoEnroll ACEs in each template security descriptor, distinguishing the control access rights by ObjectType GUID. The CA ACL and template ACL are separate permission sets.
• Inventory msPKI-Certificate-Name-Flag values, keeping the client and CA meanings of ENROLLEE_SUPPLIES_SUBJECT and ALT_NAME separate. Also review EDITF_ATTRIBUTESUBJECTALTNAME2 on the relevant CA; the template setting does not replace this CA-wide control.
• Among templates whose CA-side processing uses requester-supplied identity fields, prioritize those without CT_FLAG_PEND_ALL_REQUESTS for ordinary requests and whose output is accepted for authentication. Check the documented previous-approval renewal exception separately.
• 5136 requires Audit Directory Service Changes and a matching object SACL; 4662 requires Audit Directory Service Access and a matching object SACL. Check the DC’s success/failure coverage, object and operation together; these are different subcategories.

Events and relevant fields

• 5136 · A directory service object was modified. Changes to a template object appear only with an appropriate SACL and Audit Directory Service Changes configuration.
• 4662 · An operation was performed on an object. Recording an AD object operation depends on Audit Directory Service Access coverage and a matching object SACL. It is not generated by default everywhere; absence does not establish that no use occurred.

Rank the inventory by what the CA can issue

Prioritize by the identity material the CA can issue and the systems that accept it, rather than ACE count. Review name sourcing, the CA-wide SAN setting, template authorization, approval requirements and certificate purpose together.

Apply the same discipline to AutoEnroll. Reporting the two rights in separate columns makes visible the difference hidden by a single ‘can receive a certificate’ indicator.

Detection logic · XPath

*[System[(EventID=5136)]]

Query assumptions

• The query selects only the directory-object-modification event envelope; inspect the event content to verify whether the changed object is a certificate template.
• Event generation depends on a matching SACL on the object and the Audit Directory Service Changes subcategory being enabled. This lesson does not assume that configuration is present.

False positives

• Planned template maintenance, an application deployment, or permission repairs can produce the same event; an event alone does not establish malicious intent.
• No event is not proof of safety: without a SACL, a dangerous ACL change may not produce a record.

Hardening

• Grant Enroll and AutoEnroll to purpose-limited, reviewable groups rather than broad built-in groups.
• Restrict templates that allow client-supplied identity fields to their intended use. Assess template Name-Flag values separately from CA-wide EDITF_ATTRIBUTESUBJECTALTNAME2. Before planning a CA-setting change, investigate dependent issuance workflows; do not assume that restricting the template closes every SAN input path.
• Use a separate issuance approval step (CT_FLAG_PEND_ALL_REQUESTS) on high-impact templates, with approval held by a role distinct from enrollment authorization. Check the previous-approval renewal exception as well.
• Compare CA Security Request Certificates permissions and template security descriptors against separate baselines. Record where broad group grants come from and which account the request path uses; do not rely on a one-time review.

Read the examples

O:DAG:DAD:P(A;;RPLCLORC;;;AU)(OA;;CR;0e10c968-78fb-11d2-90d4-00c04f79dc55;;S-1-5-21-1835020781-2103267434-1139111218-1142)(OA;;CR;a05b8cc2-17bc-4802-a710-e7c15ab866a2;;S-1-5-21-1835020781-2103267434-1139111218-1142)(A;;GA;;;DA)

Two reality checks

Assumption: Anyone with Read permission on the template can enroll; there is no separate right.

In fact: Enroll is a separate control access right with GUID 0e10c968-78fb-11d2-90d4-00c04f79dc55. AutoEnroll has a different GUID and client-side role; Read does not grant either right. The CA separately checks Enroll when processing a request. Name processing is also distinct from permissions: review client rules, CA template-processing rules and the CA-wide SAN setting together.

Assumption: If Enroll is granted, the certificate is issued immediately; there is no other gate.

In fact: Template Enroll alone is insufficient: the account used for the request also needs CA-level Request Certificates permission. Those permissions do not guarantee immediate issuance. For ordinary requests, CT_FLAG_PEND_ALL_REQUESTS returns pending and requires CA manager approval; assess the MS-WCCE previous-approval renewal exception separately.

Sources

• Microsoft · Certificate-Enrollment extended right (AD Schema)
  CN Certificate-Enrollment, Display-Name Enroll, Rights-GUID 0e10c968-78fb-11d2-90d4-00c04f79dc55, Applies-To PKI-Certificate-Template.
• Microsoft Open Specifications · [MS-ADTS] Certificate-AutoEnrollment
  Certificate-AutoEnrollment control access right object and rightsGuid a05b8cc2-17bc-4802-a710-e7c15ab866a2.
• Microsoft Open Specifications · [MS-CRTD] msPKI-Certificate-Name-Flag
  The attribute table describes client-side processing for the Subject-supply and SAN-supply bits.
• Microsoft Open Specifications · [MS-WCCE] Certificate.Template.msPKI-Certificate-Name-Flag (CA processing)
  CA processing: ignores CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT_ALT_NAME by itself; when CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT is set, uses request Subject and SAN.
• Microsoft Open Specifications · [MS-WCCE] Certificate.Template.msPKI-Certificate-Name-Flag (client processing)
  Either subject-supply flag or SAN-supply flag instructs the enrollment client to supply request identity information.
• Microsoft Open Specifications · [MS-WCCE] msPKI-Enrollment-Flag
  CT_FLAG_PEND_ALL_REQUESTS ordinarily requires manager approval; qualifying previous-approval renewal processing ignores the flag.
• Microsoft Open Specifications · [MS-WCCE] Verify End Entity Permissions
  CA checks Enroll permission against the template security descriptor and rejects requests from entities without it.
• Microsoft Open Specifications · [MS-CRTD] Determining Autoenrollment Permission
  AutoEnroll is evaluated as a separate control access right against the template security descriptor.
• Microsoft Open Specifications · [MS-ADTS] Control Access Rights
  Control access right ACE model: the control-access bit in ACCESS_MASK and the ObjectType GUID scope.
• Microsoft · Audit Directory Service Changes
  Event 5136 requires the Audit Directory Service Changes subcategory and a matching object SACL; the subcategory logs on domain controllers.
• Microsoft · Event 4662
  Audit Directory Service Access subcategory and matching object SACL are separate generation requirements; AD object-operation event, not issuance/mapping proof.
• Microsoft Open Specifications · [MS-CRTD] msPKI-Enrollment-Flag Attribute
  CT_FLAG_PEND_ALL_REQUESTS 0x00000002 instructs the CA to put requests into a pending state; see the existing MS-WCCE source for renewal processing exceptions.
• Microsoft · NDES service account: CA and template permissions
  Prerequisites and Set up request permission on the CA: separate CA Request Certificates and template Read/Enroll requirements; CA Security settings.
• Microsoft · Audit Directory Service Access
  Controls generation of AD DS access audit events; Event 4662 listing and object/operation SACL design.
• Microsoft · Manage certificate templates
  Security considerations: CA-wide EDITF_ATTRIBUTESUBJECTALTNAME2, distinct from template Supply in the request; investigate dependencies before policy changes.