Now that I have Windows 8.1 installed on both my Surface and laptop (Lenovo T430s) I have some time to work on some blogs. I am going to continue on the “Operating a PKI” series. However, I did want to cover Disaster Recovery in a series of blogs as well. I will of course cover backing up and recovering Certification Authorities as well as other topics. I wanted to start of with recovering PKI related data that is stored in Active Directory. But first, let’s identify what data is stored in Active Directory.
So, let's start with a discussion of what PKI information is stored in Active Directory. Some important PKI related information that is stored in Active Directory is configuration information. Configuration information is stored in the Configuration Partition of Active Directory. For those not familiar with Active Directory, it is important to note that the Configuration Partition is replicated to every domain controller in the forest. This has some implications. For example, we will see that Certificate Templates are stored in the Configuration Partition. This means that Certificate Templates are “shared” throughout the forest. So, if you have different parts of the organization that have their own domain and even their own PKI, they will all use the same list of Certificate Templates. Specifically, PKI configuration information is stored in
There are a couple of tools that can be used to view the Configuration Partition. The first is ADSI Edit (adsiedit.msc). ADSI Edit can be installed by installing Active Directory Remote Server Administration Tools (RSAT). To view the Configuration Partition, first run adsiedit.msc. Once ADSI Edit opens, right click on ADSI Edit, and select Connect to… from the context menu.
Once Connection Settings opens, select Configuration from Select a well known naming Context:
Expand Configuration, then CN=Configuration, <RDN of the forest>., then CN=Services, and finally, CN=Public Key Services.
You will see the following containers and objects:
Below is a decryption of the containers and objects:
AIA: Short for Authority Information Access. This is where CA Certificates are stored. If the AIA extension is configured to use LDAP (Active Directory), certificates are fetched from this location if required for chain building.
CDP: Short for CRL Distribution Points. If you choose to use LDAP (Active Directory) as a CDP repository this is where CRLs are stored and then fetched if needed to check revocation status..
Certificate Templates; This is where Certificate Templates are stored. Certificate Templates are used for certificate enrollment when using an Enterprise CA.
Certification Authorities: this container is where Root CA certificates are stored.
Enrollment Services: Enrollment Services container contains Enrollment Services object. Each Enterprise CA publishes an Enrollment Service object. This object is used by enrollees to find Enterprise CAs during enrollment and to locate which Enterprise CAs host the Certificate Template the enrollee is attempting to enroll for.
KRA: The public key of Key Archival certificates are stored in this container.
OID: A container that holds OID information used by Certification Authorities.
NTAuthCertificates: The NTAuth Container contains CA certificates that are trusted for issuing certificates for authentication such as Smart Card logon.
Additional information on these containers is available here: http://technet.microsoft.com/en-us/library/cc783853(v=WS.10).aspx
Viewing these containers is also possible through the Active Directory Sites and Services MMC (dssite.msc).
To view the Services Container, open dssite.msc. Once the MMC opens, select Show Services Node from the View menu.
Then expand Services, then Public Key Services.
To view the Public Key Services container, first start Enterprise PKI (pkiview.msc). Enterprise PKI is installed on the Certification Authority if you chose to install management tools. You can also install the Active DIrectory Certificate Services Remote Server Administration Tools on a management machine. To view the Public Key Services container, first start Enterprise PKI (pkiview.msc). Right-click on Enterprise PKI, and select Manage AD Containers… from the context menu.
Once Manage AD Containers opens, you can view each container by clicking on the corresponding tab. I really like viewing the AD containers, because you get a better understanding of what is contained in these containers.
If you have a Certificate Template configured to Publish certificate to Active Directory, a copy of the certificate will be copied to the userCertificate attribute on the computer or user.
There are a couple ways to view the userCertificate attribute. The method I will mention here is using Active Directory Users and Computers.
So, first launch Active Directory Users and Computers (dsa.msc). Once ADUC opens, open View menu, and then select Advanced Features.
Next, locate a user account for which you would like to view the userCertificate attribute.
Double-click on the desired user account and select the Published Certificates tab. You can now view what certificates have been published to the userCertificate attribute on that user account.
If you want to view the attribute directly, you can without using ADSI Edit. Simply select the Attribute Editor tab on the user account. Then navigate to the userCertificate attribute. This same step can be used for viewing the userCertificate attribute for user accounts.
If a user wanted to view what certificates they have published to their user account. They can open certmgr.msc on their computer and navigate to Active Directory User Object, as seen below.
There are a number of settings that can be configured by Group Policy. Some of these settings include Autoenrollment, Automatic, Certificate Request Settings, EFS Settings, and Credential Roaming.
PKI related settings for the computer are located under \Computer Configuration\Windows Settings\Security Settings\Public Key Policies as seen in the illustration below.
PKI related settings for the computer are located under \User Configuration\Windows Settings\Security Settings\Public Key Policies as seen in the illustration below.
Your organization may have many Group Policies so you will have to determine which policies contain PKI related settings. If you are unsure which policies have PKI configuration you can use the Resultant Set of Policy tool to help determine this. Locate a machine which you believe is receiving the PKI related Group Policies. If you are looking for user related policies you would log in with a user account you believe are receiving PKI related Group Policies. I will use a Computer related policy to illustrate how this can be done.
Once you are logged into the proper machine run RSOP.msc. You will have to be logged in as an Administrator of the machine to view Computer related policies. In my example, once RSOP.msc opened, I viewed all of the settings under \Computer Configuration\Windows Settings\Security Settings\Public Key Policies. Only one of the settings was configured. So, I double click the setting to open it. Then I click on the Precedence tab to determine which policy has configured the setting as seen below.
You can also use other tools like gpresult if you are familiar with them. In “my” environment we can see that Autoenrollment was configured by a policy named Computer Autoenrollment.
Next, I am going to locate the Group Policy in the Group Policy Management Console (gpmc.msc). So, I look under Group Policy Objects in the GPMC, and locate the GPO. As you can see, I can view where the GPO is linked, what security filters are applied, and if any WMI filters are applied.
Group Polices are made up of two components: Group Policy Template (GPT) and the Group Policy Container (GPC). The GPT is stored in Sysvol. Sysvol is a file structure that is replicated amongst Domain Controllers. The GPC is stored in Active Directory. When GPO is applied a client use the GPC to determine which GPOs are applied and where to locate the GPT. the client then loads the GPT to determine what settings need to be applied. And those settings are applied by Client Side Extensions (CSEs).
If you want to locate the GPT and GPC you can follow these steps. Again I will be using my test environment as an example of how to do this. First I click on the Details tab for the Group Policy that I found earlier. I then locate the Unique ID as seen below. The Unique ID for this GPO is 6D5EB75D-356B-488B-91CE-8A032E66E993.
In order to locate the GPT, I navigate to \\fourthcoffee.com\SYSVOL\fourthcoffee.com\Policies and locate the Unique ID for the GPO as seen below.
In order to locate the GPC, I open ADSI Edit (adsiedit.msc). I connect to the Default Naming Context as seen below:
I then expand DC=Fourthcoffee,DC=com, then CN=System, and then CN=Policies. As you can see in the screenshot below I can then see the Unique ID that I had previously located.
The purpose of this blog postings was to help someone not familiar with Active Directory locate where PKI related information is stored in Active Directory. It is critical that this information is understood so that you can understand what needs to be backed up and why. In the next blog I will discuss how to back up this information.