AD CS

Overview

Active Directory Certificate Services (AD CS) is a Windows Server role that provides certificate-based authentication and Public Key Infrastructure (PKI) within Active Directory (AD) environments. It operates over TCP 135 and dynamic RPC ports, with optional use of ports 80 and 443 if Web Enrollment is enabled.

AD CS acts as an internal digital ID system for a Windows domain. Instead of printing physical ID cards, it issues digital certificates that users and computers can use to log in, encrypt communications, or sign data. These certificates are trusted across the domain, so if an attacker can trick AD CS into giving them a certificate, it's similar to getting a valid employee badge, i.e., they can impersonate someone and gain access.

Certificate Authorities

A Certificate Authority (CA) is an entity responsible for issuing and managing digital certificates. These certificates are used to verify the identity of entities such as individuals, organizations, or devices and to ensure the integrity and authenticity of data exchanged over networks.

There are two types of CAs:

1. Standalone CAs: These operate independently of AD and are typically used in environments where integration with AD is not required. They manually validate certificate requests and are often used for issuing certificates to external or non-domain entities.

2. Enterprise CAs: Integrated with AD, these CAs automatically issue certificates to domain-joined devices and users. They leverage AD's authentication and authorization features to streamline and automate the certificate issuance process.

Root CAs are the top-most level in the certificate hierarchy and are self-signed by AD CS. They serve as the ultimate trust anchor within a domain, and their certificates are trusted across the entire domain. These Root CA certificates are stored in specific AD containers to establish a trust framework within the network.

A CA essentially acts as the digital equivalent of a notary, validating identities and ensuring secure, encrypted communication between parties.

Digital Certificates

Digital certificates are electronic documents binding a public key to an entity, such as a person, organization, device, or service. These certificates are issued and signed by a CA, which verifies the holder’s identity and the integrity of the public key.

Each certificate includes a public key, subject name, issuer’s name, validity period, and more, formatted as X.509 digitally signed documents.

# List the certificate's attributes
PS C:\Users\Administrator> GCI Cert:\localmachine\My\ | Format-List

Subject      : CN=marvel-DC01-CA, DC=marvel, DC=local
Issuer       : CN=marvel-DC01-CA, DC=marvel, DC=local
Thumbprint   : EAD64F050635552A285A59D1311E11E8B82392B8
FriendlyName :
NotBefore    : 5/31/2025 12:13:55 PM
NotAfter     : 5/31/2030 12:23:55 PM
Extensions   : {System.Security.Cryptography.Oid, System.Security.Cryptography.Oid, System.Security.Cryptography.Oid,
               System.Security.Cryptography.Oid}

Subject      : CN=DC01.marvel.local
Issuer       : CN=marvel-DC01-CA, DC=marvel, DC=local
Thumbprint   : 8D56ACFD2A01D4B31C7599E06D3B4D051ED0D206
FriendlyName :
NotBefore    : 5/31/2025 12:14:29 PM
NotAfter     : 5/31/2026 12:14:29 PM
Extensions   : {System.Security.Cryptography.Oid, System.Security.Cryptography.Oid, System.Security.Cryptography.Oid,
               System.Security.Cryptography.Oid...}

Trusted certificates and related data are organized in several AD containers:

• CAs Container: Stores root CA certificates.

• Enrollment Services Container: Contains information about Enterprise CAs.

• NTAuthCertificates AD Object: Essential for AD authentication.

• Authority Information Access (AIA) Container: Holds intermediate and cross CA certificates.

These containers ensure efficient management and retrieval of certificate-related data within the directory.

Certificate Templates

Certificate templates, referred to as pKICertificateTemplate, offer preconfigured settings tailored for specific purposes. These templates streamline the certificate issuance process by defining necessary parameters and usage scenarios.

Extended Key Usages (EKUs) are a set of enabled Object Identifiers (OIDs) that specify the intended functions of a certificate. They define precise roles for certificates, such as:

• Client Authentication: Ensures secure user verification.

• PKINIT Client Authentication: Facilitates Kerberos authentication with public key cryptography.

• Smart Card Logon: Supports authentication via smart cards.

• Any Purpose: Allows the certificate to be used for any intended purpose.

These templates and EKUs are essential for ensuring that certificates are issued with the correct settings and for their intended use cases.

As operators we are mostly intersted in OIDs that enable AD authentication:

Description	OID
Client Authentication	1.3.6.1.5.5.7.3.2
PKINIT Client Authentication	1.3.6.1.5.2.3.4
Smart Card Logon	1.3.6.1.4.1.311.20.2.2
Any Purpose	2.5.29.37.0
SubCA	(no EKUs)

