Why do you need to add Active Directory Certificate Services (ADCS) Containers in your active directory?

To establish a public key infrastructure and offer your company’s public key cryptography, digital certificates, and digital signature capabilities, an ADCS server role is necessary. AD CS provides customizable services for issuing and managing digital certificates in software security systems that engage public key technologies.

The digital certificates that AD CS provides can be used to encrypt and digitally sign electronic documents and messages. These digital certificates can authenticate network computers, users, or device accounts. Digital certificates are used to provide the following:

1. Confidentiality through encryption
2. Integrity through digital signatures
3. Authentication by associating certificate keys with a computer, user, or device account on a computer network

The public key services container cannot be limited to any specific domain or domains. It is available to any client in the forest. Since the public key service container is stored in a configuration naming context, the content is simulated between all domain controllers in the current forest.

CN=Public Key Services, CN=Services, CN=Configuration, DC= {forest root domain}

The followings are the sub-containers under public key services containers:

1. AIA
2. CDP
3. Certificate Templates
4. Certification Authorities
5. Enrollment Services
6. KRA
7. OID

Below are the descriptions of each container:

AIA

In order to create a trusted certificate chain and retrieve any cross-certificates issued by the CA, clients can retrieve CA certificates from the AIA container by utilizing the authority information access (AIA) certificate extension. Another name for AIA is Authority Information Access (AIA). The AIA container will automatically install the new enterprise CA’s certificate during installation. To install the CA certificate programmatically to this container, run the below command:

Certutil -dspublish -f <PathToCertFile.cer> SubCA

<PathToCertFile.cer> – this is the actual path and certificate name file.

CDP

CDP stores certificate revocation lists. It contains all base CRLs, and Delta CRLs published in the forest.

You can install the certificate revocation list to the CDP container by running the certutil command.

Certutil -dspublish -f <PathToCRLFile.crl> <SubcontainerName>

How to add a CDP

Below command is to add CDP

Add-CRLDistributionPoint [-InputObject] <CRLDistributionPoint[]> [-URI] <String[]> [<CommonParameters>]

Parameters

-InputObject <CRLDistributionPoint[]>  -> Specifies the CRLDistributionPoint object to which new CRL distribution points are added

[-URI] <String[]>  -> This specifies new CRL file publishing distribution points for a particular CA.

<CommonParameters> : The cmdlet supports common parameters like: Debug (db), ErrorAction (ea), ErrorVariable (ev), InformationAction (infa), InformationVariable (iv), OutVariable (ov), OutBuffer (ob), PipelineVariable (pv), Verbose (vb), WarningAction (wa), WarningVariable (wv)

CRL Publication options

Certificate Templates

By defining the common features shared by all certificates issued using that template and determining the permissions for which users or computers can enroll in or automatically enroll for the certificate, certificate templates are used to automate certificate deployment. A certificate template that automatically enrolls all domain users with valid email addresses for a secure email (S/MIME) certificate would serve as an illustration.

All certificate templates available in AD, whether 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. By default, over 30 Microsoft predefined certificate templates are installed when building an enterprise CA.

Certification Authorities

Certificate authorities container is for the trusted Root CA(s). During the enterprise Root CA creation, the certificate is automatically deployed in the container. In the case of an offline standalone CA, the PKI administrator must manually publish the offline root CA certificate using the certutil command.

Example: certutil -dspublish -f <Root.cer> Root CA

Enrollment services container

It includes the certificates for the enterprise CAs that can grant certificates to individuals, machines, or services located within the forest. Only an Enterprise Admins member who installs an enterprise CA can add enterprise CA certificates to this container. The Manage AD Containers dialogue box cannot be used to add the certificates manually

KRA

Contains the certificates for key recovery agents for the forest. Key recovery agents must be configured to support key archival and recovery. Key recovery agent certificates can be added to this container automatically by enrolling with an enterprise CA. The key recovery agent certificates cannot be added manually by using the Manage AD Containers dialog box.

OID

This container stores object identifiers (OID) registered in the enterprise. OID container can hold object identifier definitions for custom Application Policies, Issuance (Certificate) Policies, and certificate templates. When the client is a member of the Active Directory Forest, it uses an OID container to resolve object identifiers and the local OID database.

New OIDs should be registered via Certificate Templates (certtmpl. msc) MMC snap-in by adding a new Application or Issuance (Certificate) Policy in the certificate template Extension tab.

Conclusion

Understanding each active directory certificate services container is vital for an enterprise PKI administrator. An Administrator must know the activities and necessity of each container while managing the enterprise PKI infrastructure.