I have an AD domain. 2003 FFL/DFL. The schema was upgraded to version 56 for Server 2012. The domain contains a mix of domain controllers from Server 2003, Server 2008, Server 2008 R2, and now Server 2012.

I have an Enterprise Issuing Certificate Authority running 2008 R2.

On the Server 2012 domain controllers, they are unable to enroll or autoenroll for their KerberosAuthentication certificates. Error event IDs 6 and 13 in the Application log:

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

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

Seeing that "RPC server is unavailable" instinctively makes one jump to the conclusion that there are network connectivity issues. But it's not that.

  • I've used portqry.exe to verify that the endpoint mapper and all high-numbered ports are indeed available from the DC to the ECA.
  • The 2012 domain controller did successfully autoenroll for two other types of certificates. It's just this one certificate that's the problem.
  • I see the request on the ECA and it failed and has the same reason for failure as the client.

So it's obviously got network comms. There's something about this particular certificate. No other domain controllers have problems with this certificate. Only the 2012 DCs.

  • I had the same issue with a 2012R2 RODC (decomissioned since then for unrelated reasons) in DMZ (limited network access). As an afterthough, I found some resources (that I can no longer locate...) that reverse RPC Access is required (eg ECA -> DC) for some templates. Opening ports for reverse MSRPC connectivity might help...
    – Don Zoomik
    Jul 3 '15 at 0:00
  • Ryan - I fixed this issue myself - see here: serverfault.com/questions/854290/…
    – TheCleaner
    Jun 6 '17 at 19:08

The 1722 error can be erroneous and misleading in certificate services. Have you tried this?


  • All those settings are correct. Unfortunately this doesn't solve it for me.
    – Ryan Ries
    Feb 15 '14 at 1:09
  • Were there ever any other CAs in the domain that have since been decomissioned? Feb 15 '14 at 1:38
  • Nope, no changes to CA infrastructure in this domain, ever.
    – Ryan Ries
    Feb 15 '14 at 1:45
  • Is the issuing CA the root CA or a subordinate CA? If it's a subordinate CA, the requesting machine must be able to validate the certificate chain up to the root, including checking CRLs. Examine the CDP and AIA extensions in the issuing CA's certificate and ensure those locations can be contacted by the server having the problem. Feb 16 '14 at 0:52

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.