Enrolment

The certificate enrollment process involves the following steps:

1. Locate an Enterprise CA: Identify the responsible CA.

2. Generate a Key Pair and Create a CSR: Develop a public/private key pair and prepare a Certificate Signing Request (CSR).

3. Sign and Submit the CSR: Sign the CSR with the private key and submit it to the Enterprise CA.

4. CA Verification: The CA verifies the client’s authorization and the CSR's validity.

5. Certificate Issuance: The CA generates, signs, and issues the certificate to the client.

6. Store the Certificate: The client stores the certificate in the Windows Certificate Store.

This streamlined process ensures secure and authenticated certificate issuance.

The certificate enrollment process (image taken from here).

Issuance Requirements

Issuance requirements ensure secure certificate enrolment by enforcing specific conditions:

• Manager Approval: Requires managerial authorization before a certificate is issued, adding an extra layer of oversight.

• Number of Authorized Signatures: Specifies the required number of signatures from authorized personnel, ensuring multiple levels of validation.

These settings help maintain strict control over the certificate issuance process, enhancing security and compliance.

PKINIT

Traditional Kerberos relies on symmetric cryptography: client and KDC share a secret key. During the Authentication Service (AS) exchange, the client proves knowledge of the secret derived from it’s password.

PKINIT (Public Key Cryptography for Initial Authentication in Kerberos) is a Kerberos extension that changes this model. It replaces password-derived proof with asymmetric cryptography (possession of a private key). PKINIT uses X.509 certificates issued by AD CS.

Authenticating with certificates when PKINIT is not supported

In the case where PKINIT is not supported, Schannel can be used.

PKINIT and WHfB

PKINIT is heavily used in Microsoft’s passwordless authentication solution, Windows Hello for Business (WHfB). WHfB allows users to authenticate without typing a password, typically using a PIN, fingerprint, or facial recognition. These factors do not replace the password directly; rather, they unlock a private key stored securely on the user’s device.

When a user enrolls in WHfB, the device generates a public/private key pair. This generation usually happens inside the Trusted Platform Module (TPM), which is a hardware security component designed to protect cryptographic material. The private key is marked as non-exportable and never leaves the TPM. The corresponding public key, however, is safe to share and is registered in AD. This is where the msDS-KeyCredentialLink attribute becomes important. There are two primary trust models in WHfB:

• In Certificate Trust, the device generates a key pair and then requests a certificate from the organization’s CA. The certificate binds the public key to the user’s identity. During authentication, the certificate is presented to the DC.

• In Key Trust, no certificate is required. Instead, the raw public key is stored directly in the multi-valued msDS-KeyCredentialLink attribute of the user object. Each value represents a Key Credential object, meaning a single account can have multiple registered devices, each with its own key pair. The DC, acting as the KDC, retrieves these stored public keys when processing authentication requests and trusts them without needing a CA-issued certificate. This makes Key Trust suitable for environments that do not have a full certificate infrastructure for user authentication.

Key Trust Model

When a user attempts to authenticate using WHfB in a Key Trust deployment, the following occurs:

1. First, the user uses a PIN, fingerprint, or facial recognition to unlock the private key from the TPM on their device.

2. Next, the client sends an AS-REQ to the DC using PKINIT. Instead of including password-based pre-authentication data, the client includes information that proves it possesses the private key corresponding to the registered public key. Cryptographically, this works through digital signatures. The DC sends or references data that must be signed and the client signs this data using its private key. Because only the legitimate device possesses that private key, only it can produce a valid signature.

3. The DC then retrieves the public key from the user’s msDS-KeyCredentialLink attribute and uses it to verify the signature. If the signature validates successfully, this proves that the client holds the corresponding private key. Since asymmetric cryptography guarantees that only the private key holder can generate a valid signature verifiable by the public key, this process replaces the traditional “prove you know the password” step.

4. If verification succeeds, the DC issues a TGT along with a session key.

The critical takeaway is that AD fully trusts any public key stored in msDS-KeyCredentialLink for PKINIT authentication. If an attacker can insert their own public key into that attribute, the DC will treat the attacker’s private key as legitimate authentication material for that account. The attacker can then perform the exact same cryptographic proof process described above and receive a valid TGT. Nothing needs to be cracked or guessed, but the attacker simply needs to register an alternative key pair and uses it as designed.

That is the fundamental weakness exploited by the Shadow Credentials attack.

Certificate Mapping

Certificate mapping is particularly relevant to ESC6, ESC9, and ESC10.

