Configuring Active Directory Certificate Services and Auto-Enrollment

/
CA.JPG

This guide shows how to setup Active Directory Certificate Services (ADCS), certificate auto-enrollment, and an OCSP responder. It was originally supposed to be a rather thorough guide, but then the test server I had blew up for some reason, so I am going to refer you to the Microsoft TechNet guide and make notes of items which I believe they missed and problems I ran into. This will allow me to focus more on describing configuration of certificate templates and certificate auto-enrollment, rather than spending a painstaking amount of time recreating a guide for installations which already exists.

The original point of me setting up ADCS was to support an IKEv2 VPN, which requires the VPN server to have a certificate. Setting up Remote Access on Windows Server 2012 will be the subject of the next guide I write. For now, we will setup ADCS as a basic piece of infrastructure to support authentication services across our domain.

Prerequisites for Installing Active Directory Certificate Services

This guide uses Windows Server 2012 for all of the servers involved.

  • Two separate servers are required.
    • Domain controllers are generally best left to their intended functions and cannot perform optimally, or most securely, when running other services as well. ADCS should also be run by itself because this server will contain your new Certificate Authority's private key. If your private key is compromised, then certificates can be issued on your CA's behalf and the integrity of your PKI infrastructure is completely compromised.
    • Setup a domain using AD Directory Services. For this guide, we will be using a domain named Wildwest.lan.
    • Install Windows Server 2012 on a separate system from your domain controller.
    • A testing workstation will also be required.

Installing and Performing Basic ADCS and OCSP Configuration

Follow this excellent step-by-step guide written on Microsoft TechNet for an in-depth explanation of installing and configuring a basic ADCS and OCSP setup. This will create the basic infrastructure for the configuration steps I will discuss next. At Step 3, only create the OCSP Response Signing template and I will discuss creating and using other templates below.

Obviously this guide was written for Windows Server 2008, but the steps are still applicable to Windows Server 2012 as long as you are familiar with the GUI and process differences between the two operating systems.

Configuring User Certificate Auto-Enrollment

  • New certificate templates should always be created. Do not customize a preexisting, built-in template. Go to the Certificate Templates part of the Certification Authority snap-in and duplicate the User template. Rename this certificate to something descriptive of your choosing.
  • By default, this template allows the certificate to be used for Client Authentication, Encrypting File System, and Secure Email. If you do not have email setup within your domain, you should go to the Extensions tab and remove "Secure Email" from the Application Policies section.
  • Additionally, if you do not populate the "Email" attribute of your user accounts in your domain, then you should go to the Subject Name tab and uncheck "Include e-mail name in subject name" and "E-mail name." If you do not uncheck these options, then certificate auto-enrollment will not occur because your users' Subject Names will not be able to populate correctly.
  • Go to the Security tab. If all of your domain's users will have their certificates auto-enrolled with this template, then select the Domain Users group and ensure that "Read," "Enroll," and "Autoenroll" permissions are all assigned to that group. If you only want a subset of users to have their certificates auto-enrolled, then make a new Global Security Group, add the users to that group, then assign the above permissions to that group within the certificate template.
  • Click OK to save the template.
  • Go back to the Certificate Templates folder in the Certification Authority MMC snap-in. Right click in the right-hand pane, select New -> Certificate Template to Issue. Select the new certificate template you just created and select OK to publish the certificate template to Active Directory.
  • In order for Certificate Auto-Enrollment to work, you need to add a GPO setting. It is, of course, easiest to add this setting in the Default Domain Policy because it will apply to every object in the domain, but you can add it add a more granular level if necessary. The setting that needs to be Enabled is: Computer Configuration -> Policies -> Windows Settings -> Security Settings -> Public Key Policies -> Certificate Services Client - Auto-Enrollment Settings -> Automatic certificate management. I also enabled the two sub-options to allow most certificate options to be managed automatically from AD.

A Note About Publishing Certificates in Active Directory

There is an option on certificate templates to publish certificates in AD once they have been generated. Obviously, this will only publish your public certificate to AD since your private certificate must be kept secret at all times. This publishing option is used for instances when it is necessary to have your public key available for others' consumption when they are not opening a point-to-point direct communication with you, such as when secure email through S/MIME is in use in your organization. However, unless there is a specific usage for this publishing, certificates are generally not published to AD.

The sub-option concerning publishing, "Do not automatically reenroll if a duplicate certificate exists in Active Directory," is useful when you want a certificate to be restricted only to a single instance because it will prevent a new certificate from being issued if one already exists in AD with the same information for that object. For instance, if a server certificate template is created where you know that issued certificates will not be reissued until they expire, then checking this option will prevent accidental or malicious duplication of certificates. However, user certificates generally do not have this option selected because it would prevent users from moving from to different computers and having certificates automatically enrolled there.

Choosing Key and Hash Strength

Modern certificates of well-known corporations generally use a key length of 2048 bits and SHA1 as a hash. 2048 bits is a forward-looking key length that will likely be viable for the next 5-10 years. For the extremely paranoid or those with highly sensitive applications, 4096 bits is a future proof key length that is still not highly compute intensive for modern hardware. SHA1 is beginning to show its age, so even though this hash algorithm's integrity is still intact, it would not be inappropriate to use SHA256 as your certificate hash algorithm of choice.

Future Articles

This piece was meant to give a few tips about creating a simple AD CS deployment in your home or small business. By no means is this a comprehensive guide or appropriate for a large organization. In the near future, I will be writing about measures to secure your PKI infrastructure appropriately.