Certificate Templates in Active Directory Certificate Services

Certificate templates are one of the most important security components in Active Directory Certificate Services. The simplest way to think about a certificate template is: A certificate template defines what kind of certificate can be issued, who can request it, and what the certificate can be used for.

Templates are useful because they make certificate issuance consistent. Instead of manually configuring every certificate request, administrators can define reusable templates for common needs such as user certificates, computer certificates, web server certificates, smart card logon, Wi-Fi authentication, VPN authentication, and internal application certificates.

That convenience also creates risk. A certificate template with unsafe settings can allow users, computers, or attackers to obtain certificates that should never have been issued to them.

What is a certificate template?

A certificate template is an Active Directory object that stores certificate issuance settings.

It controls things like:

  • Certificate purpose
  • Enrollment permissions
  • Autoenrollment permissions
  • Subject name behavior
  • Subject Alternative Name behavior
  • Extended Key Usage
  • Issuance requirements
  • Approval requirements
  • Private key settings
  • Validity period
  • Renewal period
  • Cryptographic settings
  • Template permissions

When an enterprise certificate authority issues certificates, it can use published templates to determine what kind of certificates are available and who can request them.

Why certificate templates matter

Certificate templates matter because they define certificate trust at scale. A template may look like a simple configuration object, but it can control whether a user or computer can obtain a certificate that is trusted for authentication. If a certificate can be used for authentication, the template becomes part of the identity security model.

A risky template can allow:

  • Low-privilege users to request authentication-capable certificates
  • Requesters to supply identity information
  • Certificates to be issued without approval
  • Private keys to be exported
  • Long-lived certificates to persist after access should have ended
  • Unauthorized users to modify template settings
  • Certificate-based impersonation paths
  • Privilege escalation through AD CS misconfiguration

For defenders, certificate templates should be reviewed with the same seriousness as privileged groups, delegation settings, and domain controller security.

How certificate templates are used

A common certificate issuance flow looks like this:

  1. An administrator creates or duplicates a certificate template.
  2. The template is configured for a specific purpose.
  3. The template is published to an issuing CA.
  4. Users, computers, or services with enrollment rights request certificates.
  5. The CA evaluates the request against the template settings.
  6. If allowed, the CA issues the certificate.

The template does not issue the certificate by itself. The certificate authority issues the certificate. The template defines the rules. That distinction is important. A dangerous template becomes more relevant when it is published to a CA that can issue it.

Published vs unpublished templates

Not every template is actively available for enrollment.

Template stateMeaning
PublishedThe template is available on an issuing CA and can be used for enrollment
UnpublishedThe template exists in Active Directory but is not currently available from that CA

Published templates deserve the most immediate review because they can be used to request certificates. Unpublished templates should still be reviewed because they may be published later, copied, or modified into a risky state. However, a risky setting on an unpublished template is usually less urgent than the same setting on a published template.

What is Extended Key Usage?

Extended Key Usage, often shortened to EKU, defines what a certificate is intended to be used for.

Common EKUs include:

EKUPurpose
Client AuthenticationAllows a certificate to be used for client authentication
Server AuthenticationCommonly used for TLS server certificates
Smart Card LogonUsed for smart card authentication
Code SigningUsed to sign code or scripts
Secure EmailUsed for email signing or encryption
Certificate Request AgentUsed for enrollment agent scenarios
Any PurposeMay allow broad certificate usage depending on context

From a security perspective, authentication-capable EKUs deserve special attention. The important question is, can a certificate from this template be used to authenticate as a user, computer, or service? If the answer is yes, the template should be reviewed carefully.

Authentication-capable templates

Authentication-capable templates are templates that can issue certificates usable for authentication.

These commonly include templates with:

  • Client Authentication
  • Smart Card Logon
  • PKINIT Client Authentication
  • Any Purpose
  • No EKU restriction in some scenarios

These templates are not automatically bad. Many environments legitimately need user, computer, VPN, Wi-Fi, or smart card authentication certificates. The risk comes from how authentication capability combines with other settings.

