Certificate Autoenrollment Not Working: A Read-First GPO, Template Permission, CA, and DCOM Triage

Helpdesk: "The new 802.1X Wi-Fi needs a computer certificate on every laptop. About half of the Finance laptops got one this week; the rest show nothing in the Personal store. The PKI admin duplicated the Workstation Authentication template on Monday and says the CA is up. Event Viewer on one laptop says automatic certificate enrollment for local system failed, the RPC server is unavailable. A blog post says to give Domain Computers Full Control on the template, add Authenticated Users to the CA's local Administrators group, and run certreq on every laptop. Can we start with the permissions?"

Not yet. Autoenrollment isn't one setting. It's a chain that runs on the client: policy says enroll, the client finds a template it's allowed to autoenroll, finds an enterprise CA that publishes that template, reaches the CA over RPC/DCOM, and the CA issues instead of denying or pending the request. Microsoft on when it runs: "Windows triggers automatic certificate enrollment for the computer during boot, and when Group Policy updates." And on what the identity needs: "User or computer has Read, Enroll, and Autoenroll permissions on the certificate template being requested." Full Control on a template and local admin on the CA skip past the link that failed and leave a wider permission behind. Work through it as a chain: which identity (user or computer), which template, since when → is autoenrollment policy actually applied on the client? → the CertificateServicesClient events and their error codes → the template: version, Read / Enroll / Autoenroll for that identity, and its flags → is the template published on an enterprise CA the client can see? → can the client reach the CA: DC, port 135, the RPC range, CertSvc? → DCOM and access on the CA (0x800706ba that's really access denied) → did the request reach the CA and get denied or left pending? → chain, revocation, and renewal timing → domain controller certificates, which follow their own rules. gpresult, Get-CertificateAutoEnrollmentPolicy, Get-WinEvent, certutil, Get-ADObject, Get-Acl, and Get-LocalGroupMember are the sources for that chain. Run certreq on every laptop with the same broken link, and every laptop fails the same way.

