Components of a PKI, Part 4: Active Directory Certificate Services

Preface: Components of a PKI

Public key infrastructure (PKI) is a core technology in the identity and security stack. This technology uses encryption to allow entities such as an individual or device to be uniquely identifiable and able to store or transmit information securely. All modern organizations use PKI in some form or another. The digital certificate on a website that protects customers’ privacy and data is an example of PKI in action.

Fortunately, the fundamentals haven’t changed significantly since PKI was formally introduced in the X.509 standard in 1988. In this five-part blog series, we cover a few of the most important PKI components:

  1. Digital Certificates
  2. Certificate Authorities and CA Hierarchies
  3. Certificate Revocation
  4. Active Directory Certificate Services
  5. Hardware Security Modules

Part 4: Active Directory Certificate Services

Not all organizations require their own PKI solution; however, most leverage Microsoft Active Directory Certificate Services (AD CS) because it integrates directly with their existing Active Directory (AD) environment.

Many of these organizations have IT administrators managing a wide range of infrastructure and service providers. Often, AD CS is deployed quickly by internal IT or external consultants to meet an immediate business need, such as issuing certificates to support the new Cisco wireless solution. The unfortunate outcome is that a substantial number of internal IT departments don’t have the resources to revisit their AD CS solution after the initial setup to update documentation or retrain staff.

If this sounds familiar, or if you just want to refresh your memory on how AD CS works, keep reading!

Types of AD CS Certification Authorities

When deploying AD CS, the IT administrator must choose between an enterprise CA and a standalone CA.

When building an enterprise CA, the CA configuration is automatically published in the AD forest for domain-joined users and computers to find. As Figure 1 shows, the option to build an enterprise CA is unavailable if the server isn’t domain-joined. After clicking “Next” in the dialog box, the administrator will have the option to choose whether the CA will be a root CA or a subordinate CA. For a refresher on CA types, check out Part 2 of our “Components of a PKI” blog series.

Figure 1 AD CS configuration

Enterprise CA

Enterprise CAs must be domain-joined and integrate directly with AD to provide the following critical features:

  • Certificate templates(predefined permissions/properties for certificate issuance)
  • Certificate auto-enrollment (automatically request/renew certificates using templates)
  • Key archival (escrow private key on behalf of end-entity)
  • CA automatically trusted by AD members (CA certificate published in AD)

Standalone CA

Standalone CAs are typically offline root CAs or offline intermediate CAs. Without certificate templates, auto-enrollment, or key archival, all certificate issuance must be performed manually by the CA manager by submitting certificate requests to the standalone CA, approving the certificate issuance, and transferring the public certificate to the requester.

Public Key Services Container in AD

The Public Key Services container is leveraged for the following:

  1. Central repository for all AD CS configuration information
    1. a. Located in the configuration naming context in the forest root domain
    1. b. Replicates between all domain controllers in the forest
  2. Distributing trusted root/intermediate CAs to domain-joined clients
  3. If configured for auto-enrollment, clients will attempt to find an enterprise CA in the Enrollment Services container and auto-enroll for any available published certificate templates

The easiest way for a beginner to view their existing AD CS configuration(s) in AD is to launch the pkiview.msc tool, right-click Enterprise PKI, and launch “Manage Templates” and “Manage AD Containers,” as Figure 2 shows.

Figure 2 Launching the pkiview.msc tool

Alternatively, you can explore the Public Key Services container using the ADSI Edit tool (ADSIEDIT.msc). Figure 8 and Figure 15 show an example.

Certificate Templates Container

Certificate templates are used to automate certificate deployment by defining the common properties among all certificates issued based on that template and configuring permissions for which users or computers can enroll or auto-enroll for the certificate. An example of this would be a certificate template that auto-enrolls all domain users with valid email addresses for a secure email (S/MIME) certificate.

All certificate templates available in AD, regardless if they are published on an enterprise CA or not, are stored in the Certificate Templates container. If an enterprise CA publishes a certificate template, the value is written as an attribute on the CA object in the Enrollment Services container, as Figure 8 shows. By default, over 30 Microsoft predefined certificate templates are installed when building an enterprise CA. Your organization will likely have a mixture of the default Microsoft certificate templates and custom certificate templates, as Figure 3 shows.