Certificate Mapping in AD establishes an association between a digital certificate and a subject, such as a user or machine. This process is crucial for enhancing security, particularly in response to vulnerabilities like Certifried (CVE-2022-26923).

To address these vulnerabilities, Microsoft introduced a new EKU called szOID_NTDS_CA_SECURITY_EXT, along with two registry keys: StrongCertificateBindingEnforcement and CertificateMappingMethods.

• A new EKU, szOID_NTDS_CA_SECURITY_EXT, that contains the objectSid of the requester.

• The StrongCertificateBindingEnforcement registry key used for Kerberos implicit mapping.

• The CertificateMappingMethods registry key used for Schannel implicit mapping.

Mapping Types

Mapping a certificate to a user can be conducted either explicitly or implicitly:

• In explicit mapping, the altSecurityIdentities attribute of an account must contain the certificate ID, ensuring that the certificate is both signed by a trusted CA and matches the stored value.

• Implicit mapping, on the other hand, relies on information in the certificate's Subject Alternative Name (SAN) to align with the Domain Name System (DNS) or User Principal Name (UPN) fields.

Kerberos Certificate Mapping

When certificates are used during Kerberos authentication, the StrongCertificateBindingEnforcement registry key determines the mapping process. This setting has three modes:

• Disabled Mode (0): No strong certificate mapping is enforced, and szOID_NTDS_CA_SECURITY_EXT is ignored.

• Compatibility Mode (1): The default setting, where the KDC checks for explicit mappings and validates the certificate's EKU. If the EKU is absent, authentication depends on whether the account predates the certificate.

• Full Enforcement Mode (2): This mode enforces explicit mappings and validates the EKU, denying authentication if these conditions are not met.

In Disabled mode, the mapping approach varies based on the certificate's content:

• Certificates with a UPN Value: The KDC first attempts to map the certificate to a user account using the UPN. If this fails, it searches for an account with a matching sAMAccountName. If still unsuccessful, the KDC appends a $ to the UPN to match it with a computer account.

• Certificates with a DNS Value: The KDC separates the username into user and domain components (e.g., poppy.mollysec.local becomes poppy and mollysec.local). The domain is validated against the AD domain, and the user is validated by appending a $ to find a matching sAMAccountName.

In Compatibility or Full Enforcement mode, the mapping uses the szOID_NTDS_CA_SECURITY_EXT to associate the account via its objectSid.

If operating in Compatibility mode and the EKU is missing, the behavior mirrors that of Disabled mode.

Schannel Mapping

Schannel (Secure Channel) is a security package that provides SSL/TLS protocols for secure communication over the network. It's used by Windows systems to authenticate and encrypt data between clients and servers, ensuring secure data transmission. Schannel supports various authentication methods, including certificate-based authentication, and is integral to implementing secure connections in Windows environments.

For Schannel authentication, the CertificateMappingMethods registry key guides the mapping process with different methods for explicit and implicit mappings.

Hex Code	Mapping Type
0x0001	Subject/issuer explicit mapping
0x0002	Issuer explicit mapping
0x0004	SAN implicit mapping
0x0008	S4USelf implicit Kerberos mapping
0x0010	S4USelf explicit Kerberos mapping

The default setting (0x18 → 0x8 and 0x10) combines implicit Kerberos mappings, allowing Schannel to utilize szOID_NTDS_CA_SECURITY_EXT by converting Schannel mapping to Kerberos mapping through S4USelf.

Security Updates and Mapping Modes

Security updates like KB5014754 address vulnerabilities, ensuring stronger mappings and phasing out insecure ones. As of the May 10, 2022, updates, devices default to Compatibility mode, gradually transitioning to Full Enforcement mode by February 2025. This transition ensures certificates are strongly mapped, with the option to revert to Compatibility mode until September 2025.

Strong and Weak Mappings

Certificate mapping types are categorized as strong or weak. Strong mappings use identifiers like X509IssuerSerialNumber, X509SKI, and X509SHA1PublicKey, which are secure and non-reusable. Weak mappings, such as those based on usernames or email addresses, are less secure.

For organizations unable to reissue certificates with the new SID extension, manual mappings using strong identifiers in the altSecurityIdentities attribute are recommended. Administrators can update these attributes using PowerShell commands, ensuring the accurate reversal of serial numbers and maintaining byte order.

AD CS Attacks

The attacks leveraging can be categorised as follows:

Core Issue	ESC
Certificate Templates	1, 2, 3, 9
CA Configuration	6
Access Controls	4, 5, 7
NTLM Relay	8, 11

For AD CS attacks-related information, see here.