Error enrolling "Kerberos Authentication" certificate in a sparse network

Question

I'm currently working on implementing an Enterprise Certification Authority for a customer whose network is not fully connected; it spans several geographical sites, and some of them don't have routing to the site where the CA is located.

In order to work around this, I used the Certificate Enrollment Web Service, which allows for certificate enrollmente via HTTPS; the service is exposed through a public name and IP Address, and computers in the remote sites can reach it this way.

The solution works great for all kind of certificates; however, the domain controllers in the remote sites are unable to obtain a certificate using the template "Kerberos Authentication" (which recent DCs try to use when autoenrollment is enabled); the error is a generic "the RPC server is unavailable", but it happens on the CA itself, getting logged in the failed requests.

This puzzled me for a while, until I decided to look at the network traffic; lo and behold, it seems that when a request is made for a certificate using the template "Kerberos Authentication", the CA tries to connect back to the domain controller which made the request. This is not possible in the customer network, and it seems to be the reason why the request fails.

I guess the CA is somewhat trying to validate that the computer requesting the certificate is actually a domain controller; however, I couldn't find any documentation for this, and such a "callback" seems contrary to the client/server logic of certificate requests.

Is this behaviour documented anywhere?

Can it be turned off?

The O.S. on the CA is Windows Server 2019.

---

Edit

There are four domains in the AD forest; the CA is in the forest root domain.
The behaviour is the same for all DCs in all domains: whenever a request is made for a "Kerberos Authentication" certificate, either manually or via autoenrollment, the CA tries to contact the requesting DC on ports 445 and 139 (strangely enough, there is no actual LDAP, Kerberos or RPC traffic); when this fails, the request gets denied with the error "denied by policy module" and the status code "the RPC server is unavailable".

This only happens for "Kerberos Authentication" certificates; all other certificates can be enrolled successfully via CES, including "Domain Controller Authentication" and "Directory Email Replication".

I also tested this for DCs which can actually talk with the CA: if traffic is blocked from the DC to the CA, thus forcing the request to use CES, but not the other way around, the requests succeeds; if traffic is blocked from the CA to the DC, the request fails.

Answer 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:

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.

---

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.

Answer 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:

1. duplicate the kerberos template

2. configure the new templates subject name to 'supply in the request'

3. give your DC's read and enroll permissions on the new template
4. You can supersede the older templates if needed
5. 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