Enrollee Supplies Subject

What this setting actually changes

Enrollee Supplies Subject is a certificate template option that shifts part of certificate identity construction to the requester. In Microsoft AD CS enrolment workflows, that matters because the subject name is not just metadata, it helps determine how the issued certificate represents the holder and how later mappings or trust decisions may behave.

When the setting is enabled, the enrollee can influence the subject field embedded in the request, so the template is no longer relying solely on administrator-defined identity data. That makes the template more flexible, but it also means the issuer must trust the request path and the surrounding validation controls much more carefully.

Why it matters in certificate issuance

This setting is important because certificate subject data can be used by applications, directory mappings, and downstream authentication logic. If weak request handling lets a user supply an unexpected subject, the resulting certificate may appear to represent a different principal than intended, or may be easier to abuse in environments that still rely on subject-based trust decisions.

In practice, the issue is not the template checkbox by itself, but the trust boundary it creates. A certificate template that accepts requester-supplied subject values must be designed with strict enrollment permissions, strong identity validation, and careful review of any fields that influence the certificate’s binding to an account or service.

Common abuse and failure modes

Attackers look for certificate templates that let them influence subject or related name fields because those templates can become an escalation path. In AD CS environments, this often combines with other misconfigurations, such as overly broad enrollment rights, weak manager approval, permissive SAN handling, or certificate mappings that still accept unsafe identity assertions.

The failure mode is usually a mismatch between the real requester and the effective identity encoded in the issued certificate. Once that mismatch exists, the certificate may be usable for impersonation, persistence, or access that was never meant to be delegated to the enrollee.

How to assess and control exposure

Review certificate templates that allow requester-controlled subject data and confirm who can enrol against them, what name fields are accepted, and whether the template is still needed. A secure review should include the CA configuration, template permissions, any directory or application mappings that consume the certificate, and whether the organisation has moved to stronger certificate mapping practices.

Use Microsoft and vendor guidance to validate the exact template behaviour, then compare it with the organisation’s certificate usage model. The AD CS Security Guide is a useful reference for understanding how vulnerable certificate templates fit into broader AD CS abuse paths and hardening work. For control baselines, NIST SP 800-53 Rev 5 Security and Privacy Controls provides a control structure for access control, authentication, auditability, and configuration governance around certificate services.

Risk and Threat Considerations

Certificate templates that accept enrollee-supplied subject data can become privilege-escalation paths when the resulting certificate is trusted for authentication or authorization. The risk increases when certificate mappings, enrollment rights, or approval workflows are weak enough that a requester can shape a certificate into a more powerful identity than intended.

Failure mechanism: The enrollee influences certificate identity fields that are later consumed as evidence of identity, so a poorly constrained template can issue a certificate that binds trust to the wrong subject.

Impact: Successful abuse can enable impersonation, unauthorized authentication, persistence through certificate reuse, and broader compromise of environments that rely on the certificate for trust decisions.

Practitioner Guidance

Why practitioners should care: This setting is not inherently unsafe, but it is a high-trust feature that should be reserved for cases where the issuer can reliably validate requester intent and identity. If the template is used for anything that affects authentication or privileged access, treat it as a control point, not a convenience setting.

What to watch for: Pay special attention to templates that are enrolment-enabled for broad groups, exposed to weak approval flows, or paired with legacy certificate mapping logic. Those combinations are where requester-supplied subject data most often turns into an abuse path.

Related resources from NHI Mgmt Group

• How should teams operationalise data subject requests in modern privacy programmes?
• What breaks when identity programmes cannot map access back to a real subject?
• How should privacy teams automate data subject request handling without losing control?
• How should organisations verify data subject requests without exposing personal data?