The Missing Introduction of Active Directory Certification Services

· 1464 words · 7 minute read
Sysadmin Windows PKI

ADCS is a widely-used online CA due to its tight integration with Windows and ADDS. However, many administrators new to ADCS will get lost in its old Windows 2000 UI, poor management tools, and lack of documents. In fact, lots of ADCS options are only available through registry or command line, and a number of CA configuration is done one-time using the CAPolicy.inf file. Moreover, it was born in the Windows 2000 era when Microsoft was focusing on selling its training programs (?) rather than writing easy-to-understood docs, and MS never updated the docs for ADCS until today. This blog summarizes the key architecture of ADCS, and hopefully readers can easily understood this legacy software.

Before going forward, make sure you understand the basics of X.509 PKI. I highly recommends you to take a look at https://smallstep.com/blog/everything-pki/, a beginner-friendly introduction to X.509. Although it lacks lots of key features of X.509 (for example, AIA; Delta CRL; X.509 OIDs like CA Policies, Key Usage, Extended Key Usage; CA Constraints like pathlen), it still gets you started.

You should now be familiar with X.509, and you can setup a two-tier CA with OpenSSL on your own (probably with some online configuration samples). You can also generate CSR and issue a leaf certificate.

Now let’s get started. An online CA is actually a server program that automatically issues certs upon clinet requests. It will necessarily validate client information and CSR (for example, the famous LetsEncrypt CA needs to verify your HTTP server or DNS TXT records), fill in necessary X.509 fields (for example, subject, extended key usage, subject alternative names, CRL distribution points), and sign the certificate with the CA private key then return the signed certificate back to the client. This is completely same as you issue a certificate yourself using OpenSSL, but fully automated. The online CA deploys several CA policies (or templates) that controls how it validates signing request and fills in the final certificate. This varies case-by-case. Let’s say your CA is signing for both HTTPS certificates and VPN certificates. The former must not accept requests from ordinary users (i.e., only web server admins can issue this kinds of certs), and the resulting certificate must contain SAN matching the DNS name. The later, however, should accept any user needing the corporate VPN to get a certificate, and the final cert, e.g., contains necessary information to bind to the client user (for example, the subject name is the user’s name in LDAP directory). The online CA will also maintain CRL and / or OSCP to ensure that revocation information is up-to-date.

ADCS is such an online CA software. It does everything above, but with tight integration with ADDS and other (proprietary) Windows components and protocols.

LDAP #

ADCS highly integrates with the LDAP directory (ADDS, of course). It stores certificate templates, AIAs (optional), CSRs (optional), CA server info (helps the clients to locate the server) into LDAP. Everything is stored at the configuration naming context / services: CN=Public Key Services,CN=Services,CN=Configuration,DC=YOUR,DC=DOMAIN,DC=COM. Unless noted, all LDAP references below are within that base DN.

ADCS server / Enrollment service #

During enterprise CA provision (?), ADCS server will register itself into LDAP, so clients will be able to find it. They register themselves as the pKIEnrollmentService in CN=Enrollment Services. It contains the enabled templates (see the following section), server DNS hostname, CA certificate, and other attributes.

Templates #

As described above, templates define how the CA gathers and validates info of the client and how the CA puts info into the cert. ADCS templates support the AD ACL, so you can specify who is allowed to read and change the template, as well as who is allowed to enroll and autoenroll (see below) certificates from that template.

Default templates can only be duplicated rather than deleted to make changes.

Templates are identified by name (?) in the issued certificates, in extension OID 1.3.6.1.4.1.311.21.7.

In ADCS, templates are shared in the whole domain, rather than for a specific ADCS server. Templates are pKICertificateTemplate objects in CN=Certificate Templates. Not all templates are enabled on the CA, and the admin can configure what templates are enabled on the specific CA server. Clients can only request certificates from enabled templates. The enable relationships are stored in pKIEnrollmentService objects of the target CA.

You can go to the “Certification Services” MMC and navigate to “Certificate Templates” to manage the enabled templates for that CA. You can right-click to manage templates for the whole domain.

