The problematic “Publish certificate in Active Directory” option


I am writing this blog  and others to explain how things work and some ways deployment and operational tasks can be handled. In other words, these postings are for demonstration purposes only. Since I am not familiar with your organization or environment I do not know if these steps are applicable to your environment or are even safe to perform in your environment. It is recommended that you contact Microsoft Support prior to making changes in your environment to ensure that these steps are applicable to your environment, and are safe to perform in your environment. By writing this blog I am in no way recommending that you perform these steps in your own environment. If you choose to follow the steps outlined in this or other blog postings on this site, you are assuming the risk for your actions.


So, a little bit of background. You may or may not have noticed that certificate templates have this Publish certificate to Active Directory option. So, what does this do? Well the answer is that it publishes the resulting certificate to the userCertificate attribute to the user or computer depending on whether the template is a user or computer template. An example of this settings is in the screenshot below.

So, why would you want to do this? Honestly, there is not really many good reasons for doing this. Theoretically, this would be useful when using Email Encryption or Email Signing. So, for email encryption if I wanted to encrypt an email to a user a could pull their certificate from AD and the ecrypt the email with the public key from the certificate. And for email signing if a user is trying to validate a signature they can retrieve the signers certificate from AD and use the public key to decrypt the signature so the hashes can be compared. Theoretically, the access to the users public key could potententially allow a user to give access to another user to an EFS encrypted file. However, this last option I do not have any experience with.

That being said, most organizations do not use email encryption and signing or EFS. Email encryption and signing are a problematic because getting the required certificates to all devices on which a user can check email is extremely difficult if not impossible. Think of all the devices you check email on and imagine trying to get the same exact certificate installed on all of those devices. EFS is problematic for file encryption because the process is very manual and honestly not very enterprise friendly.

So, in short although you can publish certificates to Active Directory there is most likely no need for you to do so.

The problem

So, what is the problem with this setting. For a user certificate the user will in a typical configuration enroll for a new certificate each time they log onto a new machine. If the template is configured to publish a certificate to the userCertificate attribute on the user. So, for a user that such as an IT administrator who logs onto many systems they will publish a large number of certificates to their userCertificate attribute. Another situation where this occurs when there is an MDM solution in place and the MDM uses a service account that requests certificates on behalf of it’s clients. If the certificate template that it leverages is configured to pubish the certificate to Active Direcotry it can bloat the userCertificate attribute for that service account.

So, the main problems are if many users are publishing their certificates to Active Directory it can lead to bloating of the AD database. If it is a single user publishing many certificates to it’s userCertificate attribute it can bloat that attribute in Active Directory.

Once the attribute becomes too large, certificates will no longer be able to publish certificates to the attribute and eventually it can interfere with AD replication because the attribute may be too large to replicate.

Investigating the problem

It is pretty straight forward to determine the severity of the problem using PowerShell. The following script will search AD and display the results:

get-aduser -filter * -property usercertificate | select name, distinguishedname, @{name=’CertCount’;expression={$_.usercertificate.count}}

Alternatively, you export the results to a CSV file with:

get-aduser -filter * -property usercertificate | select name, distinguishedname, @{name=’CertCount’;expression={$_.usercertificate.count}} | Export-Csv -Path .\userCertificate.csv

Clean Up

The following command will clear the userCertiifcate attribute for all users. Before running this command make sure that you do not need the userCertificate attribute populated.

Get-aduser –filter * | set-aduser –certificates $null

Prior I had one account “chdelay” that had 6 certificates in the userCertificate attribute and after running the command that user now has 0.

Thanks for visiting,