Updated 20.06.2018: clarified the purpose of NTAuthCertificates DS container.


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:

PKI containers in ADSI Editor

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 <PathToCRLFile.crl> <SubcontainerName>

Replace <PathToCertFile.cer> with actual path and certificate name file. And replace <SubcontainerName> 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.

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

Manage AD Containers in PKIView.msc

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.


Share this article:

Comments:

Toni
Toni 07.03.2013 23:31 (GMT+3) Understanding Active Directory Certificate Services containers in Active Directory

Images on the article aren't visible.

Vadims Podans
Vadims Podans 08.03.2013 11:35 (GMT+3) Understanding Active Directory Certificate Services containers in Active Directory

Fixed.

Dmitry Zobnin
Dmitry Zobnin 12.07.2014 02:30 (GMT+3) Understanding Active Directory Certificate Services containers in Active Directory

Hello Vadim, read your article and I have a question. You wrote "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." But what if it's presented? Can you explain further steps? Let's see some scenario. Domains A.local and B.local are located in different AD forests and connected with two-way Forest Trust. B.local forest have some PKI hierarchy deployed. Root certificate of the B.local PKI hierarchy (call it "B_RootCA.cer") was manually published to the forest A.local Configuration partition ("NTAuthCertificates" entry and "Certification Authorities" container). Suppose that during the Smart Card authentication process KDC (call it DC01.A.local) received a user certificate with the field UPN=user01@domainB.local. It seems that everything is OK, certificate is valid and trusted. Will KDC perform correct mapping? If yes, can you explain how does it work (with requests, kerberos refferals and signatures)?

Vadims Podans
Vadims Podans 14.07.2014 21:24 (GMT+3) Understanding Active Directory Certificate Services containers in Active Directory

In multi-forest environment only authenticating domain controller performs client certificate validation. There could be additional DCs which are acted as proxy. In your example the following process occurs: 1) user UPN=user01@domainB.local attempts to log on to domainA computer. 2) Client workstation enumerates and extracts certificate and submits to a domainA DC, say, dc.domainA.local 3) dc.domainA.local looks for a SAN extension and checks whether it can use this certificate. Since, UPN contain domainB domain component, DC performs trust relationship checking, to find whether there is a trusted domain the user belongs to. 4) if it finds, then dc.domainA.local transmits credential data to dc.domainB.local (user-origin domain). 5) dc.domainB.local performs all required checks (including NTAuthCA conformance) and responds to dc.domainA.local with "yes" or "no". If the response is "no", logon is denied, otherwise, it is allowed, and dc.domainA.local assigns appropriate membership information and kerberos token. That is, in a given example, DCs in domainA act as proxy and performs authorization only, and after user-origin domain DCs successfully aauthenticate him,her.

Eduardo Aguirre
Eduardo Aguirre 06.12.2018 06:24 (GMT+3) Understanding Active Directory Certificate Services containers in Active Directory

Dear I have a query,

some time ago we made the migration "WIN 2008R2 to WIN2012" of an Active directory that also had the role of CA, and we had some difficulties with the latter. today when trying to renew a certificate with the same key of a domain controller I get an error "the user does not have permission and that the CA can not find the certificate template" then when entering the role "CA" when trying to display the template folder certificate "I get a message that the item does not work.
Is there any way to repair this problem?

 

Vadims Podāns
Vadims Podāns 06.12.2018 18:38 (GMT+3) Understanding Active Directory Certificate Services containers in Active Directory

@Eduardo Aguirre,

I think, you may need to ask your question on related forum board. For example, on TechNet: https://social.technet.microsoft.com/Forums/en-US/home?forum=winserversecurity

바둑이사이트
바둑이사이트 12.06.2020 06:40 (GMT+3) Understanding Active Directory Certificate Services containers in Active Directory
"Baduki" is really straightforward, however you can swiftly see that a couple of rounds are in fact very hard. You might misinterpret that it is really simple because there is another card than the Western five-game low card, yet the fact that the pattern must be all various makes the trouble soar. https://1234king.com

Post your comment:

Please, solve this little equation and enter result below. Captcha