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

Author Uwe GradeneggerPosted on Categories Active Directory, Penetration Testing, Security, Smartcard, Certificate usageTags , , ,

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.

Microsoft uses the term "Enhanced Key Usage", the correct name according to RFC 5280 is "Extended Key Usage"..

Checking the behavior

Do you know TameMyCerts? TameMyCerts is an add-on for the Microsoft certification authority (Active Directory Certificate Services). It extends the function of the certification authority and enables the Application of regulationsto realize the secure automation of certificate issuance. TameMyCerts is unique in the Microsoft ecosystem, has already proven itself in countless companies around the world and is available under a free license. It can downloaded via GitHub and can be used free of charge. Professional maintenance is also offered.

You can check this behavior via the event viewer on the domain controller that processes the logon. You can track the operations that take place against certificates in the CryptoAPI (CAPI) log. This log is disabled in the default configuration due to the large amount of data generated. It can be found under Applications and Services Logs - Microsoft - Windows - CAPI2 - Operational. With a right click you can activate it with the command "Enable Log".

If you now log in via smartcard, various events concerning the smartcard certificate are logged. For us, the event with the number 11 is of interest.

In the "Details" tab you can see that the CertGetCertificateChain function is called by the Local Security Authority Subsystem (lsass) process. When called, there is an attribute "ExtendedKeyUsage" which is empty. This means that any extended key usage is allowed when checking the certificate.

This is by no means a bug: this behavior was integrated into Windows Server 2008 at the time of Windows Vista and still exists today in all Windows Server versions. The aim at the time was to enable logon with digital ID cards and comparable identification documents. Here it could not be ensured whether the certificates on them would have the correct extended key usages, or even have such an extension. So the entire check was simply switched off completely.

Activation of the Extended Key Usages check

If you want to re-enable the check for extended key usages, there is a registry key for this, which is set for the Kerberos Key Distribution Center (KDC) process to each Domain controller must be activated. It is located under the following key:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Kdc

If you set a DWORD (32-bit) value named SCLogonEKUnotrequired with value 0, the check for extended key usages is active again.

The KDC service must be restarted to apply the change.

Result control

If you now perform another logon via smartcard and intersect with the CAPI log, you will see that CertGetCertificateChain now expects one of the following three Extended Key Usages:

  • id-pkinit-KPClientAuth (1.3.6.1.5.2.3.4)
  • TLS/SSL Client Authentication (1.3.6.1.5.7.3.2)
  • Smart Card Logon (1.3.6.1.4.1.311.20.2.2)

But even in this constellation, some gaps remain: Client Authentication Extended Key Usage is very widespread and, for example, is often used in conjunction with the Microsoft Network Policy Service (NPS), which requires the certification authority certificate to be located in the NTAuthCertificates object is located in the Active Directory.

So can I use any extended key usage to perform a smart card login?

No, this is not possible. The KDC process again seems to check whether the presented certificate has one of the relevant Extended Key Uages (at least this is what tests on TGT forging with kekeo suggest: The KDC will not display the Event no. 21 with the error message "The certificate is not valid for the requested usage. log). However, the KDC does not revalidate the certificate at this point.

This means that this gap can be exploited as described in order to circumvent any restrictions on extended key usages for certification authority certificates.

Related links:

External sources

en_USEnglish
de_DEDeutsch en_USEnglish