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:
- Digital Certificates
- Certificate Authorities and CA Hierarchies
- Certificate Revocation
- Active Directory Certificate Services
- 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 certificates are 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 continue auditing 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 certificate management with AD CS works, keep reading!
Types of AD CS Certification Authorities
When deploying AD Certificate Services, the IT administrator must choose between a standalone certification authority (CA) and an enterprise 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.
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 certificate authority 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:
- Central repository for all AD CS configuration information
- a. Located in the configuration naming context in the forest root domain
- b. Replicates between all domain controllers in the forest
- Distributing trusted root/intermediate CAs to domain-joined clients
- 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.
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.
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.
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.
Certificate 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.
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.
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.
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.
CDP Container
The CDP container contains LDAP Uniform Resource Identifiers (URIs) for certificate revocation lists (CRLs). The LDAP certificate revocation list is 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.
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.
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.
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 practices, contact Ravenswood Technology for expert help.
Read more in Part 5 of this blog series: Hardware Security Modules.