It is common for two CAs in a domain having the same template. Windows certlm MMC will give user a choice when issuing certificates.

AIA and CRL publishing #

ADCS can be configured to publish AIA and CRL into many different locations, including LDAP (AD) and file system. It can also be configured to include custom locations in issued certificates. In many cases, issued certificates require HTTP (public) CDPs which ADCS cannot publish themselves. In these cases, ADCS can just include the CDP rather than publishing anything.

You can right-click the server name in ADCS MMC and configure the publish URLs. The URLs contain many placeholders like the CA name, delta CRL indicator, server hostname, etc. These configurations are actually the CRLPublicationURLs and CACertPublicationURLs registries.

You can publish AIA and CRL into AD. They are at CA=AIA and CA=CDP accordingly.

Windows PKI CA cert fetching #

In Windows networks, it is common practice for all computers to contain the full certificate chain in their certificate store rather than supplying the full chain every time.

Upon each gpupdate, the Windows certificate client will automatically copy all root CA and intermediate CA from LDAP into the Local Machine > Intermediate Certification Authorities store. I am not sure whether it got the certs from published AIA (in AD) or CN=Enrollment Services. Windows will only add new certificates but not delete anything. If you need to delete an old CA certificate, you can deploy a script yourselves.

Windows will also fetch root CA from the CN=Certification Autohrities LDAP container, where trusted root CAs are stored. Enterprise admin can publish the root CA here using certutil -dspublish -f rootca.crt RootCA. This cert will be copied to the Local Machine > Trusted Root Certification Authorities store during gpupdate.

Client certificate enrollment protocol #

ACME is a widely-used enrollment protocol that defines the way clients (e.g., web servers, VPN clients) automatically communicate with the CA server to request certificates by sending CSR and other necessary verification info.

ADCS natively supports a proprietary protocol that only works on Windows (at least currently). It is a DCOM+ service, defined in MS-WCCE. Natively, it uses ADDS authentication.

The client can request certificates in many ways:

  • Use the GUI: Open “Manage Computer Certificates” (certlm.msc) or “Manage User Certificates” MMC, navigate to Personal > Certificates, right click and select All Tasks > Request New Certificate. It will automatically fetch available templates (enabled and have permission, described later) and allows you to select a template and type necessary information (as required by the template). You can select a CA if multiple CAs have the selected template.
  • The MMC also supports generating private key and CSR without enrollment. enrolling. Just click on “Create Custom Request” and do your own. I used to use this method to request HTTPS certificates from Let’s Encrypt.
  • Use certreq.exe: You need to manually write a config file defining the CSR.
  • Use Get-Certificate: It is newer than certreq and is much more easyer to use, but it only supports a limited number of options. This cmdlet requests certificate using the machine account if ran as admin, so please check your template ACL if ADCS denied your request.
  • Auto enrollment: If the machine or user (I’m not sure if user works) have the “Auto enroll” permission on an enabled template, it will automatically enroll during gpupdate.

I am not sure about AD enrollment policies.

ADCS does support SCEP and web enrollment by installing additional roles.

Debug tools #

Lastly, I wanna introduce some cool debug tools to help you diagnose your PKI and CSR issues.

  1. pkiview.msc: The all-in-one MMC that shows all CA servers in your domain and validates all CSRs and AIAs.
  2. certutil -URL: A nice (but old) dialog that validates all CSRs, AIAs, and OSCPs in the whole PKI tree from the given leaf certificate. Note that it does NOT use schannel, the TLS library on Windows. TLS clients may behave differently.
  3. curl -v https://: cURL(1) uses schannel on Windows, so it is a nice tool to test TLS handshake.
  4. ADExplorer / ADSI Edit: The GUI ldap editor for ADDS. You can discover the ADCS directory objects on your own.
  5. OpenSSL: You can use the openssl xxxxx -text command to investigate any certificate, CSR, or CRL.

Hopefully this blog post gives you a better understanding on ADCS.