Smartcard Logon - Uwe Gradenegger

Signing certificates bypassing the certification authority - solely using built-in tools

In the article "Signing certificates bypassing the certification authority"I described how an attacker with administrative rights on the certification authority can generate a logon certificate for administrative accounts of the domain by bypassing the certification authority software, i.e. by directly using the private key of the certification authority.

In the previous article I described the PSCertificateEnrollment Powershell Module is used to demonstrate the procedure. Microsoft supplies with certreq and certutil However, perfectly suitable pentesting tools are already included with the operating system ex works.

Changes to Certificate Issuance and Certificate-Based Logon to Active Directory with the May 10, 2022 Patch for Windows Server (KB5014754)

With the May 10, 2022 patch, Microsoft is attempting to patch a vulnerability in the Active Directory in which the certificate-based enrollment (commonly known as PKINIT or also Smartcard Logon) to close.

The update changes both the behavior of the Certification Authority as well as the behavior of Active Directory when processing certificate-based logins.

Force domain controller (or other participants) to use an online responder (OCSP)

By default, Windows systems, even if an online responder (OCSP) is configured, will be sent to a certain number of OCSP requests fall back to a (if available) brevocation list, because this is usually more efficient in such a case. However, this behavior is not always desired.

For example, if one uses smart card logins, one might want to know if Logins were executed with unauthorized issued certificates. In conjunction with the deterministic good of the online responder you can thus create an (almost) seamless Audit trail create for all smartcard logins.

Configuring a Certificate Template for Domain Controllers

Even with a certificate template for domain controllers that is supposedly simple to configure, there are a few things to keep in mind.

Prevent smartcard logon to the network

Installing Active Directory Certificate Services in the default configuration automatically configures the environment to accept smart card logins from domain controllers.

Therefore, if the use of smart card logins is not desired, it makes sense to disable the functionality so that, in the event the certificate authority is compromised, it can not to jeopardize the Active Directory.

Automatically change passwords for accounts that require login via smartcard or Windows Hello for Business

A new feature of Windows Server 2016 is that the passwords for accounts that have a plain Login with smartcards be automatically renewed according to the password light lines.

If the "Smart card is required for interactive logon" option is enabled for a user account, the password of the user account is set to a random value once. However, the password never changes after that, which makes the account more vulnerable to pass-the-hash attacks.

The newly introduced feature solves this problem by generating new randomly generated passwords for corresponding accounts on a regular basis (depending on the password policy configured for the account).

Use Authentication Mechanism Assurance (AMA) to secure administrative account logins.

Authentication Mechanism Assurance (AMA) is a feature designed to ensure that a user is a member of a security group only if they can be shown to have logged in using a strong authentication method (i.e., a smart card). If the user logs in via username and password instead, he or she will not have access to the requested resources.

Originally intended for access to file servers, however, AMA can also be used (with some restrictions) for administrative logon. Thus, for example, it would be conceivable for a user to be unprivileged when logging in with a username and password, and to have administrative rights when logging in with a certificate.

Signing in via smart card fails with error message "Signing in with a security device isn't supported for your account."

Assume the following scenario:

A user has a Smartcard Logon certificate and logs on to the Active Directory domain with it.
The login fails. The following error message is returned to the user's computer:

Signing in with a security device isn't supported for your account. For more info, contact your administrator.

Configuring a Certificate Template for Authentication Mechanism Assurance (AMA)

Authentication Mechanism Assurance (AMA) provides the ability to tie membership in a security group to enrollment with a smart card certificate containing a specific Object Identifier (OID).

If the user does not log in with the smartcard certificate, but with user name and password, he is also not a member of the security group.

The following describes how to generate a certificate template for use with Authentication Mechanism Assurance.

Logon via smartcard fails with error message "The revocation status of the authentication certificate could not be determined."

Assume the following scenario:

A user has a Smartcard Logon certificate and logs on to the Active Directory domain with it.
The login fails. The following error message is returned to the user's computer:

The revocation status of the authentication certificate could not be determined.

Creating a virtual smart card in a Hyper-V guest system

For test environments, it is often helpful to be able to work with smartcards. Below is a brief guide on how to set up a virtual smartcard in a Hyper-V guest using a virtualized Trusted Platform Module (TPM).

Domain Controller Certificate Templates and Smartcard Logon

In order for domain controllers to process smart card logins, they need certificates that provide this function.

Editing the NTAuthCertificates object in Active Directory

In the default configuration, all certification authority certificates of Active Directory integrated certification authorities (Enterprise Certification Authority) are located in an object of type CertificationAuthority named NTAuthCertificates within the Configuration Partition of the Active Directory forest.

Attack vector on Active Directory directory service via smartcard logon mechanism

In simple terms, public key cryptography can be reduced to the assumption that the private part of each key pair is known only to its owner.

A certification authority is responsible for the correct identification of users, computers or resources. Its issued certificates are therefore granted a trust status because all participants assume that their private key is known only to it.

If an attacker succeeds in gaining knowledge of a certification authority's private key, or at least Perform signatures using the private key, the integrity of the certification authority is no longer guaranteed.

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.