Error enrolling "Kerberos Authentication" certificate in a sparse network

Solution 1:

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:

Enable RPC communication between CA and domain controller.
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.

TL;DR

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] §3.2.2.1.3 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] §3.2.2.6.2.1.4.5.9.

If the CT_FLAG_SUBJECT_ALT_REQUIRE_DOMAIN_DNS flag is set, the CA SHOULD:

The CA SHOULD retrieve a handle for the information policy using the LsarOpenPolicy method ([MS-LSAD] section 3.1.4.4.2), 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 3.1.4.4.4), 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.

Solution 2:

In order to bypass the RPC call back to your DC you can duplicate the Kerberos template and add the SAN's manually. Then enable Autorenew.

Here are the steps -

Configure Template:

duplicate the kerberos template
configure the new templates subject name to 'supply in the request'
give your DC's read and enroll permissions on the new template
You can supersede the older templates if needed
publish the template

On your WES:

iisreset to refresh the template list

Enroll the certificate:

On your isolated DC enroll a certificate and add the Domain names in the SAN extension (this will not make the RPC call back from the CA to the DC).

(If you cant see the template clear the Local WES cache at C:\ProgramData\Microsoft\Windows\X509Enrollment)

Enable Auto renew (via GPO):

Windows Settings > Security Settings > Public Key Policies > Certificate Services Client - Auto-Enrollment. It is enough to mark only 'Renew expired certificates, update pending certificates, and remove revoked certificates'

Testing the Auto renew:

On the new template - right click and choose 'Reenroll all Certificate Holders'. This will increase the template's major version and will force a certificate renewal at the next Auto enrollment cycle (Once 8 hours).

If you dont want to wait - then iisreset the WES, Delete the local x509enrollment folder and run 'certutil -pulse'

Good Luck