If the devices are Intune-managed and get certificates through a SCEP profile and NDES instead of Group Policy, read Intune SCEP Certificate Profile Failed first. That's a different enrollment path. If no Group Policy is landing on the client at all, start with Group Policy Not Applying. This post covers "Domain-joined users or computers don't get (or don't renew) a certificate from an AD CS enterprise CA through Group Policy autoenrollment, and you need a read-first path before you widen template permissions, change DCOM on the CA, or enroll by hand."

TL;DR

• Prove the policy landed first. Get-CertificateAutoEnrollmentPolicy -Scope Applied and the AEPolicy registry value show whether autoenrollment is on for that context (Step 2).
• Read the AutoEnrollment events before you change anything. Microsoft: "By default, autoenrollment logs errors/failures and successful enrollments in the Application event log on the client machine." The error code in the event names the link: 0x8007054b is getting to a DC, 0x800706ba is getting to the CA, 0x80094800 is the template on the CA.
• The template needs three rights, and the CA needs one. The identity needs Read, Enroll, and Autoenroll. The CA's computer account needs Read: if Authenticated Users is removed, Microsoft says "the (enterprise) CA itself can no longer read the template in the Active Directory."
• A template does nothing until a CA publishes it. Microsoft: superseding "isn't active until the template is published to one or more certificate authorities." certutil -TemplateCAs lists which CAs offer it.
• 0x800706ba isn't always the network. Microsoft's article for it lists six causes, and most are access on the CA: the Certificate Service DCOM Access group, network logon rights, EnableDCOM, and the COM Security limits (Step 7).
• Domain controllers are a special case. They request the old Domain Controller template on their own; newer templates need an autoenrollment GPO on the Domain Controllers OU (Step 10).

Where in the chain did it break?

Step 1: Capture the symptom (read-only)

Write these on the ticket first:

Then branch on what you see:

Step 2: Is autoenrollment policy applied on the client? (read-only)

The GPO setting is Certificate Services Client - Auto-Enrollment, under Public Key Policies, in either Computer Configuration (computer certificates) or User Configuration (user certificates). Microsoft's configuration sets Configuration Model to Enabled and selects both Renew expired certificates, update pending certificates, and remove revoked certificates and Update certificates that use certificate templates. Read what actually applied, on the failing client:

:: Read-only. Elevated, on the client: computer-side RSoP to a file (run without /scope computer, as the user, for the user side)
gpresult /scope computer /h C:\Temp\gpresult-computer.html

# Read-only. The applied autoenrollment policy for the computer (elevated) and for the signed-in user (not elevated)
Get-CertificateAutoEnrollmentPolicy -Scope Applied -Context Machine
Get-CertificateAutoEnrollmentPolicy -Scope Applied -Context User

Microsoft on -Scope: "If Applied scope is specified, then the currently applied policy which can be either the local policy or a domain policy, is returned." The fields to read are PolicyState, EnableMyStoreManagement (the renew / update pending / remove revoked box), and EnableTemplateCheck (the update-certificates-that-use-templates box).

Microsoft's lower-level check is the registry. Its troubleshooting page warns that RSoP isn't the last word: "Rsop results will only show what was pushed by GPOs, not what actually was applied." So read AEPolicy in all four places it names:

# Read-only. AEPolicy in the policy keys (GPO) and the non-policy keys (local), HKLM = computer, HKCU = current user
'HKLM:\SOFTWARE\Policies\Microsoft\Cryptography\AutoEnrollment',
'HKCU:\SOFTWARE\Policies\Microsoft\Cryptography\AutoEnrollment',
'HKLM:\SOFTWARE\Microsoft\Cryptography\AutoEnrollment',
'HKCU:\SOFTWARE\Microsoft\Cryptography\AutoEnrollment' | ForEach-Object {
  [pscustomobject]@{ Key = $_; AEPolicy = (Get-ItemProperty -Path $_ -ErrorAction SilentlyContinue).AEPolicy }
}

Microsoft's wiki: "If none of these keys have AEPolicy = 7, Autoenrollment is not turned on." Its older troubleshooting blog adds the other value worth knowing: AEPolicy set to 0x00008000 means autoenrollment is disabled outright (0x00008000==AUTO_ENROLLMENT_DISABLE_ALL). Check HKCU while signed in as the affected user, not as an admin in another session (our reading).

Step 3: Read the CertificateServicesClient events (read-only, then one logging switch)

Autoenrollment writes to the Application log. Read every CertificateServicesClient provider at once, so you don't have to guess provider names:

# Read-only. Last 7 days of CertificateServicesClient events in the Application log (the provider-name filter is our form)
Get-WinEvent -FilterHashtable @{ LogName = 'Application'; StartTime = (Get-Date).AddDays(-7) } -ErrorAction SilentlyContinue |
  Where-Object ProviderName -like '*CertificateServicesClient*' |
  Select-Object TimeCreated, ProviderName, Id, LevelDisplayName, Message | Format-List

# Read-only. The certificate lifecycle channels on this OS (names vary by version; list them first)
Get-WinEvent -ListLog '*CertificateServices*' -ErrorAction SilentlyContinue |
  Select-Object LogName, RecordCount, IsEnabled

The events and what they point at:

Common codes in Event 6 and 13, each from the Microsoft page named:

Turn up the logging while you test. By default only errors and successful enrollments are logged. Microsoft's two troubleshooting pages give the same switch: create a DWORD AEEventLogLevel set to 0 under Software\Microsoft\Cryptography\AutoEnrollment, in HKLM for the computer and HKCU for the user. That's one small registry write; the dry run first:

# Low-risk write. Verbose autoenrollment logging for the computer context (dry-run first; remove it after the test, Step 11)
New-ItemProperty -Path 'HKLM:\SOFTWARE\Microsoft\Cryptography\AutoEnrollment' -Name AEEventLogLevel -PropertyType DWord -Value 0 -WhatIf

Microsoft's wiki on what a healthy run looks like after gpupdate /force: "Two computer autoenrollment messages (start, stop) should occur first, followed by two user autoenrollment messages (start, stop)", within about two minutes. Then trigger one run on demand. certutil -pulse "Pulses an autoenrollment event or NGC task." It enrolls if anything is due, the same work the scheduled run does (our note):

:: Read-mostly. Trigger autoenrollment now: computer context (elevated), then user context (as the user, not elevated)
certutil -pulse
certutil -user -pulse

Step 4: The template: version, rights, and flags (read-only)

Three things on the template decide whether a client even tries. Start with what the client can see. Microsoft's wiki: run certutil -Template "when logged in as the end-user to see if the end-user has Read and Enroll permissions (but it will not reveal which certs the user has Autoenroll permissions to)". For computer templates, run it elevated without -user:

:: Read-only. Templates the current user can see through enrollment policy (run as the affected user)
certutil -user -Template > C:\Temp\templates-user.txt

:: Read-only. Elevated: the computer's view, then the AD attributes of one template (WorkstationAuth-Contoso is an example name)
certutil -Template > C:\Temp\templates-machine.txt
certutil -dsTemplate WorkstationAuth-Contoso > C:\Temp\dstemplate.txt

Version. Microsoft's template concepts page: version 1 templates support autoenrollment only in a narrow case. "Automatic enrollment is only supported for custom scripts and through group policy if using computer certificates." And: "Version 2 templates provide support for certificate autoenrollment." The default User template is version 1, so user autoenrollment needs a duplicate (our reading of Microsoft's default template table).

