Enterprise CAs and certificate templates: Subject, SAN, EKU, and intended use

1. Core mechanism

A standalone CA evaluates requests under its own issuance policy without certificate templates; an Enterprise CA uses templates stored in AD DS and published on the relevant CA. A template defines certificate fields, permitted uses, key rules, and eligible requesters. The answer to “what does the CA sign?” therefore depends on the template and its enrollment permissions as well as the CA. Issuance alone does not prove that a target protocol will map or accept the certificate as a particular account.

Interfaces and specifications

• Certificate template: a directory object stored in AD DS; an Enterprise CA must also publish it in its own list before issuing from it.
• Subject name source: the template determines whether the Subject is built from selected AD data or supplied in the request; review SAN behavior separately.
• Subject Alternative Name (SAN): can carry structured identities such as dNSName, rfc822Name, or UPN-form otherName; the verifier decides which form it recognizes.
• Extended Key Usage (EKU): when present, limits the certificate to the listed purposes; the verifier’s usage policy also matters.
• Enroll and Autoenroll: extended rights on the template object, granted through its security descriptor.
• Manager approval or authorized-signature requirements: can hold a request for approval before issuance.
• Published-template list: maintained for each CA; a template existing in AD DS does not mean every CA issues from it.
• AD certificate authentication: current KDC certificate-to-account mapping is a separate check; Subject/SAN or issuance alone does not prove strong mapping to a principal.

What the template controls

A template combines at least four decisions: which identity fields appear in the certificate, where those values come from, which purposes the certificate supports, and who may request it. Reading any one in isolation can produce the wrong conclusion.

The Subject-name-source setting matters. If the Subject is built from selected information in the AD object, the requester cannot choose an arbitrary Subject through that setting. If the Subject comes from the request, that value can be used subject to issuance permissions and approval rules. Review SAN behavior separately.

Subject and SAN carry different identity forms

The Subject is an X.500 Distinguished Name. SAN can carry additional structured identities such as dNSName, rfc822Name, and Microsoft UPN-form otherName.

SAN is important because many protocols use structured SAN identities, but the exact identity field depends on the verifier, protocol, and configuration. A correct-looking Subject does not establish the SAN source or prove how an AD KDC will map the certificate to an account.

Name-source controls exist at both the template and CA level. A CA-wide SAN override must be reviewed separately from the template setting. Its presence does not establish issuance, certificate-to-account mapping or authentication success.

EKU: a certificate-use constraint

Extended Key Usage limits a certificate to purposes represented by OIDs. Client Authentication (1.3.6.1.5.5.7.3.2) and Microsoft Smart Card Logon (1.3.6.1.4.1.311.20.2.2) are examples associated with authentication use.

When the EKU extension is present, RFC 5280 restricts use to the listed purposes; an application can also require a particular purpose. EKU is not enrollment permission, and actual enforcement belongs to the verifier’s policy.

Enrollment is an authorization decision

The template security descriptor determines which principals can enroll. Enroll and Autoenroll are extended control-access rights, distinct from ordinary read/write permissions.

Reviewing the CA alone is not enough; inspect who can enroll on each template. Broad enrollment on a template that allows request-supplied identity fields and includes an authentication purpose can create a high-impact issuance path.

State and data flow

1. An administrator creates or duplicates a certificate template.
2. The template defines the Subject source, SAN behavior, EKU, and key rules.
3. Its ACL grants Enroll or Autoenroll to selected principals.
4. The template is published on one or more Enterprise CAs.
5. A client creates a key pair and a request that references the chosen template.
6. The CA evaluates the requester’s Enroll permission and the applicable template/CA issuance conditions.
7. Under the template rules, the CA constructs Subject/SAN fields or accepts allowed values from the request; the Subject setting alone does not define SAN behavior.
8. If manager approval or an authorized signature is required, the request is held; once conditions are met, the CA signs and returns the certificate.
9. The verifier evaluates the certificate purpose and identity fields under its own policy. For AD KDC authentication, certificate-to-account/strong-mapping requirements apply separately; issuance does not prove that result.

2. Exploitation

Broken trust assumption

A likely objective is getting a trusted CA to issue a certificate with attacker-chosen identity fields. Whether it then authenticates as another AD principal also depends on target-protocol mapping rules and verifier policy.

Technical prerequisites

• The template has an EKU or purpose that can be used for authentication.
• Relevant template and CA rules must allow the requested identity data; the template name setting alone does not establish the CA-wide SAN policy.
• The requester needs Enroll on the template for enrollment; AutoEnroll is a separate right for automatic enrollment and does not replace Enroll.
• A required manager-approval or authorized-signature check is absent or bypassed.
• The template is published on the Enterprise CA that issues the certificate.
• For authentication, the target verifier must accept the certificate-to-account mapping under its current policy.