Figure 3 Certificate Templates console

Certification Authorities Container

The Certification Authorities container is for trusted root CAs, as Figure 4 shows. The certificate is deployed automatically in the container during the creation of an enterprise root CA. To build a PKI with an offline standalone root CA (to support an enterprise subordinate CA), the PKI administrator must manually publish the offline root CA certificate using certutil -dspublish -f ExampleRoot.cer RootCA.

Figure 4 Certification Authorities container

Additionally, all certificates in the Certification Authorities container are deployed to the Certificates – Local Computer\Trusted Root Certification Authorities\Enterprise\Certificates store of domain-joined clients via Group Policy, as Figure 5 shows.

Figure 5 Trusted root Certification Authorities deployed via Group Policy

Enrollment Services Container

The Enrollment Services container is reserved for enterprise CAs. Like the Certification Authorities container, the certificate of an enterprise CA is automatically installed in this container when building an enterprise CA, and the certificates in the Certification Authorities container are deployed to the Certificates – Local Computer\Intermediate Certification Authorities\Enterprise\Certificates store of domain-joined clients via Group Policy, as Figure 6 shows.

Figure 6 Intermediate CAs deployed via Group Policy

As Figure 7 and Figure 8 show, domain-joined clients will automatically find (and potentially auto-enroll if configured accordingly) all enterprise CAs published in the Enrollment Services container in AD, as well as their published templates.

Figure 7 Enrollment Services container
Figure 8 Enrollment Services container and published templates (certificateTemplates) attribute

NTAuthCertificates

The NTAuthCertificates object contains CA certificates permitted for implementing smart card logon and AD CS private key archival, as Figure 9 shows. In the smart card logon example, the issuer of a domain controller certificate processing the smart card logon and Key Distribution Center (KDC) authentication must be included in the NTAuthCertificates store, or the smart card logon will fail. In the AD CS private key archival example, the client can’t enroll a certificate from a certificate template with private key archival enabled if the enterprise CA certificate isn’t included in the NTAuthCertificates store.

Like the Certification Authorities container, the certificate of an enterprise subordinate CA is automatically installed in this container. All certificates in the NTAuthCertificates container are deployed to the Certificates – Local Computer\Intermediate Certification Authorities\Enterprise\Certificates store of domain-joined clients via Group Policy, as Figure 6 shows, above.

Figure 9 NTAuthCertificates object

AIA Container

The Certification Authorities container is for intermediate CAs and cross-certificates, as Figure 10 shows. Like the Certification Authorities container, the certificate of an enterprise subordinate CA is automatically installed in this container. All certificates in the AIA container are deployed to the Certificates – Local Computer\Intermediate Certification Authorities\Enterprise\Certificates store of domain-joined clients via Group Policy, as Figure 6 shows, above.

Figure 10 AIA container

CDP Container

The CDP container contains LDAP Uniform Resource Identifiers (URIs) for certificate revocation lists (CRLs). LDAP CRLs are automatically published in the CDP container after the installation of an enterprise CA. As Figure 11 and Figure 12 show, the Tailspin Toy Co. lab has removed the LDAP URIs and is configured with HTTP URIs instead.

Figure 11 CDP container
Figure 12 HTTP CRLs

KRA Contain

The KRA container is for Key Recovery Agent certificates. The container is updated automatically during a valid issuance from the KRA certificate template. As Figure 13 shows, the Tailspin Toy Co. lab doesn’t have any KRA certificates configured.

Figure 13 KRA container

OID Container

New Object Identifiers (OIDs) can be registered when creating new application policies or issuance policies, as Figure 14 shows. The ADSI Edit tool (ADSIEDIT.msc) can be used to view all the OIDs in a flat structure, as Figure 15 shows.

Figure 14 Adding application policies or issuance policies
Figure 15 Using ADSI Edit to explore OIDs

Final Remarks: Active Directory Certificate Services

Due to complexities with deploying or deprovisioning AD CS, many organizations have orphaned or misconfigured AD CS deployments in their AD forest. If you’re managing an AD environment and are concerned that you may have inherited an AD CS configuration that no longer meets best practice standards, contact Ravenswood Technology for expert help.

Read more in Part 5 of this blog series: Hardware Security Modules.