Understanding Active Directory Certificate Services Containers

If you have ever managed a Windows environment and wondered where your Certificate Authority configuration actually lives inside Active Directory, you are not alone. Most professionals know that Active Directory Certificate Services (AD CS) handles certificate issuance, but the plumbing underneath, specifically the set of specialized containers that store PKI configuration across your forest, often remains a mystery.

This guide will walk through every key container that AD CS uses, explain what it stores, why it matters, how to view it, and what can go wrong if it is misconfigured or neglected.

What You Will Learn

• What AD CS containers are and where they live in Active Directory
• The purpose of each container: Certification Authorities, AIA, CDP, Enrollment Services, NTAuthCertificates, KRA, OID, and more
• How to view and manage containers using PKIView, ADSI Edit, and certutil

What Is AD CS and Why Do Containers Matter?

Active Directory Certificate Services (AD CS) is Microsoft’s built-in Public Key Infrastructure (PKI) solution. It lets organizations issue and manage digital certificates for things like user authentication, computer authentication, encrypted email, SSL/TLS, smart card logon, code signing.

AD CS relies heavily on Active Directory to store configuration, publish certificates, distribute revocation information, and let client computers know which CAs they can trust. The containers we are going to explore are the specific places inside Active Directory where all of that information lives.

The Configuration Naming Context

All AD CS configuration data is stored in the Configuration naming context, under Public Key services container, which is replicated to every Domain Controller in the entire forest. That is an important detail. Unlike the Domain naming context (which is scoped to a single domain), configuration data is forest-wide. This means a change to a certificate template or a CRL distribution point on one domain controller will eventually appear on domain controllers in every domain in the forest.

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

Everything we discuss in this article lives somewhere under that path. So why does forest-wide security matter?

• Any misconfiguration in AD CS containers affects every domain in the forest.
• Permissions on these containers are set at the forest level by Enterprise Admins.
• A compromised CA or malicious certificate template can escalate privileges across domain boundaries.
• This is why hardening AD CS containers is a forest-wide security concern, not just a per-domain one.

The Key AD CS Containers, One by One

Let’s go through each container in detail.

Certification Authorities Container

This container holds the CA certificates of every root CA that your organization has decided to trust. When you install an Enterprise Root CA, the setup wizard automatically publishes the CA certificate here. Windows clients then read this container when building certificate chains, which is how they know whether to trust a certificate issued by your internal CA.

You can manually install the Root CA certificate to this container by running the following certutil.exe command:

certutil –dspublish –f  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.

Think of it as the “official list of trusted CAs” that the whole forest inherits. When a user receives a certificate signed by your internal CA, Windows checks this container (among other stores) to confirm that the issuing CA is trusted.

Enrollment Services Container

This is one of the most operationally important containers. Every Enterprise CA that joins your forest publishes an object here. When a Windows client wants to enroll for a certificate, it queries this container to find out which CAs are available and what templates each CA supports.

This discovery process powers auto-enrollment. When Group Policy triggers certificate auto-enrollment, Windows checks the Enrollment Services container to find out which CA to contact and what templates it should request. Without a valid object here, auto-enrollment simply stops working.

The pKIEnrollmentService object also carries an attribute called certificateTemplates, which is a list of templates published on that particular CA. This means if you want to know exactly which templates a specific CA is currently offering, this is where to look.

Viewing in PKIView.msc

Check Enrollment Services objects with the Enterprise PKI MMC snap-in

• Open PKIView.msc (run pkiview.msc from the Start menu)
• The tree view on the left shows your Enterprise PKI hierarchy
• Each CA node represents an object in the Enrollment Services container
• Right-click a CA and choose Properties to see its attributes
• Right-click Enterprise PKI and choose Manage AD Containers for deeper access

Certificate Templates Container

Certificate templates define the blueprint for every certificate type your PKI can issue. The template specifies the key usage, validity period, cryptographic algorithms, subject name format, extended key usage, auto-enrollment settings, and who is allowed to request that type of certificate.

All templates, whether they are currently published on a CA or not, live in this container. The separation between “template exists” and “template is published” is important: a template can sit in this container without any CA actively offering it. Only when a CA admin publishes the template does it get listed in the Enrollment Services object for that CA.

Why Templates Are a Security Hotspot

Certificate templates are the number one attack surface in most AD CS deployments. Research by security firms (most famously the ESC1 through ESC16 vulnerability classes documented by SpecterOps) has shown that misconfigured templates can allow unprivileged users to request certificates that grant domain admin privileges.

The most dangerous misconfigurations include:

• Allowing Authenticated Users to enroll in a template that has Manager Approval disabled
• Enabling subject alternative names (SANs) supplied by the requestor in sensitive templates
• Granting enrollment rights to overly broad groups
• Enabling the “Mark private key as exportable” flag unnecessarily
• Using certificate templates with ENROLLEE_SUPPLIES_SUBJECT flag on high-privilege templates

Critical Security Warning

Never leave “Authenticated Users” with Enroll permission on templates that lack Manager Approval.

AIA (Authority Information Access) Container

The AIA container stores the certificates of subordinate (intermediate) CAs and any cross-certificates your organization has established. When a client machine receives a certificate and needs to validate it, it has to build a chain from the end-entity certificate up to a trusted root. If the client does not already have the intermediate CA certificate cached locally, it uses the AIA URL embedded in the certificate to fetch it.

The LDAP URL pointing to this container is typically embedded in the AIA extension of every certificate your subordinate CA issues. So, when a machine says, “where do I get the certificate for the CA that issued this?”, it follows that LDAP URL and lands in this container.

Verify AIA with certutil

Check what is published in the AIA container from the command line

• Open an elevated command prompt
• Run: certutil -store -enterprise SubCA
• This lists all certificates in the AD-based AIA container
• Compare the output against your expected intermediate CAs
• To publish a missing cert: certutil -dsPublish -f SubCA.cer SubCA

A common problem: if the AIA container is missing the intermediate CA’s certificate, clients in other domains or forests that do not have the cert cached will fail certificate chain validation. This often shows up as SSL errors on websites or authentication failures in cross-domain scenarios.

CDP (CRL Distribution Point) Container

The CDP container is where your Certificate Revocation Lists (CRLs) live inside Active Directory. A CRL is basically a signed list of serial numbers for certificates that have been revoked before their expiration date. When a client application validates a certificate, one of its checks is “has this certificate been revoked?” It does that by downloading the CRL from a CDP URL.

Active Directory is one of several supported CDP locations (HTTP is another common one). The LDAP URL pointing to this container is embedded in the CDP extension of every issued certificate. When a certificate is validated, the client follows that URL and retrieves the CRL to check for revocation.

Each CA gets its own sub-container inside CN=CDP. Inside that sub-container you will find:

• Base CRL: The full list of revoked certificates, published on a regular schedule
• Delta CRL: A smaller incremental list of changes since the last base CRL

Publishing a CRL Manually

Force CRL publication to the AD CDP container

• On the CA server, open an elevated command prompt
• Run: certutil -crl   to force CRL publication
• This publishes both the base and delta CRL to all configured CDP locations
• Verify with: certutil -store -enterprise ldap:///CN=<CA Name>,CN=CDP,….
• In PKIView.msc, a yellow icon next to a CA indicates CRL validity is near expiry

View from the ADSI.edit

NTAuthCertificates Store

Despite sounding like a container, NTAuthCertificates is actually a single AD object with a multi-valued attribute. It holds the CA certificates for every CA that is authorized to issue certificates used for smart card logon and key archival.

Here is why this matters: when a user tries to log in to Windows using a smart card, the domain controller does not just check whether the certificate on the card is valid and trusted. It also checks whether the CA that issued that certificate appears in NTAuthCertificates. If the issuing CA is not listed there, logon is denied, even if the certificate itself is perfectly valid.

Enterprise CAs automatically add themselves to NTAuthCertificates during installation. Third-party CAs or standalone CAs used for smart card certificates must be added manually.

Check NTAuthCertificates from Command Line

Verify which CA certificates are in the NTAuthCertificates store

• Open an elevated command prompt
• Run: certutil -store -enterprise NTAuth
• This lists all CA certificates currently in NTAuthCertificates
• To add a missing CA: certutil -dsPublish -f <CA-cert.cer> NTAuthCA
• After adding, run: certutil -pulse   on DCs to force policy refresh

KRA (Key Recovery Agent) Container

The KRA container stores the KRA certificates. When a CA is configured for key archival, it uses the public key from a KRA certificate (stored in this container) to encrypt the archived copy of the user’s private key. Only the holder of the KRA private key can later decrypt and recover that archived key.

This is a sensitive container. If an attacker gains control of a KRA certificate’s private key, they can decrypt all archived user private keys, potentially accessing years of encrypted email, documents, and other sensitive data.

OID (Object Identifier) Container

Object Identifiers (OIDs) are globally unique numeric identifiers assigned to just about everything in the PKI world: algorithms, certificate extensions, policies, and more. The OID container in AD is where your organization registers custom OIDs that are used in certificate templates for Application Policies (what is the certificate valid for?) and Issuance Policies (under what conditions was this certificate issued?).

When you create a custom Application Policy extension in the Certificate Templates MMC snap-in, the resulting OID object gets stored here. This container is also how AD CS knows the human-readable names to display for those OIDs in the Certificate Templates UI.