Exploitation mechanism

Risk comes from a combination of settings. A template with an authentication-capable purpose, request-supplied identity fields, broad Enroll rights, no required approval, and publication on the relevant Enterprise CA can issue a certificate containing chosen identity values. This does not break cryptography. Issuance alone does not prove that the target KDC will map the certificate to another account; current strong-mapping rules and target-verifier policy must also be checked.

Risk comes from the combination

An authentication EKU can be legitimate, request-supplied names may serve some workflows, and enrollment rights may be granted to broad groups for convenience. Risk arises when these conditions meet on one published template and make issuance with requester-chosen identity fields accessible. Authentication as an AD account still depends on mapping policy.

The useful review unit is a profile for each template: EKUs, identity source, approval requirements, Enroll holders, and the CAs where it is published.

Why remediation must include issued certificates

Changing a template does not retroactively delete or revoke certificates issued earlier. A previously issued certificate may remain acceptable during its validity period if the target verifier’s revocation and mapping policies permit it.

When correcting a misconfiguration, inventory existing issuance records and certificates, and revoke them separately when needed. A password change alone does not revoke a certificate.

3. Defense & Detection

Telemetry scope

• Which templates have an authentication-capable EKU, and who can enroll on them?
• Which templates allow identity fields to be supplied in the request?
• Which such templates do not require manager approval or an authorized signature?
• Which groups have Enroll and Autoenroll, since when, and for what documented reason?
• Do issued Subject/SAN values match the expected identity for the requester, service, or device?
• For AD KDC authentication, what strong-mapping policy is deployed, and are explicit mappings or SID-extension requirements satisfied on the target domain controllers?

Events and relevant fields

• Correlating the CA database request/issuance record with the issued certificate helps identify the requester/request, template, and signed Subject/SAN fields. It does not prove private-key custody or successful authentication.
• A change to the template security descriptor appears as a directory ACL change and is a high-value signal.
• Publishing a new template or changing an existing template’s EKU/name behavior is a relatively rare, high-impact configuration change.
• An unexpected difference between requester-account identity and issued Subject/SAN is a triage signal; device/service and delegated-issuance workflows can be legitimate, so it is not proof of abuse.
• Microsoft KB5014754 documents KDC Event 39, or Event 41 on some older supported Windows Server versions, for strong-certificate-mapping cases. Interpret these only in the relevant update, KDC-role, and mapping-mode context; they are not a universal AD CS template-event list.

Review a profile for each template

A useful defensive output is one profile per template: EKUs, identity source, approval requirements, Enroll holders, and which CAs publish it. This makes risky combinations visible.

Repeat this review periodically. Template definitions, publication, and ACLs can expand over time through changes that look harmless in isolation.

Correlate issuance with directory authorization

The CA database answers questions about the request and issuance; a time-appropriate directory ACL snapshot answers who had Enroll on that template. A current ACL alone does not prove who was authorized at the time of an older request.

Identify the signed certificate fields and template, then correlate the CA record with the request-time template ACL. If authentication is alleged, add KDC strong-mapping evidence and the verifier result. These sources still do not by themselves reveal private-key custody.

Detection logic · KQL

// Synthetic schema example: surface certificate requests whose claimed UPN differs from the requester's account UPN.
// Validate table and fields for the environment; this query has not been run.
CertificateRequest
| where isnotempty(RequestedUpn)
| extend RequesterUpn = tolower(RequesterAccountUpn), ClaimedUpn = tolower(RequestedUpn)
| where RequesterUpn != ClaimedUpn
| project TimeGenerated, CaName, TemplateName, RequesterUpn, ClaimedUpn, RequestId
| order by TimeGenerated desc

Query assumptions

• No dataset is available; the query has not been executed.
• Table and field names are illustrative and are not a native Windows event schema.
• Central collection of CA request records is assumed.
• A UPN mismatch is only a triage candidate; it does not prove certificate issuance, target-KDC mapping, or successful authentication.

False positives

• Central automation legitimately requesting certificates for service accounts.
• Device or service certificates whose identity fields are expected to differ from the requester account.
• Temporary old identities during a migration or renaming period.

Hardening

• For authentication-use templates, prefer Subject/SAN information from AD DS and restrict requester-supplied names. Also review the issuing CA’s EDITF_ATTRIBUTESUBJECTALTNAME2 setting: with that CA-wide override enabled, turning off the template’s Supply in the request option does not by itself prevent requester-supplied SAN values. Confirm the override is disabled and review dependent issuance workflows before changing CA policy.
• Grant Enroll and Autoenroll to narrowly scoped groups with a clear purpose.
• Require manager approval or authorized signatures when requesters must choose identity values.
• Review which templates are published on each issuing CA and remove unused publications.
• Track template ACL changes as a separate, approved change category.
• When correcting a template, inventory and revoke existing certificates when necessary.
• For AD certificate authentication, apply current strong-mapping requirements and verify target-DC updates/policy; do not rely on obsolete compatibility registry workarounds.