A template becomes more dangerous when it is authentication-capable and also has:

  • Broad enrollment permissions
  • Requester-supplied subject information
  • Requester-supplied Subject Alternative Name values
  • No approval requirement
  • Weak template ACLs
  • Exportable private keys
  • Long validity periods
  • Broad autoenrollment

That combination can turn a normal PKI feature into an identity compromise path.

Enrollment permissions

Enrollment permissions determine who can request certificates from a template.

Common principals to review include:

Domain Users
Authenticated Users
Domain Computers
Everyone
Large security groups
Help desk groups
Application teams
Service accounts
Non-PKI administrators

Broad enrollment is not always wrong. For example, a basic computer certificate template may intentionally allow domain computers to enroll. The question is whether broad enrollment is appropriate for what the certificate can do.

Autoenrollment permissions

Autoenrollment allows certificates to be automatically requested and renewed based on policy and permissions.

Autoenrollment can be useful for:

  • Computer certificates
  • User certificates
  • Wi-Fi authentication
  • VPN authentication
  • Domain controller certificates
  • Internal TLS certificates

However, autoenrollment also increases the impact of a misconfigured template. If a high-risk template has broad autoenrollment, certificates may be issued widely without users or administrators directly requesting them. Review autoenrollment on templates that support authentication or privileged use cases.

Subject name settings

The subject identifies who or what the certificate represents. Subject name settings are important because they determine whether identity information comes from Active Directory or from the requester.

A safer model is usually: Build subject information from Active Directory.

A riskier model is: Allow the requester to supply subject information.

Requester-supplied subject information can be legitimate in some web server or application certificate workflows. It is much more dangerous when combined with authentication-capable certificates and broad enrollment permissions.

Subject Alternative Name risk

Subject Alternative Name, often shortened to SAN, allows additional names or identities to be included in a certificate. SAN values may include DNS names, user principal names, email addresses, or other identity-related values depending on the template and request. SAN control is important because attackers may try to request a certificate containing identity information for another account.

A high-risk combination is:

  • The template can be used for authentication.
  • The requester can supply subject or SAN values.
  • Low-privilege users can enroll.
  • No approval is required.

This is the kind of combination defenders should prioritize.

Issuance requirements

Issuance requirements add controls before a certificate can be issued.

Examples include:

  • Manager approval
  • Authorized signatures
  • Enrollment agent requirements

These controls can reduce risk for sensitive templates, but they only help if they are configured and operated correctly. Review whether sensitive templates require approval or additional authorization. Also review who can approve requests and whether approval activity is monitored.

Private key settings

Private key settings determine how the private key is generated, protected, and handled.

High-risk private key settings include:

  • Allowing private key export
  • Weak cryptographic settings
  • Long key reuse
  • Poor key protection
  • Insecure storage of exported keys

Exportable private keys can make certificate theft and reuse easier. They may be needed for some workloads, but they should not be allowed casually on authentication-capable templates.

Validity and renewal periods

Certificate templates define how long certificates are valid and how renewal works. Long validity periods increase the window of exposure if a certificate is not issued correctly, stolen, or no longer appropriate.

Review:

  • Validity period
  • Renewal period
  • Whether reapproval is required
  • Whether old certificates remain usable
  • Whether revocation is effective
  • Whether certificate owners are still valid

Long-lived authentication certificates deserve special attention because they may continue working after password resets, account changes, or role changes.

Template permissions

Certificate templates are Active Directory objects with access control lists. Template permissions control who can read, enroll, autoenroll, modify, take ownership, or change permissions on the template.

High-risk permissions include:

GenericAll
GenericWrite
WriteDacl
WriteOwner
WriteProperty
Full Control

A user who can modify a certificate template may be able to change it into a dangerous configuration.

For example, an attacker with write access to a template might be able to change enrollment settings, add authentication EKUs, change subject name behavior, or weaken issuance requirements.

Common risky combinations

Certificate template risk usually comes from combinations of settings, not one setting by itself.

