Error enrolling "Kerberos Authentication" certificate in a sparse network

According to documentation, the behavior you are facing is expected, by design and cannot be turned off. Kerberos Authentication requires an RPC connection from CA to DC. What are the options for you:

  1. Enable RPC communication between CA and domain controller.
  2. Use Domain Contoller Authentication certificate template instead of Kerberos Authentication template. Domain Contoller Authentication template does not require RPC connection back to DC.

In fact, I didn't remember all the details and kudos to you, that you did good investigation and pointed about a failed RPC callback, this really reduced the amount of possible reasons. Full details on why this happens are below.


Part 1

First of all, about certificate templates: both, Domain Controller Authentication and Kerberos Authentication templates are used to provide support for LDAPS (LDAP over TLS) and mutual authentication during certificate/smar card logon.

The difference between two is how subject is constructed, or what is included there. Domain Controller Authentication includes domain controller's FQDN in SAN extension only. Kerberos Authentication adds two more names: FDQN and NetBIOS names of domain. In addition, Kerberos Authentication adds a KDC Authentication EKU. Default template configuration is defined in [MS-CRTD], Appendix A. To be more clear:

  • Domain Controller Authentication subject name has 134217728 (0x8000000) flag combination, which translates to only flag: CT_FLAG_SUBJECT_ALT_REQUIRE_DNS

  • Kerberos Authentication subject name has 138412032 (0x8400000) flag combination, which translates to two flags: CT_FLAG_SUBJECT_ALT_REQUIRE_DNS and CT_FLAG_SUBJECT_ALT_REQUIRE_DOMAIN_DNS.

Subject name flags are stored in msPKI-Certificate-Name-Flag attribute ([MS-CRTD] §2.28).

The issue in your question is caused by the requirement in SAN to include domain FQDN and NetBIOS names. Kerberos Authentication template is the only default template that uses CT_FLAG_SUBJECT_ALT_REQUIRE_DOMAIN_DNS flag.

Part 2

Windows CA uses [MS-WCCE] protocol specification to process requests and issue certificates. This protocol completely specifies the client behavior and small part of interaction and behavior of Windows CA. [MS-WCCE] § defines a special behavior for clients that are domain controllers and prepare their name to be ready for RPC connection by prepending its name with "\\".

Part 3

Windows CA processes the CT_FLAG_SUBJECT_ALT_REQUIRE_DOMAIN_DNS as specified in [MS-WCCE] §


  • The CA SHOULD retrieve a handle for the information policy using the LsarOpenPolicy method ([MS-LSAD] section, with the SystemName parameter set as the dNSHostName attribute from the requestor's computer object, all fields of the ObjectAttributes set to NULL, and the DesiredAccess parameter set to POLICY_VIEW_LOCAL_INFORMATION.
  • The CA SHOULD obtain the requester's computer DNS Domain Information by using the LsarQueryInformationPolicy method ([MS-LSAD] section, with the PolicyHandle parameter set to the value obtained in the previous step, and the InformationClass parameter set to PolicyDnsDomainInformation.
  • The CA MUST add the value of the Name and DNSDomainName field in the returned DNS Domain Information from the previous step, to the subject alternative name extension of the issued certificate.

As you can see, LsarOpenPolicy call is indeed the RPC call and returns a handle to RPC connection on success. In your case, this call fails and CA cannot call LsarQueryInformationPolicy (which is RPC call again!) in order to obtain required names to insert in certificate.

Bottom line

There may be a desire to turn off domain FQDN and domain NetBIOS name in Kerberos Authentication template, but I wouldn't recommend this. Nor attempting to add KDC Authentication EKU to Domain Controller Authentication, because first is strictly dependent on presence of domain FQDN and NetBIOs which causes issues in your environment.