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:
- An administrator creates or duplicates a certificate template.
- The template is configured for a specific purpose.
- The template is published to an issuing CA.
- Users, computers, or services with enrollment rights request certificates.
- The CA evaluates the request against the template settings.
- 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 state | Meaning |
|---|---|
| Published | The template is available on an issuing CA and can be used for enrollment |
| Unpublished | The 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:
| EKU | Purpose |
|---|---|
| Client Authentication | Allows a certificate to be used for client authentication |
| Server Authentication | Commonly used for TLS server certificates |
| Smart Card Logon | Used for smart card authentication |
| Code Signing | Used to sign code or scripts |
| Secure Email | Used for email signing or encryption |
| Certificate Request Agent | Used for enrollment agent scenarios |
| Any Purpose | May 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 combination | Why it matters |
|---|---|
| Client Authentication plus broad enrollment | Many users or computers may be able to obtain authentication certificates |
| Requester-supplied subject plus authentication EKU | Requesters may influence the identity represented in the certificate |
| Broad enrollment plus no approval | Certificates may be issued without human review |
| Weak template ACL plus published template | A user may be able to modify a live template into a dangerous state |
| Exportable private key plus authentication certificate | The certificate may be easier to steal and reuse |
| Any Purpose EKU plus broad enrollment | The certificate may be usable in more scenarios than intended |
| Long validity plus authentication use | Misissued 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:
- Identify the risky condition.
- Confirm whether the template is published.
- Determine who uses the template.
- Identify certificate owners and dependent systems.
- Decide whether the template should be disabled, restricted, replaced, or redesigned.
- Test changes in a safe environment.
- Update enrollment permissions.
- Remove unnecessary authentication EKUs.
- Disable requester-supplied identity fields unless required.
- Add approval requirements for sensitive templates.
- Remove weak ACLs.
- 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:
- Inventory all certificate templates.
- Identify templates published to issuing CAs.
- Identify authentication-capable templates.
- Review enrollment and autoenrollment permissions.
- Review subject and SAN control.
- Review Any Purpose and no-EKU templates.
- Review private key export settings.
- Review validity periods.
- Review issuance requirements.
- Review template ACLs.
- Remove unused templates from issuing CAs.
- Restrict high-impact templates to appropriate users and systems.
- 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
- Microsoft Learn: Certificate template concepts in Windows Server
- Microsoft Learn: Manage certificate templates in Windows Server
- Microsoft Learn: Defender for Identity certificate security posture assessments
- Microsoft Support: KB5005413, Mitigating NTLM Relay Attacks on Active Directory Certificate Services