Smartcard Logon - Page 2 - Uwe Gradenegger

Domain controller does not check extended key usage on smart card login

Anyone who wants to use the smartcard logon function in their company would be well advised to ensure that their certification authority has the strongest possible security hardening. This includes some essential measures:

Removing all unnecessary certification authority certificates from the NTAuthCertificates object in Active Directory: Each certification authority located in this store is authorized to issue smartcard logon certificates in Active Directory for the complete forest.
Use qualified subordinationRestricting the certification authority certificates so that they are only trusted for the extended key usages actually issued. In the event of a compromise of the certification authority, the damage is then limited to these extended key usages. The "Smart Card Logon" Extended Key Usage would then only be present in the certification authority certificate of the certification authority that actually issues such certificates.

What is interesting about these thoughts, however, is that the domain controllers do not check the extended key usages at all when logging in via smartcard.

Active Directory forest compromised by EDITF_ATTRIBUTESUBJECTALTNAME2 flag

In net circulate unfortunately much at many Instructions (also the big players are not excluded from this, not even Microsoft itself or the Grand Master Komar), which fatally recommends that the EDITF_ATTRIBUTESUBJECTALTNAME2 flag should be set on the certification authority - supposedly to be able to issue Subject Alternative Name (SAN) extension certificates for manually submitted certificate requests.

Unfortunately, this approach is not only unnecessary, it also has some unpleasant side effects, which in the worst case can help an attacker to take over the entire Active Directory forest.

Overview of the different generations of domain controller certificates

Over the generations of Windows operating systems, various certificate templates for domain controllers have been established. In a current Active Directory directory service, one will find three different templates for this purpose.

Domain controller
Domain Controller Authentication
Kerberos Authentication

Below is a description of each template and a recommendation for configuring domain controller certificate templates.

certutil -dcinfo fails with error message "KDC certificates: Cannot find object or property. 0x80092004 (-2146885628 CRYPT_E_NOT_FOUND)"

Assume the following scenario:

Domain controllers have certificates for LDAP over SSL.
The certificates do not include the Extended Key Usage "Smart Card Logon" or "Kerberos Authentication".
If you run certutil -dcinfo, the command reports the following error message:

0 KDC certificates for DC01
No KDC Certificate in MY store
KDC certificates: Cannot find object or property. 0x80092004 (-2146885628 CRYPT_E_NOT_FOUND)

Manual application for a domain controller certificate

There are cases where you cannot or do not want to obtain domain controller certificates from a certification authority in your own Active Directory forest.

In this case, the use of certificate templates is not possible, and one must manually create a Certificate Signing Request (CSR).

Requesting a certificate fails with the error message "A certification chain processed correctly, but one of the CA certificates is not trusted by the policy provider. 0x800b0112 (-2146762478 CERT_E_UNTRUSTEDCA)".

Here's the scenario:

A user applies for a certificate from an Active Directory integrated certification authority (Enterprise Certification Authority).
The certificate of the certification authority is trusted, i.e. it is located in the Trusted Root Certification Authorities store.
The certificate request fails with the following error message:

A certification chain processed correctly, but one of the CA certificates is not trusted by the policy provider. 0x800b0112 (-2146762478 CERT_E_UNTRUSTEDCA)