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 supports Personal Identity Verification (PIV) attestation for YubiKeys.

A YubiKey is a compact security token that can be used, among other things, like a smart card 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 logon with security-critical accounts in Active Directory.

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

Smart card logon 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 smart card logon.
  • The domain controllers are equipped with certificates that can be used for smart card logon .
  • The users are equipped with certificates that can be used for smart card logon.
  • Logon to the domain via smart card 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)

Continue reading "Smart card logon 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)""

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 used the PSCertificateEnrollment Powershell Module to demonstrate the procedure. However, with certreq and certutil Microsoft already ships perfectly suitable pentesting tools directly with the operating system ex works.

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

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 close a vulnerability in Active Directory that affects certificate-based logon (commonly known as PKINIT or also smart card logon ).

The update changes both the behavior of the certification authority as well as the behavior of Active Directory when processing certificate-based logons.

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

Force domain controllers (or other participants) to use an Online Responder (OCSP)

By default, Windows systems, even if an Online Responder (OCSP) is configured, will fall back to a certificate revocation list (if available) after a certain number of OCSP requests , because this is usually more efficient in such a case. However, this behavior is not always desired.

For example, if one uses smart card logons, one might want to know if logons were performed with certificates issued without authorization . In conjunction with the deterministic good of the Online Responder you can thus create an (almost) seamless audit trail for all smart card logons.

Continue reading "Force domain controllers (or other participants) to use an Online Responder (OCSP)"

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.

Continue reading "Configuring a Certificate Template for Domain Controllers"

Prevent smart card logon to the network

Installing Active Directory Certificate Services in the default configuration automatically configures the environment so that smart card logons are accepted by the domain controllers.

Therefore, if the use of smart card logons is not desired, it makes sense to disable the functionality in order not to jeopardize Active Directory in the event the certification authority is compromised.

Continue reading "Prevent smart card logon to the network"

Automatically change passwords for accounts that require logon via smart card or Windows Hello for Business

A new feature of Windows Server 2016 is that the passwords for accounts that require pure logon with smart cards are automatically renewed according to the password policies.

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).

Continue reading "Automatically change passwords for accounts that require logon via smart card or Windows Hello for Business"

Using Authentication Mechanism Assurance (AMA) to secure the logon of administrative accounts

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 on using a strong authentication method (i.e., a smart card). If the user logs on 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 on with a username and password, and to have administrative rights when logging on with a certificate.

Continue reading "Using Authentication Mechanism Assurance (AMA) to secure the logon of administrative accounts"

Logon 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 uses it to log on to the Active Directory domain.
  • The logon fails. The following error message is returned to the user on their computer:
Signing in with a security device isn't supported for your account. For more info, contact your administrator.

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

Configuring a Certificate Template for Authentication Mechanism Assurance (AMA)

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

If the user does not log on with the smart card 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.

Continue reading "Configuring a Certificate Template for Authentication Mechanism Assurance (AMA)"

Logon via smart card 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 uses it to log on to the Active Directory domain.
  • The logon fails. The following error message is returned to the user on their computer:
The revocation status of the authentication certificate could not be determined.

Continue reading "Logon via smart card fails with error message "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 smart cards. Below is a brief guide on how to set up a virtual smart card in a Hyper-V guest using a virtualized Trusted Platform Module (TPM).

Continue reading "Creating a virtual smart card in a Hyper-V guest system"

Editing the NTAuthCertificates object in Active Directory

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

Continue reading "Editing the NTAuthCertificates object in Active Directory"