Diving Into AD CS: Exploring Some Common Error Messages

Abuse of Active Directory Certificate Services (AD CS) has become a staple of our internal network assessment methodology. In fact, I can’t recall an internal I’ve done in the past two or more years that didn’t feature ADCS abuse in some manner or another.
We can all agree that when AD CS abuse works as intended, it is fantastic. As Tinus Green stated in his BSides talk, AD CS abuse is the teleport scroll to the top of the mountain. It allows us to rapidly gain high-privileged access to the domain and, from there, can target more lucrative objectives.

Abuse of Active Directory Certificate Services (AD CS) has become a staple of our internal network assessment methodology. In fact, I can’t recall an internal I’ve done in the past two or more years that didn’t feature ADCS abuse in some manner or another.

We can all agree that when AD CS abuse works as intended, it is fantastic. As Tinus Green stated in his BSides talk, AD CS abuse is the teleport scroll to the top of the mountain. It allows us to rapidly gain high-privileged access to the domain and, from there, can target more lucrative objectives.

Unfortunately, the inverse is also true. One often encounters errors while attempting to abuse AD CS. Certificate templates might be slightly misaligned with the true misconfigurations, or user privileges might be disallowing minor steps. Not to mention that the client’s Active Directory environment could have sophisticated security solutions present, blocking the abuse—looking at you, Semperis.

Tooling such as Certify and certipy have evolved to provide more descriptive error messages lately. Yet, they still leave a lot to be desired. Often, when you encounter an error with these tools, it’s somewhat ambiguous and unclear what caused it. Is it one of the many flags I mistyped, the domain credentials I got the syntax wrong, or am I not correctly connecting to the CA server? Add in the complexity of remote testing via a VPN and SOCKS proxy, and you are in a world of hurt trying to diagnose what is going wrong.

During two recent internal assessments, I encountered several error messages (see below) that outright baffled me. The certificate templates checked out, my domain privileges were as expected, and tool invocation was aligned with how I’ve used them before—or, simply, I copied/pasted a known-good command. So… why were I getting these, and what do they mean?

Got error while trying to request TGT: Kerberos SessionError: KDC_ERR_INCONSISTENT_KEY_PURPOSE(Certificate cannot be used for PKINIT client authentication)

Got error while trying to request TGT: Kerberos SessionError: KDC_ERROR_CLIENT_NOT_TRUSTED(Reserved for PKINIT)

Got error while trying to request TGT: Kerberos SessionError: KDC_ERR_PADATA_TYPE_NOSUPP(KDC has no support for padata type)

While it would have been easy to dismiss the error messages and move on to the next tool or concept, I decided to investigate this further. I wanted to replicate the exact error messages in my test Active Directory lab, which would give me insight into what was causing them and what they represented.

In this blog post, I’ll share the insights I gleaned from my test AD lab. It will start with a basic overview of the AD CS certificate request sequence and then pivot to the PKINIT authentication process. With the foundation established, it will showcase individual scenarios for how the error messages mentioned above could occur.

*Note: A large portion of the research and blog post content showcased here is inspired by Will Schroeder and Lee Christensen’s original AD CS whitepaper and more recent blog post. The PKINIT explanation is largely attributed to @_ethicalchaos_ attacking smart card based Active Directory networks blog post.*

A Foundational Understanding of AD CS: A Quick 101 Introduction

AD CS is a server role that functions as Microsoft’s public key infrastructure (PKI) implementation. As expected, it integrates tightly with Active Directory. It enables issuing certificates, which are X.509-formatted digitally signed electronic documents that can be used for authentication (the central area of focus for us in this blog post).

It can be misleading, but the last sentence above hints towards two separate processes that contribute to how AD CS actually works:

• There is a process for generating the certificate, which is typically where certificate templates and requests come in.

• There is a separate authentication process that occurs with an issued certificate—this is where PKINIT authentication occurs.

Certificate Issuance

In Will Schroeder and Lee Christensen’s original AD CS whitepaper, they share the below diagram that showcases how the process of generating a certificate is accomplished:

When a domain user or computer wants a new AD CS certificate generated. It first creates a public-private key pair, and the public key is placed in a certificate signing request (CSR) message along with other details, such as the subject of the certificate and the certificate template name. They then send the CSR to the CA server. The CA server then checks if they are allowed to request the certificate. If so, it determines if it will issue a certificate by looking up the certificate template AD object. If permitted, the CA generates and signs the certificate using its private key and returns it to the user/computer.

From the description above, the CA performs two initial checks based on the CSR that is being received:

• It checks if the user or computer can request certificates—this is typically done as an SMB authentication request to the ‘\pipe\cert’ RPC endpoint.

• It checks whether the user or computer is allowed to receive the certificate based on the certificate template’s properties—this is typically referred to as the policy module check.

Error messages pertaining to the first step above are typically relatively easy to spot. Here is an example where a CSR has been requested, but the wrong user credentials were supplied:

Notice in the error output how the \pipe\cert RCP endpoint is listed along with a failed SMB connection error.

Error messages regarding the second step are also quite verbose in the latest version of certipy. The tooling was updated recently to indicate that the template disallowed the certificate to be requested:

In the case above, the ESC1 certificate template’s permissions were modified to disallow enrollment as follows:

*Note: Older versions of Certipy or other tooling, such as Certi, still refer to the above issue as a policy module error. Regardless, it ultimately relates to the permissions set on the certificate template.*

While the errors above are related to the certificate’s issuing, it is essential to remember that this is only the first step in the AD CS process flow. When a certificate has been correctly issued, the next step would be authentication.

PKI Authentication

Active Directory largely relies on Kerberos for its authentication purposes. When a user supplies valid credentials, a Ticket-Granting Ticket (TGT) is issued, and later, a Ticket-Granting Service Ticket (TGS) might be issued depending on the service the domain user or computer wants to reach.

Before 2006, certificate-based authentication was not integrated directly into the Kerberos authentication protocol used in Windows environments. Instead, other authentication mechanisms (i.e., SSL/TLS) were used alongside Kerberos to support certificate-based authentication. Users would insert their smart cards into card readers attached to their computers, and the operating system would use the certificates stored on the smart cards for authentication purposes.

Note: AD CS-based certificates are synonymous with smartcard authentication in Windows environments. Thus, one often will see references to smart cards while working with AD CS.

[...]

Original source