Risky combinationWhy it matters
Client Authentication plus broad enrollmentMany users or computers may be able to obtain authentication certificates
Requester-supplied subject plus authentication EKURequesters may influence the identity represented in the certificate
Broad enrollment plus no approvalCertificates may be issued without human review
Weak template ACL plus published templateA user may be able to modify a live template into a dangerous state
Exportable private key plus authentication certificateThe certificate may be easier to steal and reuse
Any Purpose EKU plus broad enrollmentThe certificate may be usable in more scenarios than intended
Long validity plus authentication useMisissued or stolen certificates may remain useful longer

The more of these conditions that exist together, the higher the priority.

PowerShell: Find certificate templates

Certificate templates are stored in the Configuration partition.

$ConfigNC = (Get-ADRootDSE).configurationNamingContext

Get-ADObject `
  -SearchBase "CN=Certificate Templates,CN=Public Key Services,CN=Services,$ConfigNC" `
  -LDAPFilter "(objectClass=pKICertificateTemplate)" `
  -Properties displayName, pKIExtendedKeyUsage, msPKI-Certificate-Name-Flag, msPKI-Enrollment-Flag |
  Select-Object Name, displayName, pKIExtendedKeyUsage, msPKI-Certificate-Name-Flag, msPKI-Enrollment-Flag

This gives you a starting inventory of certificate templates.

PowerShell: Find published templates

Published templates are associated with enterprise CAs.

$ConfigNC = (Get-ADRootDSE).configurationNamingContext

Get-ADObject `
  -SearchBase "CN=Enrollment Services,CN=Public Key Services,CN=Services,$ConfigNC" `
  -LDAPFilter "(objectClass=pKIEnrollmentService)" `
  -Properties dNSHostName, certificateTemplates |
  Select-Object Name, dNSHostName, certificateTemplates

Focus first on templates listed under active issuing CAs.

PowerShell: Find templates with Client Authentication EKU

Client Authentication is one of the most important EKUs to review.

$ConfigNC = (Get-ADRootDSE).configurationNamingContext
$ClientAuthEku = "1.3.6.1.5.5.7.3.2"

Get-ADObject `
  -SearchBase "CN=Certificate Templates,CN=Public Key Services,CN=Services,$ConfigNC" `
  -LDAPFilter "(objectClass=pKICertificateTemplate)" `
  -Properties displayName, pKIExtendedKeyUsage |
  Where-Object { $_.pKIExtendedKeyUsage -contains $ClientAuthEku } |
  Select-Object Name, displayName, pKIExtendedKeyUsage

This is not automatically a list of vulnerable templates. It is a list of templates that deserve review.

PowerShell: Review template ACLs

Use this to review permissions on a specific certificate template.

$ConfigNC = (Get-ADRootDSE).configurationNamingContext
$TemplateName = "TemplateName"
$TemplateDn = "CN=$TemplateName,CN=Certificate Templates,CN=Public Key Services,CN=Services,$ConfigNC"

Get-Acl "AD:\$TemplateDn" |
  Select-Object -ExpandProperty Access |
  Select-Object IdentityReference, ActiveDirectoryRights, AccessControlType, IsInherited

Look carefully for unexpected write, owner, or permission modification rights.

PowerShell: Identify potentially sensitive template flags

Template name flags can help identify templates where subject information may be supplied or built in specific ways.

$ConfigNC = (Get-ADRootDSE).configurationNamingContext

Get-ADObject `
  -SearchBase "CN=Certificate Templates,CN=Public Key Services,CN=Services,$ConfigNC" `
  -LDAPFilter "(objectClass=pKICertificateTemplate)" `
  -Properties displayName, msPKI-Certificate-Name-Flag |
  Select-Object Name, displayName, msPKI-Certificate-Name-Flag

These values often require interpretation. Treat the output as a starting point for deeper template review.

GUI: Review certificate templates

Open the Certificate Templates console (certtmpl.msc) and review high-impact templates for:

  • Template purpose
  • Compatibility settings
  • Request handling
  • Cryptography settings
  • Subject name behavior
  • Issuance requirements
  • Security permissions
  • Application policies
  • Extensions
  • Validity period
  • Renewal period

