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.
Best Answer
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:Domain Contoller Authentication
certificate template instead ofKerberos 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
andKerberos 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 aKDC 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
andCT_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 usesCT_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.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 callLsarQueryInformationPolicy
(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 addKDC Authentication
EKU toDomain Controller Authentication
, because first is strictly dependent on presence of domain FQDN and NetBIOs which causes issues in your environment.