Rights. The identity needs Read, Enroll, and Autoenroll. Enroll and Autoenroll are extended rights on the template object. Microsoft's schema pages give their GUIDs: Enroll (Certificate-Enrollment) is 0e10c968-78fb-11d2-90d4-00c04f79dc55, and Certificate-AutoEnrollment is a05b8cc2-17bc-4802-a710-e7c15ab866a2. Read them from the template's ACL with the ActiveDirectory module:

# Read-only. Template attributes and the Enroll / Autoenroll ACEs (template CN is an example; the AD: drive form is ours)
Import-Module ActiveDirectory
$config   = (Get-ADRootDSE).configurationNamingContext
$template = "CN=WorkstationAuth-Contoso,CN=Certificate Templates,CN=Public Key Services,CN=Services,$config"

Get-ADObject -Identity $template -Properties displayName, 'msPKI-Template-Schema-Version', 'msPKI-Enrollment-Flag', flags |
  Select-Object Name, displayName, 'msPKI-Template-Schema-Version', 'msPKI-Enrollment-Flag', flags

$rights = @{ '0e10c968-78fb-11d2-90d4-00c04f79dc55' = 'Enroll'; 'a05b8cc2-17bc-4802-a710-e7c15ab866a2' = 'Autoenroll' }
(Get-Acl -Path "AD:\$template").Access |
  Where-Object { $rights.ContainsKey($_.ObjectType.ToString()) -or $_.ActiveDirectoryRights -match 'GenericRead|GenericAll' } |
  Select-Object IdentityReference, AccessControlType, ActiveDirectoryRights, @{ n = 'ExtendedRight'; e = { $rights[$_.ObjectType.ToString()] } }

Then check that the failing identity is actually in the group that holds Autoenroll:

# Read-only. The computer's groups in AD (LAPTOP17 is an example), and the signed-in user's token on the client
Get-ADComputer -Identity LAPTOP17 | Get-ADPrincipalGroupMembership | Select-Object Name
whoami /groups

A computer added to a group yesterday may not have that group in its token yet. The token is built at startup, so AD membership and token membership can disagree until a restart or a purge of the computer's tickets (our reading; Step 11 has the klist form).

The CA's own Read. Microsoft KB 283218: "The Authenticated Users group is on a template ACL, by default. (The Certification Authority object itself is included in this group.)" And: "If the Authenticated Users group is removed, the (enterprise) CA itself can no longer read the template in the Active Directory, and that's why certificate requests can be unsuccessful." Its minimums: "Requesting user/machine: Read & Enroll, Certification Authority Object: Read". Autoenrollment adds Autoenroll for the requester.

Flags. Microsoft's template protocol spec defines the bits in msPKI-Enrollment-Flag. The ones that change autoenrollment:

# Read-only. Decode the enrollment flags on the template read above (bit values from MS-CRTD; the test form is ours)
$t = Get-ADObject -Identity $template -Properties 'msPKI-Enrollment-Flag'
$f = [int]$t.'msPKI-Enrollment-Flag'
[pscustomobject]@{
  PendAllRequests          = [bool]($f -band 0x2)
  CheckUserDsCertificate   = [bool]($f -band 0x10)
  AutoEnrollmentFlag       = [bool]($f -band 0x20)
  SkipAutoRenewal          = [bool]($f -band 0x40000)
}

Step 5: Is the template published on an enterprise CA? (read-only)

Microsoft: "Only an enterprise CA can issue certificates based on a certificate template." Creating or duplicating a template doesn't offer it; a CA has to issue it. Microsoft's Windows Hello for Business guide says it about supersedence too: "However, the certificate template and the superseding of certificate templates isn't active until the template is published to one or more certificate authorities."

:: Read-only. Which CAs publish this template (WorkstationAuth-Contoso is an example)
certutil -TemplateCAs WorkstationAuth-Contoso

:: Read-only. Every template one CA publishes ("CA01.contoso.com\Contoso Issuing CA" is an example config string)
certutil -CATemplates -config "CA01.contoso.com\Contoso Issuing CA"

Microsoft's descriptions: -TemplateCAs "Displays the certification authorities (CAs) for a certificate template." -CATemplates "Displays templates for the Certificate Authority." The client reads the same list from AD, from the Enrollment Services container. Microsoft's blog points there for 0x800706ba too: "Check network connectivity to all of the available certification authorities listed in the Enrollment Services object". Read it:

