1

I migrated a Windows 2008 R2 DC and Enterprise Root CA to a new Windows 2016 DC and CA. Everything seemed stable except I had a few RODCs and writeable DCs that were showing "Failed Requests" in the CA for their auto enrollment of the KerberosAuthentication Certificate.

The error is:

Event ID: 13

Certificate enrollment for Local system failed to enroll for a KerberosAuthentication certificate with request ID 1052 from CAServer.domain.com\domain-CAServer-CA (The RPC server is unavailable. 0x800706ba (WIN32: 1722)).

Along with:

Event ID: 6

Automatic certificate enrollment for local system failed (0x800706ba) The RPC server is unavailable.

All other auto enrollments work from these DCs, and most of the DCs do not exhibit this behavior, enrolling just fine for all certs including the KerberosAuthentication Certificate.

What is causing these particular clients to fail auto-enrolling just this KerberosAuthentication Certificate?

Community
  • 1
TheCleaner
  • 32,352
  • 26
  • 126
  • 188

1 Answers1

1

After researching this out and trying multiple CA certutil commands among other things I'll skip straight to the actual answer that worked for me:

Most of the time something like "RPC server is unavailable" can be attributed to network connectivity issues or firewall rules.

However, in my case the DCs having issues weren't running the Windows Firewall. BUT it turns out that was the very issue. Someone had decided instead of turning off the firewall (not best practice btw, but I digress) in the Network and Sharing Center, they instead Disabled the Windows Firewall service itself.

This is actually a bad idea as discussed here: How can I back up my recommendation to NOT disable the Windows Firewall service?

Answer:

  1. On the problematic DC not getting the cert start the Windows Firewall service and set it to Automatic startup.
  2. If required in your environment (likely since the service was stopped by someone), turn off the Windows Firewall in Control Panel, System and Security, Windows Firewall for the Domain network, etc. as required.
  3. Verify that the secondary DNS server for that DC is pointed to itself via loopback address. In my case I had a few of these that weren't and their primary wasn't accessible over the WAN at the moment.
  4. run certutil -pulse on the problematic DC
  5. Check the application event log again (should show enrollment ok)
TheCleaner
  • 32,352
  • 26
  • 126
  • 188
  • *"Verify that the primary DNS server for that DC is pointed to itself."* I understood that the Microsoft "best practice" du jour is that the primary DNS server for a DC should *not* point to itself, but that the secondary or tertiary DNS server *should*. And it should use the loopback address. Do you have more recent information than I do? Mine's about a year old. – Mike Sherrill 'Cat Recall' Jul 03 '17 at 17:18
  • @MikeSherrill'CatRecall' - let me update my answer. You're still correct. Our issue was that the problematic ones were pointed to DCs they couldn't reach at the moment and the secondary wasn't set at all. I should have stated "verify the secondary..." not primary. Went too fast typing an answer, so thank you for the comment to correct me! – TheCleaner Jul 05 '17 at 14:40