Understanding AD CS CRL publication periods and configure auto publish CRL to share

By default when you deploy a two-tier AD CS the default CRL publication period is 1 week. This is set on the Offline CA and the Onsite CA. 

What does this mean?

If you have the CRL publication period set to one week, a new CRL must be published and available to clients on a weekly basis of certificate revocation will fail. 

In a two-tier AD CS infrastructure there are two CRL's in created;

Offline CA CRL - this is published by the Offline CA and should be blank unless you have revoked historic Root Certificates. This CRL is only used to by the Online CA to check the validity of Root Certificate which has been issued by the Offline CA. If certificate revocation fails for the Offline CA Root Certificate, the entire AD CS will fail. This is because all certificates are signed by the top certificate in the trust chain. By default this is set to one week, which means every week an administrator will have to boot the Offline CA, publish a new CRL and then copy it to the revocation points. It is likely that your Offline CA will only issue a single certificate, to the Online CA, if this is the case there is no risk in setting the Offline CA's CRL publishing time to months, or even years. 

To do this login to the Offline CA, open Certification Authority expand the server object, right click on Revoked Certificates and select Properties. Once this is committed, a new CRL must be created which can be done if you right click Revoked Certificates and select All Tasks > Publish. 

The newly published CRL can be found at C:\Windows\System32\CertSrv\CertEnroll the CRL files should be copied to the revocation points which are usually stored in AD LDAP, HTTP or both. It's typical for a HTTP revocation point to be on the Online CA, so that it's reachable by clients. 

Online CA CRL - this is published by the Online CA and will contain any certificates that have been revoked by administrators. Revoked certificates are not listed in the CRL until a new CRL has been generated. The Online CA CRL publication period is more important than the Offline CA, this is because it's likely that certificates issued by the Online CA might actually be revoked during the course of normal business. I usually set the Online CA to have a CRL publication period of 1 month, which means a new CRL will automatically be published every month, however once published the CRL files are not automatically copied to the revocation points on disk, which are usually served over HTTP by IIS or similar. If no certificates are revoked over the period of a month, the CRL will be unchanged, however the new files must be copied into the revocation point locations or certificate revocation will fail. 

With the Online CA CRL set to 1 month I usually just build it into a monthly maintenance task that should be provided by the SysAdmin team who are managing the AD CS environment. 

A useful way to check CRL expiration times is to use pkiview.msc which gives a clear overview of the CRL's all the way up the trust chain.

AD CS reinstall causes templates to show "Template information could not be loaded. Element not found."

After a reinstall of AD CS when you try to expand the Certificate Templates pane of the Certificate Authority MMC it throws the error "Template information could not be loaded. Element not found.".

To resolve this you need to use ADSI Edit from one of your Domain Controllers. Open ADSI Edit and connect to the Configuration partition, expand CN=Services, CN=Public Key Services and find CN=Certificate Templates. Right click on CN=Certificate Templates and select Properties. 

The error is caused because the Computer Object of the newly install AD CS server does not have Read permissions on the Certificate Templates top level folder. Add the Computer Object and grant it Read permissions. 

It's a good idea at this point to force an AD replication cycle.

Relaunch the Certificate Authority MMC and refresh Certificate Templates, please not you will have to recreate any of your Certificate Templates before the reinstall, these will also need republished to AD before they can be used for enrollment. 

AD CS custom templates not shown in AD CS Web Enrollment portal

When you try to enroll a new certificate using the AD CS Web Enrollment point you are unable to select the custom AD CS template you would like to use. 

When the custom template is being created click on the Subject Name tab and ensure Supply in the Request is selected. This is a must if you are creating certificate for non domain-joined devices like network appliances. 

Click on the Security tab and add the Web Enrollment server computer object to the ACL and ensure it has Full Control permissions. 

Ensure you issue the certificate template to AD.

Go back to the web enrollment point and you should have the option to use this new template. Please note you might have to force AD replication.

MDOP 2013 R2: Advanced Group Policy Management to Track GPO Changes

I was recently asked to investigate the Advance Group Policy Management toolkit to enforce greater compliance and change control of Group Policy objects in a large enterprise environment. This particular client had various different IT service providers making changes to the Active Directory and Group Policy objects.
a
You can download the MDOP 2013 R2 ISO from Microsoft;

http://www.microsoft.com/en-us/windows/enterprise/products-and-technologies/mdop/default.aspx

The first step is to install the AGMP Server  on to a Domain Controller in your environment. The installation is very straight forward and uninteresting therefore I am not going to cover it in detail. In this example I am also going to install the AGMP Client on to the same Domain Controller.

 

When the AGPM Server installation completes a new tab will appear in Group Policy Management called Change Control this is where the majority of AGPM tasks are done.

 

Click on the Uncontrolled tab and you will see a list of Group Policy Objects that are not being audited or managed using AGPM. Right click on one of your GPO's and select Control.

 

This will then instruct AGPM to audit and track any changes that are made to that GPO. For this example I have deliberately make some policy changes to the AGPM Example GPO.

 

If you click on the Controlled tab, and right click on the GPO you have auditing set on and select Differences and then HTML Report.

 

AGPM will generate and output a full HTML report that highlights and changes to that particular GPO.

 

The History tab also tracks time and date stamps on events and GPO changes.

 

I have found this tool extremely useful in large enterprise environments where there are multiple Active Directory Administrators (or IT service providers) all working on the Group Policies. It was particularly good when someone accidentally deleted the Default Domain Policy link from a production domain.