# Read-only. Enterprise CAs registered in AD, their host names, and the templates each one publishes
$config = (Get-ADRootDSE).configurationNamingContext
Get-ADObject -SearchBase "CN=Enrollment Services,CN=Public Key Services,CN=Services,$config" `
  -Filter "objectClass -eq 'pKIEnrollmentService'" -Properties dNSHostName, certificateTemplates |
  Select-Object Name, dNSHostName, @{ n = 'Templates'; e = { $_.certificateTemplates -join ', ' } }

certificateTemplates is an attribute of Microsoft's pKIEnrollmentService schema class. An entry for a CA that no longer exists is a CA the client may still try (our reading; Microsoft's decommission article covers removing it).

Microsoft's wiki also lists a setup check here: the issuing CA's computer account is in the domain's Cert Publishers group.

Step 6: Can the client reach a DC and the CA? (read-only)

The DC first. Event 15 with 0x8007054b means the client didn't get as far as the CA. Microsoft's blog: the cause is "problems getting to a DC in the domain, common cause is name resolution." That's the same DC locator path as Netlogon Event ID 5719, which covers it from the client side. A laptop that booted off the network and signed in with cached credentials fits Microsoft's 0x80072751 note, too.

Then the CA. Microsoft's port reference: "Certificate Services relies on RPC and DCOM to communicate with clients by using random TCP ports that are higher than port 1024." Its table for the service lists TCP 135, SMB on TCP 445 and 139, and the random range 49152-65535. Microsoft's firewall guide explains the two steps: the endpoint mapper on 135 "replies with a dynamically assigned port number that the client must use to communicate with the service". A firewall that allows 135 and not the range lets the first step through and blocks the second (our reading).

Microsoft's own end-to-end test is certutil -ping, which "Attempts to contact the Active Directory Certificate Services Request interface." Run it from the failing client:

:: Read-only. From the client: contact the CA's request interface (config string and host name are examples)
certutil -ping -config "CA01.contoso.com\Contoso Issuing CA"

:: Read-only. Same test by machine name; the terminating comma marks a single machine (Microsoft's syntax), and it shows site cost
certutil -ping CA01.contoso.com,

# Read-only. TCP from the client to the CA: the endpoint mapper and SMB (a passing test proves TCP, not DCOM)
foreach ($port in 135, 445) {
  Test-NetConnection -ComputerName CA01.contoso.com -Port $port -WarningAction SilentlyContinue |
    Select-Object ComputerName, RemoteAddress, RemotePort, TcpTestSucceeded
}

# Read-only. On the CA: is the Certificate Services service running?
Get-Service -Name CertSvc | Select-Object Name, DisplayName, Status, StartType

Microsoft's blog for 0x800706ba lists the same reads, ending with "Use Portqry to verify that the necessary RPC ports are opened." portqry -n CA01.contoso.com -e 135 lists what the CA's endpoint mapper registers; test a listed ncacn_ip_tcp port with -e (our form of that step).

NAT breaks DCOM. Microsoft's RPC firewall article: "You can't use DCOM through firewalls that do address translation." The reason: "DCOM stores raw IP addresses in the interface marshaling packets." A client that reaches the CA through a NAT'd VPN pool or a published address fails even with every port open (our reading of that article).

Step 7: DCOM and access on the CA: the 0x800706ba that isn't the network (read-only)

Microsoft's article for 0x800706ba during enrollment describes a failure that looks like the network and isn't. In its network trace, the client's LDAP queries to the configuration partition succeed, and then the RPC call to the CA comes back access denied. Its note on a tell: "When the issue occurs, if we add the user account that's used to request the certificate to the local administrators group on the certificate authority (CA), the enrollment succeeds for a user-based template. However, enrollment against a machine-based template still returns the same error." That's why adding users to the CA's Administrators group looks like a fix and isn't one.

On the CA, Microsoft's article logs this when auditing is on, as DCOM event 10027 in the System log: "The machine wide limit settings do not grant Remote Activation permission for COM Server applications to the user NT AUTHORITY\ANONYMOUS LOGON SID (S-1-5-7)". Read for it, and for the DCOM hardening events from KB5004442:

# Read-only. On the CA: DCOM 10027 (Microsoft's 0x800706ba article) and 10036 (KB5004442 server event), last 7 days
Get-WinEvent -FilterHashtable @{ LogName = 'System'; Id = 10027, 10036; StartTime = (Get-Date).AddDays(-7) } -ErrorAction SilentlyContinue |
  Select-Object TimeCreated, Id, ProviderName, Message | Format-List

# Read-only. On the failing client: KB5004442 client events 10037 / 10038
Get-WinEvent -FilterHashtable @{ LogName = 'System'; Id = 10037, 10038; StartTime = (Get-Date).AddDays(-7) } -ErrorAction SilentlyContinue |
  Select-Object TimeCreated, Id, Message

KB5004442: "The system will log these events if it detects that a DCOM client application is trying to activate a DCOM server using an authentication level that is less than RPC_C_AUTHN_LEVEL_PKT_INTEGRITY." Its timeline ends with "March 14, 2023 Phase 3 Release - Hardening changes enabled by default with no ability to disable them." So the old registry opt-out isn't a fix on a patched CA. Microsoft's client-side patch raises the level for most Windows clients automatically, so unpatched clients and non-Windows apps are the ones to look at (our reading of KB5004442).

Microsoft's six causes for the access-denied form of 0x800706ba, and the read for each, on the CA:

:: Read-only. On the CA, elevated: the applied policy report (Microsoft's form)
gpresult /h C:\Temp\appliedgpo-ca.html

# Read-only. On the CA: the two local groups and EnableDCOM (group names as Microsoft's article gives them)
Get-LocalGroupMember -Group 'Certificate Service DCOM Access' | Select-Object Name, ObjectClass, PrincipalSource
Get-LocalGroupMember -Group 'Users' | Select-Object Name, ObjectClass
Get-ItemProperty -Path 'HKLM:\SOFTWARE\Microsoft\Ole' -Name EnableDCOM

On a CA installed on a DC, Microsoft's older blog says the DCOM group "may be a Domain Local group instead"; read it with Get-ADGroupMember (our form). The same blog lists Domain Users and Domain Computers as members to check, plus users and computers from other domains in the forest.

Microsoft's article has one line worth repeating before anyone edits a policy on a CA: "The settings configured on the Group Policy Objects (GPOs) are for a reason, so you should talk to your security team before making any changes."

Step 8: Did the request reach the CA, and what did the CA do? (read-only)

If the client got through, the CA has a record. Microsoft's wiki: make sure the request isn't in pending or failed status in the Certification Authority console. Look in Pending Requests and Failed Requests for the requester, and read the CA's Application log:

# Read-only. On the CA: CertificationAuthority events (53 = denied, 77 = template couldn't load, 80 = couldn't publish to AD; IDs from Microsoft's pages)
Get-WinEvent -FilterHashtable @{ LogName = 'Application'; Id = 53, 77, 80; StartTime = (Get-Date).AddDays(-7) } -ErrorAction SilentlyContinue |
  Where-Object ProviderName -like '*CertificationAuthority*' |
  Select-Object TimeCreated, Id, Message | Format-List

For 80, Microsoft's blog: "Check that the Cert Publishers group has permission to read and write to the userCertificate attribute on the user object in AD that is specified in the event."

Pending forever. A template with CA certificate manager approval (the 0x2 flag in Step 4) holds every request until someone issues it. Microsoft documents a renewal trap with it: "When unsupported values of validity and renewal period are configured in a certificate template, the certificate renewal is skipped and the client triggers new enrollment requests instead of renewals, then prompting CA certificate manager approval." Its guidance: "For normal renewal behaviors, set the renewal period to more than 8 hours and less than 20% of the validity period." Read the two values from the certutil -dsTemplate output in Step 4: pKIExpirationPeriod is the validity and pKIOverlapPeriod is the renewal period (Microsoft's note on that article).

Step 9: Chain, revocation, expiry, and renewal timing (read-only)

Revocation. Microsoft's autoenrollment blog: "The certificate request failed. The revocation function was unable to check revocation because the revocation server was offline." Its explanation: the client doesn't have a valid CRL from the issuing CA. Its test runs certutil -v -verify -urlfetch against the issuing CA's certificate. Get the CA certificate from the CA, then verify it with URL fetching:

:: Read-only (writes one local file). The issuing CA's certificate, then verify its chain and fetch every CDP/AIA URL
certutil -config "CA01.contoso.com\Contoso Issuing CA" -ca.cert C:\Temp\issuing-ca.cer
certutil -v -verify -urlfetch C:\Temp\issuing-ca.cer > C:\Temp\verify-issuing-ca.txt

Microsoft's caution on that test: "it will use the security and proxy settings of the user that runs it". The computer account can still fail if your admin session passes (our reading).

Expiry and renewal. Microsoft: "Certificate autoenrollment runs every eight hours." And: "To be renewed, a certificate should have completed 80% of its validity period and be within the renewal period." Read what's in the store and what's about to lapse:

# Read-only. Computer certificates with expiry and the template extension (filtering on the extension's friendly name is our form)
Get-ChildItem -Path Cert:\LocalMachine\My |
  Select-Object Subject, Issuer, NotAfter, Thumbprint,
    @{ n = 'Template'; e = { ($_.Extensions | Where-Object { $_.Oid.FriendlyName -like 'Certificate Template*' } | ForEach-Object { $_.Format($false) }) -join '; ' } }

# Read-only. Anything that expires in the next 30 days (the certificate provider's -ExpiringInDays parameter)
Get-ChildItem -Path Cert:\LocalMachine\My -ExpiringInDays 30 | Select-Object Subject, NotAfter, Thumbprint

Event 64 gives a thumbprint; a Microsoft Q&A answer finds it with Get-ChildItem cert:\*<thumbprint> -recurse (community). The warning threshold comes from the policy's expiration percentage. Microsoft's cmdlet page: it "Sets the percentage of the certificate lifetime at which close-to-expiration events are logged and auto-enrollment notifications start to appear." (ExpirationPercentage in Step 2's output.)

Supersedence leftovers. Old user certificates published in AD aren't removed when a template is superseded. Microsoft KB 2884551: "This feature has been removed in Vista and subsequent Windows versions." That matters with the 0x10 flag in Step 4 (our reading).

Step 10: Domain controller certificates (read-only)

DCs behave differently enough to read separately. Microsoft: "Domain controllers automatically request a domain controller certificate (if published) when they discover an enterprise CA is added to Active Directory." And the catch: "However, domain controllers are unaware of newer certificate templates or superseded configurations on certificate templates. For domain controllers to automatically enroll and renew of certificates, configure a GPO for automatic certificate enrollment, and link it to the Domain Controllers OU."

The current template is Kerberos Authentication. Microsoft: "The Kerberos Authentication certificate template is the most current certificate template designated for domain controllers, and should be the one you deploy to all your domain controllers." The older Domain Controller and Domain Controller Authentication templates "don't include the KDC Authentication object identifier (OID), which was later added to the Kerberos RFC." Microsoft's EKU list for a DC certificate: Client Authentication (1.3.6.1.5.5.7.3.2), Server Authentication (1.3.6.1.5.5.7.3.1), and KDC Authentication (1.3.6.1.5.2.3.5), with the DNS name in the Subject Alternative Name.

Microsoft's reads on a DC:

:: Read-only. On a DC, elevated: enrolled and archived certificates, verbose, with templates and EKUs
certutil -q -v -store my > C:\Temp\dc-store.txt

:: Read-only. Every DC's certificates, verified (DeleteBad and DeleteAll are the destructive modifiers; don't use them here)
certutil -DCInfo Verify > C:\Temp\dcinfo.txt

:: Read-only. The forest's NTAuth store (Microsoft's form)
certutil -viewstore -enterprise NTAuth

Microsoft on the first two: "Certutil shows enrolled and archived certificates for the local computer." The console doesn't: "Archived certificates don't appear in Certificate Manager." -DCInfo "Displays information about the domain controller. The default displays DC certificates without verification." And on NTAuth: "If the domain controller certificate does not chain to a root in the NTAuth store, user authentication will fail."

Microsoft's validation also points at a log: Application and Services > Microsoft > Windows > CertificateServices-Lifecycles-System, where a new autoenrollment shows the template, thumbprint, and EKUs, and a superseded certificate shows an archive event. Step 3's -ListLog read shows the exact channel name on your build.

If the DCs use a non-Microsoft CA, Microsoft KB 291010: "Third-party CAs don't support the automatic enrollment and renewal of domain controller or computer certificates."

Common false starts (read these before you change anything)

Step 11: Change one link, then prove it (only after the read)

Pick the one change Steps 1-10 point at. Save the current state first:

# Low-risk write. Save the template attributes, the autoenrollment keys, and the CA's published templates (our habit)
New-Item -Path C:\Temp -ItemType Directory -Force | Out-Null
certutil -dsTemplate WorkstationAuth-Contoso > C:\Temp\dstemplate-before.txt
certutil -CATemplates -config "CA01.contoso.com\Contoso Issuing CA" > C:\Temp\catemplates-before.txt
reg export 'HKLM\SOFTWARE\Policies\Microsoft\Cryptography\AutoEnrollment' C:\Temp\ae-policy-before.reg /y

Policy (Step 2). In the GPO that targets the right OU, open Public Key Policies > Certificate Services Client - Auto-Enrollment in the half you need (Computer Configuration for computer certificates, User Configuration for user certificates), set Configuration Model to Enabled, and select both boxes. Microsoft: "Computers apply the GPO and download the certificate the next time Group Policy is refreshed." For DCs, use Microsoft's separate GPO linked to the Domain Controllers OU (below).

Set-CertificateAutoEnrollmentPolicy "configures local certificate auto-enrollment policy for a user or computer." Use it (with -WhatIf first) only on one lab machine, to separate a GPO problem from a template problem (our reading).

Template version (Step 4). For user certificates on a version 1 template, duplicate it in the Certificate Templates console, set the rights on the copy, and publish the copy. If the copy replaces the old one, add the old one on the copy's Superseded Templates tab (Microsoft's DC steps use the same tab).

Template rights (Step 4). On the template's Security tab, give the group that should enroll Read, Enroll, and Autoenroll. Microsoft's NPS template steps are the pattern: for the server group, "ensure that Enroll is selected, then select the check box for Autoenroll." If Authenticated Users was removed on purpose, Microsoft's KB 283218 fix: "each and every CA's computer account must be added to the template ACLs and set to Read."

Token refresh after a group change (Step 4). The computer's tickets carry its groups. Microsoft's klist page gives the purge for the computer's logon session; a restart does the same (our reading):

:: Change, on the client (elevated). Purge the computer account's Kerberos tickets, then pulse autoenrollment
klist purge -li 0x3e7
certutil -pulse

For a user, sign out and back in.

Publish the template (Step 5). In the Certification Authority console: Certificate Templates > New > Certificate Template to Issue. Or from the CA, certutil -SetCATemplates, which "Sets the certificate templates that the Certificate Authority can issue." (+ adds, - removes):

:: Change, on the CA. Add one template to the CA's list (WorkstationAuth-Contoso is an example), then read the list back
certutil -SetCATemplates +WorkstationAuth-Contoso
certutil -CATemplates

The path to the CA (Step 6). Ask for a rule from the client subnets to the CA: 135/TCP and 49152-65535/TCP, per Microsoft's port reference. No NAT between DCOM clients and the CA. Then rerun certutil -ping from a client in that subnet.

Access on the CA (Step 7). Talk to the security team first, as Microsoft's article says. Then fix only the cause the read found: remove the requester's group from the Deny user right in the winning GPO, add Authenticated Users back to the Users or Certificate Service DCOM Access group, set EnableDCOM to Y and restart, or restore the COM Security limits for the DCOM group. For the group:

# Change, on the CA. Dry-run first (Microsoft's cause 3)
Add-LocalGroupMember -Group 'Certificate Service DCOM Access' -Member 'NT AUTHORITY\Authenticated Users' -WhatIf

Microsoft's blog: "If you had to change the permissions/members of the CertSVC_DCOM_ACCESS group then you may in certain cases need to run the following to get the CA to recognize the updated DCOM security settings." Its sequence, on the CA, in a maintenance window:

:: Change, on the CA. Microsoft's blog sequence after a DCOM group change; restarting CertSvc pauses issuance briefly
certutil -setreg SetupStatus -SETUP_DCOM_SECURITY_UPDATED_FLAG
net stop certsvc
net start certsvc

Approval and renewal period (Step 8). Issue the pending request, then decide whether the template should require approval at all. If renewals keep landing as new pending requests, set the renewal period inside Microsoft's range: more than 8 hours and less than 20% of the validity period.

Revocation (Step 9). On the CA, certutil -CRL "Publishes new certificate revocation lists (CRLs) or delta CRLs." Then copy the CRL to every CDP location the certificates point at (HTTP paths aren't updated by the CA on their own unless you configured it; our reading), and rerun certutil -verify -urlfetch from a client.

Domain controllers (Step 10). Microsoft's sequence: duplicate Kerberos Authentication, add Domain Controller, Domain Controller Authentication, and Kerberos Authentication on the new template's Superseded Templates tab, publish it on the CA, and link a GPO named, for example, Domain Controller Auto Certificate Enrollment to the Domain Controllers OU with autoenrollment enabled. Microsoft's guide then says to unpublish the superseded templates. Then on one DC: "Alternatively, you can forcefully trigger automatic certificate enrollment using certreq.exe -autoenroll -q from an elevated command prompt."

Then prove it. One machine, one template, one pulse, then the same reads as Steps 3 and 9:

:: Read-mostly. Trigger autoenrollment on one test machine (elevated); user context: certutil -user -pulse as the user
gpupdate /target:computer /force
certutil -pulse

# Read-only. Events 2/3 (and no 6/13/15) since the pulse, and the new certificate with its template
Get-WinEvent -FilterHashtable @{ LogName = 'Application'; StartTime = (Get-Date).AddMinutes(-15) } -ErrorAction SilentlyContinue |
  Where-Object ProviderName -like '*CertificateServicesClient*' | Select-Object TimeCreated, Id, Message
Get-ChildItem -Path Cert:\LocalMachine\My | Sort-Object NotBefore -Descending | Select-Object -First 3 Subject, Issuer, NotBefore, NotAfter

# Low-risk write. Remove the verbose logging value from Step 3 (dry-run first; our habit)
Remove-ItemProperty -Path 'HKLM:\SOFTWARE\Microsoft\Cryptography\AutoEnrollment' -Name AEEventLogLevel -WhatIf

gpupdate /force "Reapplies all policy settings. By default, only policy settings that have changed are applied." Then let the next scheduled run handle a second machine in the group, so you know it works without a pulse, and confirm the thing the user waited for, like the 802.1X connection (our habit).

When a change is justified

FAQ

Why is certificate autoenrollment not working?
Usually one link in the chain: the policy isn't applied for that context, the identity lacks Autoenroll on the template, the template isn't published on a CA, the client can't reach the CA, or the CA refuses the caller over DCOM. The AutoEnrollment event's error code in the Application log tells you which link to read first.

How do I force certificate autoenrollment?
certutil -pulse (elevated) for the computer and certutil -user -pulse for the signed-in user. Microsoft's DC guide also gives certreq.exe -autoenroll -q from an elevated prompt. gpupdate /force triggers it too, because Windows runs autoenrollment when Group Policy updates.

What permissions does a certificate template need for autoenrollment?
Read, Enroll, and Autoenroll for the user or computer (or a group it's in, with the group in its token). The CA's computer account needs Read, which Authenticated Users provides by default. For user certificates the template must be version 2 or later.

What does Event ID 6 with 0x800706ba mean?
Autoenrollment found a template and a CA and the call to the CA failed with "The RPC server is unavailable." Check the network path first with certutil -ping, then the access causes on the CA in Microsoft's 0x800706ba article: network logon rights, the Certificate Service DCOM Access group, EnableDCOM, and the COM Security limits.

Why don't domain controllers get the new Kerberos Authentication certificate?
DCs request the old Domain Controller template on their own, but Microsoft says they're unaware of newer or superseding templates. Publish a template based on Kerberos Authentication that supersedes the old ones, and link an autoenrollment GPO to the Domain Controllers OU.

Related posts

• Intune SCEP Certificate Profile Failed (the Intune path: SCEP profiles, NDES, and the connector instead of Group Policy autoenrollment)
• Group Policy Not Applying (when the Auto-Enrollment setting never reaches the client)
• Netlogon Event ID 5719 (the DC locator side of Event 15 and 0x8007054b)
• Intune Wi-Fi Profile Not Applying (EAP-TLS Wi-Fi is often the thing waiting on the certificate)

Free checklist

A template permission pushed to every computer before one pilot machine got its certificate is a change nobody tested where the enrollment happens. So is a Conditional Access policy enforced before anyone read the report-only results. The free Conditional Access pre-enforcement checklist keeps break-glass accounts, pilot groups, and report-only review on one page:

👉 https://cashflow4375.gumroad.com/l/ujkqxb?utm_source=devto&utm_medium=article&utm_campaign=aps_first_sale&utm_content=certificate-autoenrollment-not-working

If you want the rest of the Intune runway written down for the team (enrollment hygiene, compliance phasing, break/fix cards and read-only PowerShell snapshots), the Intune & M365 Admin Starter Pack pairs with this triage: https://cashflow4375.gumroad.com/l/joonf?utm_source=devto&utm_medium=article&utm_campaign=aps_first_sale&utm_content=certificate-autoenrollment-not-working

Admin Pack Studio; not affiliated with Microsoft. Steps 1-10 favor read-only checks: gpresult, Get-CertificateAutoEnrollmentPolicy, Get-ItemProperty, Get-WinEvent, certutil -Template, -dsTemplate, -TemplateCAs, -CATemplates, -ping, -ca.cert, -verify -urlfetch, -store, -DCInfo Verify, -viewstore, Get-ADRootDSE, Get-ADObject, Get-Acl, Get-ADComputer, Get-ADPrincipalGroupMembership, whoami /groups, Test-NetConnection, portqry, Get-Service, Get-LocalGroupMember, and Get-ChildItem Cert:. certutil -pulse, certutil -user -pulse, and certreq -autoenroll trigger enrollment; output redirection and reg export write local files. AEEventLogLevel, GPO and local autoenrollment policy, template versions, rights, and supersedence, klist purge, certutil -SetCATemplates, firewall rules, user rights, local group membership, EnableDCOM, COM Security limits, certutil -setreg, CertSvc restarts, certutil -CRL, and DC templates and GPOs are deliberate changes. Change one link at a time, test with one machine first, and check current Microsoft Learn for version-specific behavior.