How to Avoid Having Users Enroll for Multiple Certificates

Gregg O’Brien is a Microsoft Premier Field Engineer from Canada. In this post he talks about the ‘certificate explosion’ phenomenon and suggests a way to mitigate it.


Introduction

We live in some very exciting times – we have so many devices to choose from: desktops, laptops, tablets, hybrids/convertibles, ultrabooks, netbooks and smartphones. Each of these devices offer their own unique benefits and features, so much so that it’s not uncommon to find people carrying 2 or 3 devices now!

As with all super cool technology though, IT pros will always find some challenge waiting at the bottom of that pile of coolness. In the case of multiple devices in an enterprise, a common problem is enrollment of certificates. Not so much a problem of acquiring certificates, but the problem of users acquiring too many certificates.

Scenario

A Microsoft Active Directory Certificate Services infrastructure on Windows Server 2008/2012 is implemented with auto-enrollment capabilities. Users with accounts in Active Directory login to the domain and the auto-enrollment policy enrolls the user for a certificate tied to their account. The certificate is downloaded from the certificate authority and is stored in the user’s certificate store on the local computer. So far so good….

Now for the ‘wrench in the gears’: the same user logs into another computer with the same user account and because the certificate store tied to that user account is empty on the second computer, the user receives a new certificate with a different private key. This behavior repeats on every computer the user logs on to. At first this might not seem like such a big deal. But this actually presents a few potential issues:

  1. Operations carried out on the local PC such as drive encryption will use certificate stored in the local computer store. When the user logs into a different machine and a new certificate is requested, a different private key will be used for local operations. Meaning that the user will have multiple private keys that will not be able to perform operations on data from another computer, even if it is a device that they own!
  2. The certificate is stored in the user’s local profile. If that profile is lost, so is the certificate with the private key! If that key isn’t backed up, the data protected with that private key is lost.
  3. The certificate services database gets larger unnecessarily due to each user in the organization having multiple certificates.

The Solution

So what can we do about this? Well, the good news is, unlike most complex problems in life this one can be fixed by checking a few check boxes:

  • Launch the Certificate Templates Snap-in
  • Locate the template that users are being enrolled for certificates from. On my server, I called it “User Certificates”:
  • Right click on the template and click “Properties”:

Certificate Template Properties

  • On the general tab locate the check box for “Publish certificate in Active Directory” and ensure it is checked.
  • Check the box below called “Do not automatically reenroll if a duplicate certificate exists in Active Directory”

Auto-enroll control

  • Click “Apply” and then click “OK”
  • Now launch the “Certificate Authority” console and click on Certificate Templates. We will reissue the User Certificates template to update for the changes.
  • Click on the “Certificate Templates” node and find the User Certificates template being used from the pane on the right.
  • Right click on the template and click “Delete” and answer “Yes”

Delete the template

  • Now right click on the “Certificate Templates” node and click on “New” and then “New Template to Issue”

New certificate template

  • Locate the template being used for User Certificates and then click “OK”

Enable Certificate Templates

Conclusion

Now when users enroll for a certificate, the client will first check it see if there is a certificate in Active Directory. If there is, rather than issuing a new certificate it will reuse the certificate that has already been issued. Another technical challenge vanquished!


Posted by Arvind Shyamsundar, MSPFE Editor.