Start with templates that can be used for authentication.

GUI: Review templates published on a CA

Open the Certification Authority console (certsrv.msc), then review:

Certification Authority
  CA Name
    Certificate Templates

This shows templates currently available from that CA. A dangerous template that is not published may still be worth fixing, but a dangerous template that is published should usually be prioritized.

What defenders should review first

Start with templates that meet one or more of these conditions:

  • Published to an issuing CA
  • Supports client authentication
  • Supports smart card logon
  • Supports Any Purpose
  • Has no EKU restriction
  • Allows the requester to supply subject information
  • Allows the requester to supply SAN values
  • Allows broad enrollment
  • Allows broad autoenrollment
  • Allows private key export
  • Has weak template ACLs
  • Has long validity periods
  • Lacks approval for sensitive use cases

This review should produce a short list of templates that deserve immediate attention.

How to safely fix risky templates

Template remediation should be careful because certificates may support business-critical services.

A safe approach is:

  1. Identify the risky condition.
  2. Confirm whether the template is published.
  3. Determine who uses the template.
  4. Identify certificate owners and dependent systems.
  5. Decide whether the template should be disabled, restricted, replaced, or redesigned.
  6. Test changes in a safe environment.
  7. Update enrollment permissions.
  8. Remove unnecessary authentication EKUs.
  9. Disable requester-supplied identity fields unless required.
  10. Add approval requirements for sensitive templates.
  11. Remove weak ACLs.
  12. Monitor certificate issuance after changes.

Avoid making broad template changes without understanding dependencies.

Detection opportunities

Defenders should monitor both template changes and certificate issuance.

Useful monitoring areas include:

  • New certificate templates
  • Certificate template modifications
  • Template permission changes
  • Templates published or removed from CAs
  • Certificate issuance from authentication-capable templates
  • Certificate requests involving privileged identities
  • Certificate requests from unusual systems
  • Failed or denied certificate requests
  • Enrollment agent activity
  • Changes to certificate mapping attributes

Certificate templates do not usually change often. That makes changes worth reviewing.

Common mistakes

Treating all templates the same

A web server template and an authentication-capable user template do not carry the same risk. Focus first on templates that can be used for authentication.

Only reviewing template names

Template names can be misleading. Review EKUs, subject name settings, enrollment permissions, and ACLs.

Ignoring published status

A risky template published to an issuing CA is more urgent than a risky template that is not currently available for enrollment.

Allowing broad enrollment on powerful templates

Broad enrollment may be fine for low-impact templates, but it is dangerous when certificates can be used for authentication or impersonation.

Forgetting template ACLs

Even if a template is currently safe, weak ACLs may allow someone to modify it into a dangerous state.

Allowing private key export by default

Exportable private keys should be justified, especially for certificates used for authentication.

Leaving old templates published

Old templates often remain available long after the original project or application no longer needs them.

Practical recommendation

A practical certificate template review should include:

  1. Inventory all certificate templates.
  2. Identify templates published to issuing CAs.
  3. Identify authentication-capable templates.
  4. Review enrollment and autoenrollment permissions.
  5. Review subject and SAN control.
  6. Review Any Purpose and no-EKU templates.
  7. Review private key export settings.
  8. Review validity periods.
  9. Review issuance requirements.
  10. Review template ACLs.
  11. Remove unused templates from issuing CAs.
  12. Restrict high-impact templates to appropriate users and systems.
  13. Monitor template changes and certificate issuance.

Start with templates that are both published and authentication-capable. Those are usually the most important.

Summary

Certificate templates are a core part of Active Directory Certificate Services. They define what certificates can be issued, who can request them, and how those certificates can be used. From a security perspective, templates are important because certificates can act as credentials. A risky template can allow unauthorized certificate issuance, impersonation, relay-assisted compromise, or long-term access.

Defenders should focus on published templates, authentication-capable templates, enrollment permissions, subject and SAN control, private key export, template ACLs, and certificate issuance monitoring. A well-managed AD CS environment depends on certificate templates that are controlled, documented, justified, and regularly reviewed.

References

Scroll to Top