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 Appliedand theAEPolicyregistry 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 -TemplateCAslists 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 Accessgroup, 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 | What should be true | Typical symptom when it breaks |
|---|---|---|
| 1. Symptom captured | Which identity, which template, which machines, since when, what changed | "Certificates aren't working" with no template name |
| 2. Policy applied | Autoenrollment enabled in the applied policy for that context (user or computer) |
AEPolicy missing; GPO linked to the wrong OU or the wrong half (User vs Computer) |
| 3. Events | AutoEnrollment events read, error code noted | Event 6 or 13 nobody has decoded |
| 4. Template | Version 2 or later for user autoenrollment; Read, Enroll, Autoenroll for this identity; CA can read it | Autoenroll granted to a group the computer isn't in; Authenticated Users removed |
| 5. Published | An enterprise CA lists the template under Certificate Templates | Template duplicated but never issued |
| 6. CA reachable | Client reaches a DC and the CA over 135 and the dynamic range; CertSvc running | Event 15 (no DC); 0x800706ba across a firewall or NAT |
| 7. DCOM and access on the CA | The identity can log on to the CA over the network and activate its DCOM interface | 0x800706ba with DCOM 10027 on the CA |
| 8. Request on the CA | Issued, not denied or pending | Pending forever (manager approval); denied 0x80094800 |
| 9. Chain and renewal | CA chain and CRLs valid; renewal window sane | Revocation server offline; Event 64; renews too often |
| 10. Domain controllers | A DC autoenrollment GPO and a current Kerberos Authentication-based template | DCs still on the old Domain Controller certificate |
| 11. Change | Only after Steps 1-10 agree: one link, one change | Full Control on the template, same failure |
Step 1: Capture the symptom (read-only)
Write these on the ticket first:
| Fact | Why it matters |
|---|---|
| User or computer certificate? | Different policy half, different registry hive, different event context ("local system" vs the user), different token (our reading) |
| Template name (the CN, not only the display name) |
certutil and AD use the template name; the console shows the display name. They can differ |
| Which machines or users fail, and which work | A group, an OU, a site, or an OS version in common is the first lead |
| New enrollment or renewal? | Never had one: Steps 2-7. Had one and it didn't renew: Steps 8-9 |
| What changed? | Template duplicated or edited, CA renewed or migrated, GPO moved, firewall change, DCOM hardening updates, a group removed from a template ACL |
Then branch on what you see:
| What you see | What it usually means (our reading unless noted) | Start at |
|---|---|---|
| No AutoEnrollment events at all | Policy not applied, or autoenrollment disabled in the registry | Step 2 |
| Event 15 with 0x8007054b | Microsoft: "is due to problems getting to a DC in the domain, common cause is name resolution." | Step 6 |
| Event 6 or 13 with 0x800706ba | The CA isn't reachable over RPC, or DCOM on the CA refuses the caller | Steps 6, 7 |
| 0x80094800, "The requested certificate template is not supported by this CA." | The CA doesn't publish the template, or can't read it | Steps 4, 5 |
| User certificates work, computer certificates don't (or the reverse) | The other policy half, or the other identity's rights on the template | Steps 2, 4 |
| DCs keep the old Domain Controller certificate | No DC autoenrollment GPO, or the new template isn't published | Step 10 |
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).
| Finding | What it means (our reading unless noted) | Next |
|---|---|---|
No AEPolicy anywhere, GPO in RSoP |
The GPO setting is there but not enabled, or another GPO wins with Not Configured | The winning GPO in the gpresult report |
| GPO missing from RSoP | Link, security filtering, WMI filter, or the client isn't processing policy | Group Policy Not Applying |
AEPolicy = 0x8000
|
Autoenrollment disabled (Microsoft's blog) | Find what set it (a GPO set to Disabled, or a script) |
AEPolicy = 7 in the policy key |
Policy is fine | Step 3 |
| Policy only in the local (non-policy) key | Set by Set-CertificateAutoEnrollmentPolicy or by hand; the wiki says it means "AD GPOs are not working" |
Step 2 again for the domain GPO |
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:
| Event | Source and text | Points at |
|---|---|---|
| 2 / 3 | Microsoft: "Stop and Start messages are event IDs 2 and 3." | Autoenrollment ran. No 2/3 at all: Step 2 |
| 6 (AutoEnrollment, Error) | Example from a community comment on Microsoft's PKI blog: "Automatic certificate enrollment for local system failed (0x800706ba) The RPC server is unavailable." | The error code in parentheses (table below) |
| 13 (CertEnroll) | Microsoft: "Autoenrollment 13 is further into the chain, where we actually can try enroll for a certificate but fails." It names the template and the CA | The template and the CA it tried (Steps 5-8) |
| 15 (AutoEnrollment) | Microsoft: with 0x8007054b, "is due to problems getting to a DC in the domain, common cause is name resolution." With 0x80072751, it "is commonly due to the client being logged on with cached credentials" | Step 6: DC and name resolution first |
| 64 (AutoEnrollment, Warning) | Community post on Microsoft Q&A: "Certificate for local system with Thumbprint ... is about to expire or already expired." | Step 9: a certificate nobody is renewing |
| 82 (Application) | Microsoft's 0x800706ba article: "Event ID 82 is logged in Application logs if auto-enrollment is failing with the same error." | Step 7 |
Common codes in Event 6 and 13, each from the Microsoft page named:
| Code | Microsoft's text | Link in the chain |
|---|---|---|
| 0x800706ba | "The RPC Server is unavailable" (Microsoft's enrollment article); its causes are mostly access on the CA | Steps 6, 7 |
| 0x80070005 | "Access is denied", which Microsoft's blog says "occurs when attempting to bind to the certification authority to generate the certificate request" | Step 7 |
| 0x80094800 | "The requested certificate template is not supported by this CA." (KB 283218) | Steps 4, 5 |
| CRL error | "The revocation function was unable to check revocation because the revocation server was offline." (Microsoft's autoenrollment blog) | Step 9 |
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
| Finding | What it means (our reading unless noted) | Next |
|---|---|---|
| No events after a pulse, even with verbose logging | Policy isn't applied for that context | Step 2 |
| 2 and 3 with nothing in between | Autoenrollment ran and found nothing to do: no template it may autoenroll, or a valid certificate already exists | Step 4 |
| 15 with 0x8007054b | The client couldn't reach a DC | Step 6 |
| 6 / 13 with 0x800706ba or 0x80070005 | It found the template and the CA and failed calling the CA | Steps 6, 7 |
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:
| Bit | Name | Microsoft's description | What you'll see (our reading) |
|---|---|---|---|
| 0x2 | CT_FLAG_PEND_ALL_REQUESTS |
"This flag instructs the CA to put all requests in a pending state." | Requests sit in Pending Requests (Step 8) |
| 0x10 | CT_FLAG_AUTO_ENROLLMENT_CHECK_USER_DS_CERTIFICATE |
Instructs "clients not to do autoenrollment for a certificate based on this template if the user's userCertificate attribute" in AD "has a valid certificate based on the same template" | A user with a certificate published in AD gets no new one on a new PC |
| 0x20 | CT_FLAG_AUTO_ENROLLMENT |
"This flag instructs clients to perform autoenrollment for the specified template." | Set on templates meant for autoenrollment; it doesn't replace the Autoenroll permission |
| 0x40000 | CT_FLAG_SKIP_AUTO_RENEWAL |
"This flag indicates that the certificate should not be auto-renewed, although it has a valid template." | Initial enrollment works, renewal never happens |
# 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)
}
| Finding | What it means (Microsoft unless noted) | Next |
|---|---|---|
| Template version 1 for user certificates | Version 1 autoenrolls only computer certificates | Step 11: duplicate it |
| Autoenroll granted to a group, identity not in it | The client skips the template (our reading) | Add the identity to that group, not a new ACE |
| Group membership in AD, not in the token | Token predates the change (our reading) | Step 11: restart or klist purge |
| Authenticated Users removed, no CA computer Read ACE | The CA can't read the template: 0x80094800 | Step 11: "each and every CA's computer account must be added to the template ACLs and set to Read." |
PendAllRequests true |
CA certificate manager approval | Step 8 |
SkipAutoRenewal true |
No automatic renewal | Step 9 |
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.
| Finding | What it means (our reading unless noted) | Next |
|---|---|---|
-TemplateCAs returns nothing |
No CA issues the template | Step 11: publish it on one CA |
| Published, but only on a CA the client can't reach | Enrollment tries that CA and fails | Step 6 for that CA |
| A dead CA still listed in Enrollment Services | Clients may try it first | Microsoft's decommission article, deliberately |
| Published on a reachable CA | Publishing isn't the problem | Step 6 |
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).
| Finding | What it means (Microsoft unless noted) | Next |
|---|---|---|
| Event 15, 0x8007054b | No DC: name resolution or reach | The Netlogon 5719 post |
certutil -ping fails, 135 fails |
The CA is down, unreachable, or 135 is blocked | Network path; CertSvc on the CA |
135 succeeds, -ping fails |
The dynamic range is blocked, or DCOM refuses the call (our reading) | PortQry the listed port, then Step 7 |
| Works on the LAN, fails over VPN | NAT or a VPN firewall policy without the range (our reading) | VPN path design; Microsoft's NAT note |
CertSvc stopped |
Nothing answers on the CA | Read the CA's System and Application logs for why it stopped before you restart it (our reading) |
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:
| Cause (Microsoft's article) | Read-only check | Healthy value |
|---|---|---|
| 1. Access this computer from the network doesn't include the requester, or Deny access to this computer from the network includes a group it's in |
gpresult /h on the CA, User Rights Assignment, note the Winning GPO
|
Microsoft's default list: Administrators, Backup Operators, Everyone, and Users; no requester group in Deny |
| 2. Authenticated Users missing from the CA's local Users group | Get-LocalGroupMember -Group Users |
Domain Users, Authenticated Users, INTERACTIVE |
| 3. Authenticated Users missing from Certificate Service DCOM Access | Get-LocalGroupMember -Group 'Certificate Service DCOM Access' |
Authenticated Users present |
4. EnableDCOM not Y on the client or the CA |
HKLM\Software\Microsoft\OLE, value EnableDCOM
|
Y |
| 5. Restrictions for Unauthenticated RPC Client: Microsoft's cause title is "Remote Procedure Call restrictions aren't applied on the Certificate server" |
gpresult /h on the CA, Administrative Templates \ System \ Remote Procedure Call; note the winning GPO and its value |
Compare with Microsoft's article before changing it; its wording is terse (our note) |
| 6. Certificate Service DCOM Access removed from the COM Security limits | Component Services > My Computer > COM Security > Edit Limits | Local and Remote Access; Local and Remote Activation |
:: 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."
| Finding | What it means (Microsoft unless noted) | Next |
|---|---|---|
| 10027 ANONYMOUS LOGON on the CA | Kerberos failed for the caller and it fell back to anonymous, which DCOM refuses | Causes 1 and 2 first |
| Requester's group in Deny access to this computer from the network | Cause 1 | Security team, then the winning GPO (Step 11) |
| Authenticated Users missing from either group | Causes 2 and 3 | Step 11: add it back |
EnableDCOM = N
|
Cause 4 | Step 11 |
| COM Security limits greyed out | Set by policy. In a Microsoft Q&A answer, the DCOM SDDL security options are the place to look (community) | The GPO that sets them |
| 10036 on the CA, 10037/10038 on clients | DCOM hardening rejected a low authentication level | Patch the client or the app (our reading) |
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
| CA event | Microsoft's text | Means |
|---|---|---|
| 53 | "Active Directory Certificate Services denied request" ... "because The requested certificate template is not supported by this CA." | The CA can't use the template: not published, or it can't read it (Steps 4, 5) |
| 77 | "Certificate Template could not be loaded. Element not found." | The CA lost Read on the template (KB 283218) |
| 80 | "Active Directory Certificate Services could not publish a Certificate for request" ... "Insufficient access rights to perform the operation." | The certificate issued but couldn't be written to the user object in AD |
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).
| Finding | What it means (our reading unless noted) | Next |
|---|---|---|
| Pending | Manager approval on the template | Issue it, or Step 11 for the template |
| Failed with 0x80094800 | Microsoft's KB 283218 | Steps 4, 5 |
| New request every 8 hours, each pending | Microsoft's renewal-period trap above | Step 11: renewal period |
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).
| Finding | What it means (our reading unless noted) | Next |
|---|---|---|
-urlfetch fails on a CDP URL |
Expired or unreachable CRL; Microsoft's revocation error | Step 11: publish a CRL on the CA, fix the URL path |
| Certificate past 80% and inside the renewal period, no renewal | Renewal blocked: rights (Enroll still needed), skip-renewal flag, or Steps 6-8 | Steps 4, 6-8 |
| Event 64 for a certificate nobody uses | A stale certificate in a monitored store | Confirm the owner, then archive or remove it |
| Two certificates from old and new templates | Supersedence not published, or old certificate still valid | Steps 5, 10 |
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."
| Finding | What it means (Microsoft unless noted) | Next |
|---|---|---|
| DCs only have a Domain Controller template certificate | No DC autoenrollment GPO, or the Kerberos Authentication-based template isn't published or doesn't supersede | Step 11: the DC sequence |
| GPO on the Domain Controllers OU, still no new certificate | The template lacks Autoenroll for Domain Controllers, or isn't published (our reading) | Steps 4, 5 |
| Root missing from NTAuth | Microsoft: user authentication fails | Microsoft's NTAuth import article for non-Microsoft CAs |
Common false starts (read these before you change anything)
| False start | Why it hurts | Read-first alternative |
|---|---|---|
| Full Control (or Write) on the template for Domain Computers | Autoenrollment needs Read, Enroll, and Autoenroll. Write lets every computer change what the CA issues for that template (our view) | Grant exactly Read, Enroll, Autoenroll to the group that should enroll (Step 4) |
| Adding users to the CA's local Administrators group | Microsoft's 0x800706ba article: it makes user-template enrollment succeed while machine-template enrollment "still returns the same error." It also hands out admin on a CA (our view) | Read the six causes (Step 7) |
certreq or the MMC wizard on every machine |
It hides the broken link and won't renew on its own if the link stays broken (our reading) | One manual enrollment on one machine as a test, as Microsoft's blog suggests for 0x800706ba |
| Turning off the firewall on the CA | Shows the path matters, not which rule was missing (our view) |
certutil -ping and PortQry from the client (Step 6) |
| Disabling DCOM hardening with the registry value | KB5004442 Phase 3 removed the opt-out | Find the client or app on 10037 / 10038 (Step 7) |
certutil -DCInfo DeleteBad or DeleteAll while reading |
Those modifiers delete DC certificates |
certutil -DCInfo Verify first (Step 10) |
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
| Finding | Prefer | Avoid |
|---|---|---|
| Identity lacks Autoenroll | Read, Enroll, Autoenroll for the intended group | Full Control or Write on the template |
| CA can't read the template | Authenticated Users back, or every CA computer account with Read | Removing ACEs to "tighten" without the CA's Read |
| 135 or the range blocked | A client-to-CA rule for 135 and 49152-65535 | Turning off the CA's firewall |
| Access denied on the CA | The one cause from Microsoft's six, with the security team | Requesters in the CA's Administrators group |
| DCs on the old template | Kerberos Authentication-based template, superseding, DC GPO | Deleting DC certificates with -DCInfo DeleteAll
|
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:
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.
Top comments (0)