As part of our internal penetration tests, we regularly encounter AD CS (Active Directory Certificate Services) infrastructures deployed on corporate networks.

This component always catches our attention, as inadequate configuration can quickly pave the way for total compromise of the Active Directory domain.

Unfortunately, AD CS is often deployed without the necessary security precautions. This lack of rigour provides opportunities for attackers. In 2021, several studies highlighted the risks associated with AD CS. Research by SpecterOps demonstrated how to exploit misconfigured deployments. In the same year, the PetitPotam vulnerability was revealed. It allows an unauthenticated attacker to compromise an entire domain via AD CS.

We will go into more detail about specific AD CS vulnerabilities and exploitation techniques (particularly ESC attacks) in a future article. This article focuses on the operating principles of AD CS, its role in an Active Directory environment, and the certificate management mechanisms it implements.

Comprehensive Guide to Active Directory Certificate Services

What is Active Directory Certificate Services?

In an Active Directory environment, Active Directory Certificate Services (AD CS) is Microsoft’s implementation of public key infrastructure (PKI). This service manages encryption mechanisms, digital certificates, and electronic signatures.

With AD CS, it is possible to enhance the security of exchanges and authentications by associating the identity of a user, machine or service with a corresponding private key. Put simply, AD CS is used to issue, manage and revoke digital certificates.

AD CS relies on several key components:

• The Certification Authority (CA): at the top of the PKI hierarchy, it is responsible for signing certificates. The Root CA, often kept offline for security reasons, can be integrated into Active Directory; this is referred to as an Enterprise CA.
• The Subordinate Certification Authority (Subordinate CA): it handles the issuance, management and revocation of certificates on a daily basis. Unlike the Root CA, it is kept online.
• Certificate Distribution Points (CDPs): these host Certificate Revocation Lists (CRLs), which are used to check whether a certificate is still valid or has been revoked.
• The Online Responder service: this uses the Online Certificate Status Protocol (OCSP) to provide a quick response on the status of a certificate.
• Clients: these are the entities (users, machines, services) that use certificates to authenticate themselves, encrypt data or sign documents.

Understanding the AD CS architecture is all well and good. But from the outset, we have been talking about certificates. It is therefore relevant to take a closer look at what they contain, how they are generated and why their integrity is so crucial.

Key information from a certificate

Certificates issued by AD CS comply with the X.509 standard (RFC 5280). Each certificate includes a set of standard fields, including:

• Certificate version: indicates the version of the X.509 format (usually version 3).
• Serial number: uniquely identifies each certificate issued by a CA. This number is used in particular during revocation.
• Issuer: the authority that issued the certificate, expressed as a Distinguished Name (DN), for example DC=local, DC=essos, CN=ESSOS-CA.
• Validity period: the time period during which the certificate is valid (start date and expiry date).
• Subject: the entity to which the certificate is assigned, also in the form of a DN, e.g. DC=local, DC=essos, CN=Users, CN=khal.drogo.
• Public key: associated with the certificate subject, it is used to encrypt data and verify signatures.
• Certificate signing: this is produced by the issuing CA to guarantee the integrity of the certificate and prevent any falsification.

Please note that simply possessing the certificate does not allow you to authenticate yourself on a service or request a TGT ticket, as you must also have the private key.

Certificate extensions

An X.509 certificate issued by AD CS is not limited to basic information alone. It also includes a set of extensions, which play an essential role in defining authorised uses and in strengthening (or not) security.

These additional fields provide advanced functionality, but they are also a gateway for attackers.

Among the most commonly encountered extensions, some deserve special attention.

Key Usage

Key Usage (1) specifies the cryptographic operations that the certificate is authorised to perform.

The X.509 standard defines nine possible uses, such as digital signature, key encryption, certificate signature, and revocation list signature.

This field therefore allows the technical use of the certificate to be restricted or, conversely, expanded.

Extended Key Usage (EKU)

Extended Key Usage (2) further refines the possible uses by specifying the intended application use cases for the certificate.

These include, for example, the values ‘Client Authentication’, ‘Email Protection’ and ‘Smartcard Logon’. These indications allow certificate consumer services to verify that the certificate presented corresponds to the expected context.

Incorrect configuration of these EKUs can have serious consequences, in particular by allowing a certificate to authenticate to services to which it should not have access.

Subject Alternative Name (SAN)

The Subject Alternative Name (2) extension completes the identification of the entity holding the certificate.

It allows secondary identifiers to be added, such as DNS names or UPNs (User Principal Names). This flexibility is particularly useful in web server certificates or in authentication scenarios where the same certificate must be recognised under multiple identities.

Again, an overly permissive configuration can create opportunities for an attacker, for example by allowing the spoofing of a critical DNS name.

File formats

It is impossible to overlook a crucial element of certificates: file formats.

During our audits, we often encounter file extensions that are as varied as they are mysterious: .pem, .crt, .pfx, etc.