Read the examples

30 81 d2 30 1f 06 03 55 1d 25 04 18 30 16 06 08
2b 06 01 05 05 07 03 02 06 0a 2b 06 01 04 01 82
37 14 02 02 30 4d 06 03 55 1d 11 04 46 30 44 a0
29 06 0a 2b 06 01 04 01 82 37 14 02 03 a0 1b 0c
19 73 76 63 2d 77 65 62 40 6f 75 74 72 65 61 73
6f 6e 2e 65 78 61 6d 70 6c 65 82 17 77 65 62 30
31 2e 6f 75 74 72 65 61 73 6f 6e 2e 65 78 61 6d
70 6c 65 30 31 06 09 2b 06 01 04 01 82 37 15 07
04 24 30 22 06 1a 2b 06 01 04 01 82 37 15 08 83
d7 89 2f 83 a8 9f 57 e9 e3 76 fd f1 39 02 81 0e
02 01 64 02 01 02 30 2d 06 09 2b 06 01 04 01 82
37 14 02 04 20 1e 1e 00 43 00 6f 00 72 00 70 00
57 00 65 00 62 00 53 00 65 00 72 00 76 00 65 00
72 00 56 00 32

O:DAG:DAD:(A;;RPWPCRCCDCLCLORCWOWDSDDTSW;;;DA)(OA;;CR;0e10c968-78fb-11d2-90d4-00c04f79dc55;;S-1-5-21-1002233445-2244556677-3366778899-1137)(OA;;CR;a05b8cc2-17bc-4802-a710-e7c15ab866a2;;S-1-5-21-1002233445-2244556677-3366778899-1137)(A;;RPLCLORC;;;AU)

Two reality checks

Assumption: If the Enterprise CA itself is securely configured, which templates it publishes is a minor detail.

In fact: An Enterprise CA issues according to template rules. Request-supplied identity fields, an authentication-capable EKU, broad Enroll, missing approval, and CA publication can combine into high issuance risk. Whether the certificate maps to and authenticates as an AD principal depends separately on target protocol/KDC policy.

Assumption: The Subject determines identity; SAN is only cosmetic.

In fact: SAN can carry structured identities such as dNSName and UPN-form otherName. Which identity is accepted depends on protocol/configuration and, for AD KDC authentication, current strong-mapping policy; a correct Subject alone is insufficient evidence.

Sources

• Microsoft · Active Directory Certificate Services (AD CS) overview
  The distinction between an Enterprise CA and a standalone CA; AD CS role services and the directory-backed enrollment model.
• Microsoft · Configure the User Certificate Template (Windows Server 2012)
  User certificate template example: Read/Enroll/Autoenroll on Security; AD-sourced Subject Name and UPN; Certificate Template to Issue on the CA. Historical example, not a default claim for every template.
• Microsoft Open Specifications · [MS-WCCE]: Windows Client Certificate Enrollment Protocol
  Enrollment request flow, template reference, and the protocol-level representation of name/extension information carried in the request.
• RFC 5280 · Internet X.509 Public Key Infrastructure Certificate and CRL Profile
  Section 4.2.1.6 subjectAltName and GeneralName forms; Section 4.2.1.12 extended key usage.
• Microsoft · Certificate template concepts
  Only Enterprise CAs issue from AD DS templates; templates define request/issuance rules and assigned permissions.
• Microsoft · Manage certificate templates
  Template publication/removal on each CA and the effect of template changes/deletion. Security considerations: CA-wide EDITF_ATTRIBUTESUBJECTALTNAME2 SAN override, separate from template Supply in the request; investigate dependencies before change.
• Microsoft Support · KB5014754 certificate-based authentication changes on Windows domain controllers
  Strong certificate mapping, SID extension, Full Enforcement timeline, and applicable KDC Event 39/41 guidance.
• Microsoft Open Specifications · [MS-PKCA] Mapping Strength
  Strong versus weak certificate-to-account mapping distinctions.
• Microsoft MS-CRTD · Determining Autoenrollment Permission of an End Entity for a Template
  Current section 2.5.2: CR + ObjectType GUID table, Enroll 0e10c968-78fb-11d2-90d4-00c04f79dc55 and AutoEnroll a05b8cc2-17bc-4802-a710-e7c15ab866a2.