Certificate auto-enrollment is one of those AD CS features that’s easy to configure and surprisingly easy to configure badly. The Group Policy side takes five minutes. The certificate template is where the real decisions are made: what the certificate can be used for, what identity goes into it, and who is allowed to request it. A poorly built template can create a security problem just as easily as a well-built one solves an operational one.
This guide covers template configuration, Group Policy, testing, troubleshooting, and the template security issues worth checking before you roll autoenrolment out broadly.
What autoenrolment actually does
Autoenrolment lets Windows users and computers request certificates from an Enterprise CA automatically, provided they meet the conditions set by a certificate template and Group Policy. It handles initial enrolment, renewal before expiry, updating certificates when a template changes, removing revoked certificates, and re-enrolling when a certificate is missing. The client runs this at startup or logon, at Group Policy refresh, and periodically after that.
One thing it doesn’t do is recover a lost private key. If the private key behind an encryption certificate is lost, issuing a new certificate won’t decrypt anything encrypted with the old one. Recovery needs key archival and a Key Recovery Agent configured on the CA, which is a separate AD CS feature. Decide which templates need archival before you deploy them, not after someone loses a key.
A practical use case: 802.1X with NPS
Certificate-based network authentication is a good example of where autoenrolment earns its keep. In an 802.1X deployment using NPS and EAP-TLS, clients need a certificate with the Client Authentication application policy and the right identity (the DNS name for computers, the UPN for users), and the NPS server needs a certificate with Server Authentication. Microsoft’s guide to configuring auto-enrollment of certificates for NPS walks through the server side.
Without autoenrolment, that’s a manual certificate request on every device and a renewal problem every year. With it, the certificate becomes part of the normal Windows lifecycle and part of the infrastructure supporting the service.
Prerequisites
An Enterprise CA. Certificate templates and AD-based autoenrolment only work with an Enterprise CA. A standalone CA doesn’t use templates at all.
The right permissions. Creating and modifying templates requires Enterprise Admins or delegated rights on the certificate templates container in AD. Configuring the GPO only needs rights to edit and link that GPO. These are separate permission boundaries, and it’s worth keeping them that way.
A clear requirement. Start with what the certificate is for, then build the template around it. Don’t create a template and then work out who should get it.
Create the certificate template
In the Certification Authority console, right-click Certificate Templates and select Manage. Duplicate a template close to what you need rather than modifying a built-in one, and give it a name that describes its purpose, such as 802.1X Computer Authentication.
General
Set the validity and renewal periods based on the certificate’s purpose and the risk if its private key is compromised, not on a default that sounds sensible. The renewal period needs to give autoenrolment enough time to get a replacement before the current certificate expires, including for devices that are off the network for a while.
Compatibility
These settings control the minimum CA and client versions the template supports. Set them for the oldest systems that actually need the certificate. Raising them without checking your estate can stop older devices from enrolling.
Subject Name
This is one of the most important tabs. For a normal domain computer or user certificate, select Build from this Active Directory information and choose the subject and SAN details the service needs, such as the DNS name for computers or the UPN for users.
Don’t select Supply in the request just because it’s more flexible. On an authentication template, it lets the requester choose whose identity goes in the certificate, which is the basis of the ESC1 attack covered below.
Extensions
Application policies (EKUs) such as Client Authentication and Server Authentication are set on the Extensions tab, not Request Handling. Request Handling covers the key’s purpose, key archival and whether the private key can be exported.
Include only the application policies the certificate needs. A template that covers several unrelated authentication purposes has a bigger blast radius if it’s misused. While you’re here, leave private key export disabled unless an application genuinely requires it.
Security
Grant the target group Read, Enroll and Autoenroll. All three are needed, and they’re separate permissions. Where only some machines need the certificate, create a dedicated group (for example 802.1X Computer Certificates) rather than granting Domain Computers or Domain Users. A certificate that supports authentication is effectively a credential, so scope it like one.
Superseded Templates
If you’re replacing an existing template, for example because it has a weak key size, a wrong EKU or overly broad permissions, add the old template on the new template’s Superseded Templates tab. Clients will then enrol from the new template and replace the old certificate.
Superseding a template doesn’t revoke the certificates already issued from it. They stay valid until they expire. If the old template was vulnerable, revoke its certificates on the CA, then unpublish the old template.
Publish the template on the CA
Close the templates console, return to the Certification Authority console, right-click Certificate Templates and select New > Certificate Template to Issue, then choose your template.
Creating a template and publishing it are two separate steps. A template can exist in AD without being available from the CA your clients use, and this is a common reason for “nothing happens” after the GPO is in place.
Configure autoenrolment with Group Policy
Create a dedicated GPO linked to the OU containing the target computers or users. Putting autoenrolment in the Default Domain Policy works, but a dedicated GPO is easier to understand, scope and troubleshoot later.
For computer certificates, go to:
Computer Configuration > Policies > Windows Settings > Security Settings > Public Key Policies
Open Certificate Services Client – Auto-Enrollment, set Configuration Model to Enabled, and tick both:
- Renew expired certificates, update pending certificates, and remove revoked certificates
- Update certificates that use certificate templates
For user certificates, configure the same setting under User Configuration > Policies > Windows Settings > Security Settings > Public Key Policies.
Trigger and verify
To test without waiting for the next cycle, refresh Group Policy and then trigger the autoenrolment engine directly:
gpupdate /force
certutil -pulseFor user certificates, run certutil -pulse -user in the user’s session.
To check the result, open certlm.msc for computer certificates or certmgr.msc for user certificates and look under Personal > Certificates. Check more than the expiry date: confirm the issuer, subject, SAN, Enhanced Key Usage, validity period, that a private key is present, and that the certification path is trusted.
From the command line, certutil -store my shows the computer store and certutil -user -store my shows the current user’s store. Without -user, you’re looking at the computer.
Troubleshooting
When no certificate appears, work through the dependency chain in order rather than changing the GPO straight away:
Template configured and permissions set
-> Template published on the Enterprise CA
-> GPO applies to the user or computer
-> Group membership is current
-> Autoenrolment runs and submits the request
-> CA issues the certificate
-> Certificate appears in the correct storeRunning gpupdate /force repeatedly won’t help if the template isn’t published or the computer lacks Enroll and Autoenroll.
Confirm the GPO applies. From an elevated prompt, run gpresult /r /scope computer (or /scope user for user certificates). Without elevation, computer settings aren’t shown. For a full report, use gpresult /h C:\Temp\gpresult.html.
Check permissions and publication. Confirm the target group has Read, Enroll and Autoenroll on the template, and that the template appears under Certificate Templates in the CA console.
Check group membership. This one catches people out. If you’ve just added a computer to the group that has enrol rights, the computer won’t see the new membership until it gets a new Kerberos ticket. Reboot it, or purge the computer account’s tickets from an elevated prompt:
klist -li 0x3e7 purgeIf the template looks right but the computer behaves as if it isn’t in the group, this is usually why.
Check the event log. Start with Windows Logs > Application and filter on the source CertificateServicesClient-AutoEnrollment. These events show whether the engine attempted a request and why it failed. There are additional CertificateServicesClient logs under Applications and Services Logs > Microsoft > Windows, but the Application log is the place to start.
Template security: ESC1 and why it matters
Misconfigured certificate templates are a well-documented Active Directory attack path. SpecterOps’ Certified Pre-Owned research catalogued a series of AD CS escalation techniques, and the first, ESC1, is still the one most worth checking for.
A template is vulnerable to ESC1 when all of these are true:
- Low-privileged users (such as Domain Users) have enrolment rights
- The template allows the requester to supply the subject or SAN (Supply in the request)
- The template includes an EKU that allows authentication: Client Authentication, PKINIT Client Authentication, Smart Card Logon, Any Purpose, or no EKU at all
- CA certificate manager approval isn’t required
When all of those line up, any user who can enrol can request a certificate in the name of a Domain Admin and authenticate as them. The ASD’s ACSC covers this in its Detecting and mitigating Active Directory compromises guidance. It recommends removing the enrolee-supplies-subject setting from client authentication templates and names PSPKIAudit and Certify as tools for identifying vulnerable configurations. The current version, Certify 2.0, covers the newer ESC techniques as well.
When reviewing templates, go through each published one and check three things:
- Subject Name: if it says Supply in the request, find out why. There are legitimate uses (such as some web server workflows with manager approval), but it shouldn’t appear on a general workstation or user authentication template.
- Extensions: if the template allows any of the authentication EKUs above, treat the certificate as a credential.
- Security: check who has Enroll, Autoenroll, Full Control or Write. Write access to a template lets someone reconfigure it, which is its own escalation path.
Creating a new, secure template doesn’t make an old vulnerable one go away. If it’s still published and still grants enrolment rights, it’s still part of the attack surface. Template review belongs in regular AD security assessments, not just the original PKI build.
Strong certificate mapping (KB5014754)
Certificate-based authentication to Active Directory now requires strong certificate mapping. Under KB5014754, domain controllers moved to Full Enforcement mode with the February 2025 security update, and the ability to fall back to Compatibility mode was removed with the September 2025 update.
For autoenrolment, the practical impact is that certificates issued online from a patched Enterprise CA using a template built from AD information include the SID extension, which gives a strong mapping. Certificates that don’t meet the strong mapping criteria are denied, so if authentication fails after you’ve issued certificates, check the KB’s requirements and look for Kdcsvc event 39 in the System log on your domain controllers.
Auditing what the CA has issued
The CA database shows what has actually been issued. On the CA (or with -config from another machine), this lists issued certificates:
certutil -view -restrict "Disposition=20" -out "RequestID,RequesterName,CertificateTemplate,NotAfter"Disposition=20 means issued, and -out limits the output to the columns you care about. On a busy CA the output is still large, so redirect it to a file (> C:\Temp\issued.txt) and filter from there. This gives you an audit view of issuance. On its own, it isn’t a compliance report.
Get the template right, then automate it
Autoenrolment is only one part of the certificate lifecycle. You still need to look after CA availability and backups, CRL and OCSP availability, key archival where it’s needed, monitoring for expiry and failed enrolments, cleaning up obsolete templates, and controlling who administers the CA.
The GPO is the easy part. The important work is designing a template that contains the identity the service needs, the application policies it needs and nothing more, with enrolment rights limited to the users or machines that need it. An autoenrolment setup that saves administrators time but lets a large group obtain powerful authentication certificates isn’t a good trade.
From my early days on the helpdesk through roles as a service desk manager, systems administrator, and network engineer, I’ve spent more than 25 years in the IT world. As I transition into cyber security, my goal is to make tech a little less confusing by sharing what I’ve learned and helping others wherever I can.