p12/pfx

The .p12 format (or .pfx on Windows) is certainly the most widely used when it comes to managing user certificates.

Described in RFC 7292 (PKCS #12), this format has an interesting feature: it contains both the X.509 certificate and the associated private key. And to avoid unpleasant surprises, the whole thing is protected by a password.

On Windows, .pfx is the historical standard imposed by Microsoft, but in reality, .p12 and .pfx are technically identical.

On a Linux system, they can be easily inspected or converted with openssl:

# Display the contents of a .p12/.pfx file
openssl pkcs12 -in certificate.p12 -info

# Extract the certificate without the private key
openssl pkcs12 -in certificate.pfx -clcerts -nokeys -out certificate.pem

pem/crt

The .pem and .crt extensions refer to files containing only the public certificate, without the private key.

• The .pem extension is the most explicit: it is a Base64 encoding, framed by the famous tags -----BEGIN CERTIFICATE----- and -----END CERTIFICATE-----.
• The .crt extension, on the other hand, is a little more ambiguous: it can refer to a certificate encoded in Base64 (like a .pem) or in pure binary (DER format). In practice, it all depends on the context of use.

To read the contents of a .pem or .crt certificate, the following command is sufficient:

openssl x509 -in certificat.crt -text -noout

After exploring the general functioning of AD CS and the structure of a certificate, one key question remains: how are these certificates generated?

AD CS certificate templates

To better understand, let’s imagine that certificates issued in a domain are comparable to access badges. These badges allow users to prove their identity, access certain resources, or authenticate services.

Rather than designing each badge manually, standard models, called templates, are established. For example, there is a template for visitors, one for employees, one for administrators, etc.

Each template specifies a set of characteristics such as:

• Associated authorisations (access to certain resources or services)
• The certificate’s validity period
• The criteria for issuance
• And the entities authorised to make a request based on this template

In AD CS, templates are used to standardise the issuance of certificates, automate their deployment, and control their use according to the roles and needs of users or machines. In other words, they ensure that each user receives a certificate that precisely matches their profile.

But be careful: a poorly configured template can quickly become a vector for attack. If, for example, the template intended for visitors accidentally allows privileged access to critical systems, then any user with that certificate could take advantage of it.

Template properties

Template properties are identified by OIDs (Object Identifiers). These properties precisely determine the conditions for issuing a certificate, its use and the associated rights.

Each template is defined by:

• An internal name, used by the certification service for management purposes, and a more readable full name, intended to facilitate identification by administrators.
• A version number, allowing changes to be tracked.
• And a type, indicating whether it is a certificate intended for a particular user, machine or service.

Two parameters are key to the certificate’s lifespan:

• The validity period, generally expressed in months or years.
• The renewal period, which determines when a certificate can be renewed before it expires. This mechanism makes it possible to anticipate service interruptions and avoid manual management of renewals.

Access rights to a template are managed via an ACL (Access Control List). This allows, for example, certain users or groups to request a certificate via the ‘Enroll’ right, or to enable automatic issuance via the ‘Autoenroll’ right, which is often used for machines or accounts integrated into Active Directory. The ‘Read’ right, on the other hand, gives access to read the template properties.

Another key element is how the subject name is defined. This name represents the identity that will appear in the final certificate. It can be constructed automatically from the Active Directory attributes of the user or machine, or entered manually.

Finally, templates include extensions that specify what the certificate is authorised to do.

• The ‘Key Usage’ extension, identified by OID 2.5.29.15, defines the cryptographic operations permitted, such as digital signing or encryption.
• For its part, ‘Extended Key Usage’ (OID 2.5.29.37) specifies the application uses of the certificate. For example, it can indicate that a certificate is intended for client authentication (OID 1.3.6.1.5.5.7.3.2) or for connection via smart card (OID 1.3.6.1.4.1.311.20.2.2).

AD CS certificate issuance process

After exploring how certificate templates are defined, it is time to look at the actual process of issuing a certificate by AD CS.

Preparing the request

The starting point is always on the client side, whether it is a user or a machine.

The client generates a pair of cryptographic keys: a private key, which is kept securely on the local machine, and a public key, which is intended to be shared. At the same time, the client creates a certificate request, known as a CSR (Certificate Signing Request).

This file contains all the information necessary for the certification authority to issue a valid certificate: the applicant’s identity, intended uses, extensions, and of course the public key.

It is essential to emphasise that the private key never leaves the client. Only the public key is included in the CSR, which is a fundamental security guarantee in the process.

Sending the request

Once the request is ready, the client sends its CSR to the certification authority, in this case AD CS, for processing.

This operation can be performed automatically, depending on the system configuration and the rights assigned to the client.

Before issuing a certificate, AD CS performs a series of rigorous checks.

• First, it ensures that the requested certificate template exists and is active.
• Next, it checks whether the client has the necessary permissions to use this template, in particular the ‘Enroll’ or ‘Autoenroll’ rights, as defined in the template.
• Finally, AD CS examines the content of the request itself to ensure that it complies with the constraints defined in the template: Subject Name, uses, extensions, etc.

Issuance or rejection of the certificate

If all conditions are met, AD CS proceeds to create the certificate. It signs it using its own private key, thereby guaranteeing the authenticity of the document, and then transmits it to the client.

However, certain additional security settings can alter this process or prevent its automatic completion. There are two protections in particular that are often overlooked, yet crucial.

• The first is manual approval by an administrator, known as CA certificate manager approval. When enabled, each request must be reviewed and approved manually.
• The second concerns authorised signatures. It is possible to configure a certificate template to require that each CSR be signed by a certificate issued by a specific authority. This requirement is equivalent to requesting hierarchical validation, as if every access request had to be approved by a security manager.

In the context of an Active Directory penetration test, both of these mechanisms must be absent for exploitation scenarios to be valid. Fortunately (or unfortunately, depending on your point of view), in the environments we audit, these protections are rarely implemented.

Storage of the certificate

Once the certificate has been issued, it is automatically stored on the client workstation in the Windows Certificate Store. It is then immediately available for its intended uses: authentication, electronic signing or encryption.

This certificate thus becomes a central element in the secure operation of the Active Directory environment.

How certificate mapping works

Certificate mapping refers to the process by which a domain controller (DC) associates a received certificate with a user or machine account in Active Directory.

This mechanism can be implicit or explicit, and classified as strong or weak, depending on the level of verification performed.

Implicit and explicit mapping

In the case of implicit mapping, the DC relies on the content of the certificate itself to identify its holder.

It begins by extracting the Subject Alternative Name (SAN) attribute. If it is a user certificate, it attempts to match the otherName entry of type UPN (User Principal Name) with the userPrincipalName attribute in AD. If this attempt fails, it checks the sAMAccountName attribute, or even the latter suffixed with a dollar sign ($) in the case of machine accounts. For a machine certificate, the DC uses the dNSName value and searches for a match with the dNSHostName attribute of the corresponding object. If this fails, the same checks as for a user certificate can be applied.

Explicit mapping, on the other hand, is based on a manual association between a certificate and an AD account.

This is recorded in the altSecurityIdentities attribute of the object concerned. This method offers precise control over which certificates are authorised, but involves more cumbersome management.

Weak mapping, strong mapping and security

The distinction between weak and strong mapping is based on the level of trust placed in the information extracted from the certificate.

Weak mapping simply involves associating a certificate with an account based on fields such as the UPN or DNS Name, without any real identity verification. This opens the door to attacks, particularly if an attacker manages to obtain a certificate with a forged SAN.

To counter this, in May 2022, following the Certifried vulnerability (CVE-2022-26923), Microsoft introduced several mechanisms to strengthen strong mapping:

• Certificates now include a szOID_NTDS_CA_SECURITY_EXT security extension (OID 1.3.6.1.4.1.311.25.2), containing the objectSid of the requesting user. This field, unique to each AD user, allows the DC to accurately verify the identity of the bearer.
• However, this verification can be bypassed if the certificate template is misconfigured. By enabling the CT_FLAG_NO_SECURITY_EXTENSION flag (0x80000) in the msPKI-Enrollment-Flag attribute, the security extension is disabled, returning the mapping to weak mode.
• Two registry keys can be configured on DCs to reinforce this behaviour: CertificateMappingMethods, which controls the mapping method for TLS/SSL (Schannel) authentication, and StrongCertificateBindingEnforcement, which enforces certificate owner verification.

Practical consequences and current stance

Since May 2022, properly updated and configured Active Directory environments can enforce strong mapping, making it much more difficult for an attacker to exploit certificates.

In practice, however, these security measures are rarely enabled, either due to lack of knowledge or to avoid administrative overload.

As a result, weak implicit mapping remains the default configuration in most audited environments. Combined with poor certificate template configuration, this constitutes a particularly attractive attack vector, exploited by attackers to steal identities and compromise entire systems.

Conclusion

Active Directory Certificate Services (AD CS) plays a central role in managing identities, access, and trust within Windows environments. By enabling the issuance, management, and revocation of digital certificates, it is the cornerstone of many security functions.

In this article, we explored the key components of AD CS and how certificate templates work. These elements, which often remain in the background of users’ daily lives, are nevertheless essential to the security and proper functioning of the Active Directory infrastructure as a whole.

AD CS infrastructures are still too often poorly secured. As we have seen, a simple misconfiguration (e.g., a permissive template) can give an attacker privileged access to the most sensitive systems.

In a future article, we will take a detailed look at common vulnerabilities related to AD CS, the specific attack scenarios that result from them, and best practices for effectively securing this often underestimated but highly strategic component.

Author: Adrien HOC – Pentester @Vaadata