Freigeben über


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.

Comments

  • Anonymous
    January 01, 2003
    Will this setting prevent users from re-enrolling after their certificate has expired?

    Won't an expired certificate remain in Active Directory and thus prevent the user from being able to renew?

  • Anonymous
    January 01, 2003
    And to follow up, as this was posted over 2 years ago, I can't see anyone actually following up.

  • Anonymous
    January 01, 2003
    The comment has been removed

  • Anonymous
    December 03, 2013
    Thanks for this article! Stupidly we overlooked the setting to avoid multiple certificates and now we have the problem that several users have more than 1 certificate that is published in AD for email encryption. What is the best way to cleanup? Check what certificate will be used as default one and delete the other? Is it surely that the default certificate will be used everytime a user send an encrypted mail? What is the best practise? Thank you very much!

  • Anonymous
    December 03, 2013
    The comment has been removed

  • Anonymous
    December 04, 2013
    Thanks Alan for your help. I see, not so easy but I didn't thought it will. The checkbox as described above is set since yesterday, is it a possibility just to wait until they expire and then there's only one valid certificate in the store due to the setting to do not enroll multiple certs? But as I understand, I still must care of that the user has all his old private keys on the machine to read oly emails, right? At the moment we do not use roaming profiles and credential roaming, but credential roaming sounds like the one we need.

  • Anonymous
    December 16, 2013
    Hi, I followed the exact same steps as above but still when a user is logging into multiple computers, it is generating individual certificate for each computer. Please help

  • Anonymous
    February 16, 2014
    Hi all, Our CA server was configured to avoid user enroll for multiple certificate and to archive users' encrypted private key in server ("Archive subject's encryption private key" in Request Handling tab). Users have to set password to protect their private key stored in local computer. Our problem is how to protect Users' certificate( signatures) however they lost their AD account. This mean, when Attacker know AD account of an user, attacker could log on user's computer, delete user's certificate in local computer (password protected) then request a new certificate. we want to configure CA server to required attacker provide password which user set at the first time request certificate for each time re-request certificate. Please help!

  • Anonymous
    February 16, 2014
    Hi all, Our CA server was configured to avoid user enroll for multiple certificate and to archive users' encrypted private key in server ("Archive subject's encryption private key" in Request Handling tab). Users have to set password to protect their private key stored in local computer. Our problem is how to protect Users' certificate( signatures) however they lost their AD account. This mean, when Attacker know AD account of an user, attacker could log on user's computer, delete user's certificate in local computer (password protected) then request a new certificate. we want to configure CA server to required attacker provide password which user set at the first time request certificate for each time re-request certificate. Please help!

  • Anonymous
    August 11, 2014
    Assuming this also requires credential roaming? As in out environment this does not work.

  • Anonymous
    August 12, 2014
    Yes and no. For this to work with users using lots of computers, you'll need to ensure the private key for the "one" certificate are stored on each computer the users use. Which means, in general:
    -credential roaming, or
    -roaming profiles
    are needed to keep that private key material consistent across hosts.

  • Anonymous
    September 04, 2014
    "For this to work with users using lots of computers, you'll need to ensure the private key for the "one" certificate are stored on each computer the users use. Which means, in general:
    -credential roaming, or
    -roaming profiles
    are needed to keep that private key material consistent across hosts."

    Totally agree!
    This article is badly incomplete without telling this tiny little bit missing part of the story to the readers!
    Attention to everybody out there reading this article!

  • Anonymous
    December 05, 2014
    Any thought about reuse if the certificate requester is a service account but we are associating the cert with a user (aka, MDM like AirWatch)? Trying to use the same AD user cert for both a PC and a mobile device.

  • Anonymous
    January 09, 2015
    Hello.

    Once certificate is created on first user's login, and attached to its AD account, this setting (do not automatically reenroll a certificate if a duplicate exists in AD) prevent a new certificate to be created on another workstation when user log in. Is there any way to have the first certificate (attached in AD user's account) copied on the second workstation instead ?

    Thanks for your replies !

    • Anonymous
      November 22, 2016
      Hello François LAGRANGE,Do you solved this problem, that user get same certificate from AD user object to another machine? I have the same problem.Thanks,
  • Anonymous
    January 13, 2015
    Hi François ,

    I think you will find that the auto enrolled Public Certificate itself IS published in AD meaning that if you open up "certmgr.msc", you check out the "Active Directory User Objects", you will see all the certificates issued to the user in there. However, there are no references to the private key - I believe this is stored on the Local computer and if you check out the "Personal" folder, you should see one certificate in there that matches one of the AD certs, but will have a key on the icon. Opening up the Certificate, and you should see a note at the bottom saying "You have a private key that corresponds to this certificate". Without the private key, you cannot decrypt anything that has been encrypted by a third party with your public key. The point of the Private Key is that its supposed to be private, so publishing this in AD is probably a bad idea.

    Our issue is that we us a LOT of RDP sessions to AD joined servers, and users are also issued with certificates for every machine they login into via RDP. I can see on real way of figuring out what machine was used to generate what certificate. I really want to get away from all these multiple certs, but of course would run into the same problem.

    I would love to hear what the original writer as a"Microsoft Premier Field Engineer" would say on the subject.

  • Anonymous
    January 15, 2015
    Hello Chris,

    Thanks for your feedback.

    Correct: i can see certificates attached to my AD user in "AD User Object" store. But i can't use them on web sites (for authentication, i don't need to use them for decryption).

    By the way, i opened a case to MS support. First answer was to enable Creadential Roaming using GPO (User Configuration / Policies / Windows Settings / Security Settings / Public Key Policies / Certificate Services Client - Credential Roaming Settings). Tests are on going...

  • Anonymous
    April 14, 2015
    Hi Gregg,

    Good article. Thank you very much. I have a question for you:

    After making change(s) to the "Certificate Templates”, can I use "reenroll all certificate holders" instead of using "New Template to Issue"? What are pros and cons?

    Thanks in advance.

    AH

  • Anonymous
    June 02, 2016
    Sorry, I know this is an old post but I assume that you do need credential roaming enabled for this to be functional with users logging on to multiple machines to use the same user cert?MrBlGmog - not if you have your autoenrollment GPO settings configured correctly....

  • Anonymous
    January 30, 2017
    The comment has been removed

    • Anonymous
      May 29, 2017
      I see the AD user certs get stored in Active Directory User Object instead of Personal which Cisco Anyconnect is not aware of and therefore dose not see the SSL cert. Anyone know of a way to have the user certs stored in personal instead of Active Directory User Object, or how to tell Anyconnect to check Active Directory User Object?