Smartcard Logon - Uwe Gradenegger

YubiKey Personal Identity Verification (PIV) Attestation - with the TameMyCerts Policy Module for Microsoft Active Directory Certificate Services (ADCS)

Since the recently released version 1.7, the TameMyCerts Policy Module for Microsoft Active Directory Certificate Services Personal Identity Verification (PIV) attestation for YubiKeys.

A YubiKey is a compact security token that can be used like a smartcard for the secure storage and use of certificates and can therefore also be used for passwordless logon to Active Directory environments.

This cool function was developed by Oscar Virot and integrated into TameMyCerts. This makes it possible to provide cryptographic proof when issuing certificates and thus ensure that a key pair is actually generated with a YubiKey and secured by it and cannot be exported.

This can be particularly helpful in complying with the NIS2 directive if companies decide to use certificates as a second factor for logging in with security-critical accounts in the Active Directory.

Smartcard login fails with 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)"

Assume the following scenario:

The company would like to use smartcard logon.
The domain controllers are with certificates that can be used for smartcard logon equipped.
The users are equipped with certificates that can be used for smartcard logon.
The login to the domain via smartcard 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)

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.