While this container carries less direct security risk than the others, it is worth auditing to ensure no unexpected OID definitions have been added, which could affect template behavior in subtle ways.

Tools for Viewing and Managing AD CS Containers

Now that we know what is in each container, let’s talk about how to actually interact with them. You have three main tools at your disposal, each suited to different tasks.

PKIView.msc: The Friendly Starting Point

PKIView (also called the Enterprise PKI MMC snap-in) is the most approachable way to get a bird’s-eye view of your PKI health. It shows you the CA hierarchy, flags CRL and AIA accessibility issues with color-coded status icons and lets you navigate the AD containers without needing to know LDAP paths.

PKIView.msc – Enterprise PKI Health View

What you will see when you launch pkiview.msc on a domain-joined computer

• Start > Run > pkiview.msc
• Left pane: hierarchical tree of your Enterprise PKI (Root CA at top, Subordinate CAs below)
• Green checkmark icon = container/URL is healthy and accessible
• Yellow warning icon = CRL is nearing expiry or URL is slow to respond
• Red X icon = CRL or AIA URL is unreachable or expired
• Right-click Enterprise PKI > Manage AD Containers to view, delete, or refresh container objects

PKIView gives you great visibility but limited ability to make changes beyond deleting stale entries. For deeper management, you need the tools below.

ADSI Edit: The Low-Level Explorer

ADSI Edit (adsiedit.msc) is a raw directory editor that lets you browse and modify any object in Active Directory, including the PKI containers. Think of it as File Explorer for Active Directory. With great power comes great responsibility: a wrong edit in ADSI Edit can break your PKI in ways that are hard to reverse, so always test in a non-production environment first.

ADSI Edit – Navigating to Public Key Services

Browse the full PKI container structure

• Start > Run > adsiedit.msc
• Right-click ADSI Edit in the left pane > Connect To…
• Select ‘Configuration’ from the well-known naming context dropdown > OK
• Expand: Configuration[DC=…] > CN=Configuration > CN=Services > CN=Public Key Services
• You will now see all the sub-containers: AIA, CDP, Certification Authorities, Enrollment Services, KRA, OID
• Right-click any object and choose Properties to view all its attributes and values

Certutil.exe

Certutil is the command-line workhorse for everything AD CS. It can read from and write to AD CS containers, publish certificates and CRLs, verify certificate chains, and much more. Here are the most used commands for container management:

Quick Reference Summary

Here is a consolidated reference of all the AD CS containers we covered:

How Encryption Consulting Can Help With Your PKI?

Encryption Consulting provides specialized services to identify vulnerabilities and mitigate risks by providing PKI Services. Our strategic guidance aligns PKI solutions with organizational objectives, enhancing efficiency and minimizing costs. By partnering with Encryption Consulting, organizations can unlock the full potential of PKI solutions, realizing tangible financial benefits while maintaining strong security measures.

Encryption Consulting’s PKIaaS provides a flexible and secure PKI solution tailored to your specific needs, offering benefits such as customizable options, high assurance standards, and a low-risk managed approach. PKIaaS automates key and certificate management tasks, reducing operational overhead and minimizing the risk of human error. Additionally, it enhances network visibility by requiring certificates for access. It will take care of building the PKI infrastructure to lead and manage the PKI environment (cloud/ hybrid or On-Prem) of your organization.

CertSecure Manager has a comprehensive suite of lifecycle management features. From discovery and inventory to issuance, deployment, renewal, revocation, and reporting. CertSecure provides an all-encompassing solution. Intelligent report generation, alerting, automation, automatic deployment onto servers, and certificate enrollment add layers of sophistication, making it a versatile and intelligent asset.

Conclusion

AD CS containers are the unsung heroes (and occasional villains) of Windows PKI. When they are configured correctly and properly secured, they work silently in the background, enabling automatic certificate enrollment, smart card logon, SSL validation, and more. When they are misconfigured, neglected, or attacked, the consequences can range from annoying (auto-enrollment breaks) to catastrophic (forest-wide privilege escalation).

The key takeaways from this guide:

• All AD CS configuration lives in the Configuration naming context and is replicated forest-wide
• Each container serves a specific purpose in the certificate lifecycle, understand each one’s role
• Certificate templates are the highest-risk attack surface; audit them regularly
• NTAuthCertificates and the KRA container are high-value targets that need tight access control and monitoring
• PKIView, ADSI Edit, and certutil give you three complementary ways to inspect and manage containers
• Most common PKI problems trace back to stale, missing, or expired data in one of these containers

Taking time to truly understand your PKI’s container structure is one of the best investments you can make in both the reliability and security of your Windows environment. A PKI that is well-understood is a PKI that can be properly defended.