As part of joining PKI Solutions, several blog posts from my old site are re-posted here for visibility and thoroughness.
Hello folks! Today I want to explain in details about Active Directory containers related to ADCS (Active Directory Certificate Services), their purposes and how they work.

Intro

All ADCS related containers are stored in configuration naming context under Public Key Services container:
CN=Public Key Services, CN=Services, CN=Configuration, DC={forest root domain}

Since Public Key Services container is stored in configuration naming context, any it’s content is replicated between all domain controllers in the current forest (not only current domain) and are available to any client in the forest. This means that there is no way to limit PKI containers only to specific domain or domains.

Here is a screenshot from ADSIEdit.msc tool:

Under Public Key Services container you find the following subcontainers:

• AIA
• CDP
• Certificate Templates
• Certification Authorities
• Enrollment Services
• KRA
• OID

and the following entry (not a container):

• NTAuthCertificates

Sections below describe the purpose of each container.

AIA

This container is used to store intermediate CA certificates and cross-certificates. This container may contain entries of certificateAuthority type. CA certificates are written to cACertificate attribute and cross-certificates are written to crossCertificatePair attribute.

When you install new Enterprise CA, it’s certificate is automatically installed to AIA container.

you can programmatically install CA certificate to this container by running the following certutil.exe command:

certutil –dspublish –f <PathToCertFile.cer> SubCA

Replace <PathToCertFile.cer> with actual path and certificate name file.

All certificates from this container are propagated to each client as a part of group policy processing to client’s Intermediate Certification Authorities container.

CDP

This container is used to store certificate revocation lists (CRL). To differentiate CRLs a separate container is created for each CA. Typically CA host NetBIOS name is used. For example, if CA server runs on a computer ca01.company.com, the following path is created for that CA:

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

And this container may contain records of cRLDistributionPoint type. Base CRL is written to certificateRevocationList attribute. Delta CRLs (multiple delta CRLs are allowed) are written to deltaRevocationList attribute.

When you install new Enterprise CA, it automatically publishes first CRLs to CDP container.

you can programmatically install certificate revocation list to this container by running the following certutil.exe command:

certutil –dspublish –f   

Replace with actual path and certificate name file. And replace with required name. Usually subcontainer name is CA host short (NetBIOS) name.

CRLs from CDP containers are NOT propagated to clients and is used only when a certificate refers to a particular cRLDistributionPoint entry in CDP container.

Certificate Templates

This container contains enterprise certificate templates used by Enterprise CAs. You should not edit templates directly. Consider to use Certificate Templates (certtmpl.msc) MMC snap-in for template management.

Certification Authorities

This container is used to store trusted root certificates. This container may contain entries of certificateAuthority type. CA certificates are written to cACertificate attribute.

When you install Enterprise Root CA, it’s certificate is automatically installed to Certification Authority container.

you can programmatically install Root CA certificate to this container by running the following certutil.exe command:
certutil –dspublish –f <PathToCertFile.cer> RootCA
Replace <PathToCertFile.cer> with actual path and certificate name file. Note that a copy of root CA certificate is also installed in AIA container too.

All certificates from this container are propagated to each client as a part of group policy processing to client’s Trusted Root Certification Authorities container.

Enrollment Services

This container is used to store Enterprise CA objects. Clients use this container to locate Enterprise CAs in the forest.

When you install new Enterprise CA, a new record in the Enrollment Services container is created.

All certificates from this container are propagated to each client as a part of group policy processing to client’s Intermediate Certification Authorities container. Also, this container is enumerated during certificate enrollment process.

KRA

This container is used to store key recovery agent certificates for each Enterprise CA. When Enterprise CA issues a certificate based on Key Recovery Agent template, it automatically adds it to a corresponding entry. If this is first KRA certificate, CA creates a record for itself and writes KRA certificate to userCertificate attribute.

Certificates from KRA container are exposed only when you assign new key recovery agent to CA server.

OID

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

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

Alternatively, you can use PowerShell PKI module which contains commands to add or remove OID from Active Directory: Get-ObjectIdentifierEx, Register-ObjectIdentifier and Unregister-ObjectIdentifier.

NTAuthCertificates

This entry is used to store certificates for CAs that are eligible to issue smart card logon certificates and perform client private key archival in CA database.

• During smart card logon, domain controller checks whether issuer is presented in the NTAuthCertificates entry. If it doesn’t, the logon attempt is denied immediately.
• During certificate enrollment based on a template that requires private key archival in CA database, enrollment client checks whehter the CA certificate is presented in NTAuthCertificates entry. If it doesn’t, the enrollment process is failed.

you can programmatically install CA certificate to this container by running the following certutil.exe command:

certutil –dspublish –f <PathToCertFile.cer> NTAuthCA

Replace <PathToCertFile.cer> with actual path and certificate name file.

When you install new Enterprise CA, its certificate is added to NTAuthCertificates entry. Note that a copy of CA certificate is also installed in AIA container as well.

All certificates from this container are propagated to each client as a part of group policy processing to client’s Intermediate Certification Authorities container.

Alternate AD container management options

Although, ADSIEdit.msc allows you to view and edit extended details of the Public Key Services container, it is not very user-friendly and cannot render binary data (certificates and CRLs) in UI. To view container contents in UI you can use PKI Health Monitor (PKIView.msc) tool.

• Log on the computer where ADCS management tools (RSAT) are installed, run the PKIView.msc console.
• In the opened console, select top node named Enterprise PKI.
• Click Action menu and select Manage AD Containers.

In this window you can view and delete entries for all containers, except Certificate Templates and OID.

Also, this tool allows you to add CA certificates only to NTAuthCertificates containers. To add certificates or CRLs to other containers (AIA, CDP, Certification Authorities) you should use certutil.exe tool as described above.

Permissions

By default only members of Enterprise Admins group have permissions to modify the contents of the Public Key Services. If necessary, you can delegate appropriate permissions to other user or group (must be either global or universal) via ADSIEdit.msc tool.