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:
- Enable RPC communication between CA and domain controller.
- Use
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
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
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 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 thedNSHostName
attribute from the requestor's computer object, all fields of theObjectAttributes
set toNULL
, and theDesiredAccess
parameter set toPOLICY_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 thePolicyHandle
parameter set to the value obtained in the previous step, and theInformationClas
s parameter set toPolicyDnsDomainInformation
.- The CA MUST add the value of the
Name
andDNSDomainName
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.