December 19, 2019
Posted by on
Microsoft recommends using “Kerberos Authentication” template for Domain Controllers instead of older “Domain Controller” and “Domain Controller Authentication” templates https://docs.microsoft.com/en-us/windows/security/identity-protection/hello-for-business/hello-hybrid-cert-whfb-settings-pki
we can easily do so creating a duplicate of “Kerberos Authentication” template and set up a superseding for templates issued based on older templates.
One of my Customers complained that when he did so, Active Directory Web Services (used, for example for remote Power Shell connect) started to log a Warning (Even Id 1400), regardless the fact the certificate has proper EKU and the server FQDN is included in subject name (as DNS name as it is described in the article) and in SAN.
Event Id: 1400
|Active Directory Web Services could not find a server certificate with the specified certificate name. A certificate is required to use SSL/TLS connections. To use SSL/TLS connections, verify that a valid server authentication certificate from a trusted Certificate Authority (CA) is installed on the machine.
It is important to note that by default “Kerberos Authentication” template has Subject name set to None as per RFC 3280, so he customized the template duplicate and put “DNS name” under “Subject name format”.
I created a new duplicate of the Kerberos Authentication template (Server 2003 Compatibility level!!!) and add a Common Name to the Subject Name field
after that I added the template to my CA and requested the template-based certificate from my Domain Controller. I removed the old certificatee to keep just one certificate in the Local machine store.
After after restart ADWS successfully recognized the certificate (Even Id 1401).
Note: Microsoft has an article saying the empty Subject name is fine from RFC point of view, but that can cause issues with third-party apps… It looks like not only with third party