I was looking at the Windows Server 2008 R2 KDC architecture with my colleague Jan earlier today concerning an issue when using smart cards with 3rd party domain controller certificates.
Our customer that Jan was working with had requested and received a certificate for their DC from Verisign but the W2k8 R2 DC just plainly refused to consider it as a valid KDC certificate and as a result smartcard logons were not possible.
The first knee-jerk reaction was to recite the requirements from the venerable KB´s “Requirements for Domain Controller certificates from a Third-party CA” (http://support.microsoft.com/kb/291010) and “Guidelines for enabling smart card logon with third-party certification authorities” (http://support.microsoft.com/kb/281245).
Both are however quite old and neither has really been updated since Windows 2000.
For example; the GUID part is really only needed if you want to also use the certificate for SMTP replication (See http://support.microsoft.com/kb/947057).
So, barring an updated KB here are some notes on what we found out:
In short; the KDC on Windows Server 2008 R2 will look for one of three conditions when parsing its certificate store for KDC certificates to use:
- the OID for KDC Authentication (126.96.36.199.188.8.131.52)
- the presence of the Template Name DomainController in the certificate (all flavors of MS CA’s stamp this on certificates if it is a part of the request file received)
- the OID for SmartcardLogon (184.108.40.206.4.1.3220.127.116.11)
If one of these is present in the certificate, the KDC will consider it potentially usable as a DC certificate capable of servicing smartcard logons. The last two are present in the W2k3 code while the first one was introduced with Windows Server 2008.
The following two OID’s are typically also used for the EKU´s:
- The OID for Server Authentication(18.104.22.168.22.214.171.124.1)
- The OID for Client Authentication (126.96.36.199.188.8.131.52.2)
In addition to this, the direct issuer of the potential KDC certificate needs to be in the NTAuth store of the DC and all certificates in the chain except the Root CA need to pass revocation checking as well.
Finally, as per RFC5280, the CRL of the SubCA that signs the CRL of the Domain Controller certificate must also include the CERT_CRL_SIGN_KEY_USAGE flag in the Key Usage extension of the SubCA certificate – otherwise revocation checking for the DC cert will fail on a Windows Server 2008 R2 or Windows 7 client.
Note: This is a change from the Windows Server 2003 an Windows XP behaviour which did not enforce the RFC5280 requirements concerning the key usage flag of the certificate used to sign the CRL.
Without these you’ll most likely see KDC Event ID 19 or KDC Event ID 29 being logged on the DC whenever the KDC service starts and every 10 hours afterwards when it tries to locate a valid domain controller certificate.
Note that the easiest and most manageable solution (i.e. autoenrollment and renewal) for an internal DC certificate would probably be to just use a Windows Enterprise Issuing CA and the Kerberos Authentication certificate template for the DC’s, but it should also be possible to add the required OID’s to the .req file if you’re sending it to a 3rd party CA.
Other events on the DC indicating you’re hitting this condition are: KDC_ERR_PADATA_TYPE_NOSUPP and 0xc00000BB being logged on the DC during a smartcard logon from a client.
Requirements for Domain Controller certificates from a Third-party CA
Guidelines for enabling smart card logon with third-party certification authorities
Kerberos Authentication Template
Key Usage requirements for SubCA’s
Updated requirements for a Windows Server 2008 R2 domain controller certificate from a 3rd party CA