If we use the Microsoft Exchange server and Outlook and utilize email encryption, it's a good idea to place the encryption certificates of individual users in the Active Directory (AD). Then these certificates (to put it simply) are automatically distributed to all users as part of the GAL (Global Address List). So users can send encrypted messages to each other.
Publishing Certificates to AD
Certificates are stored in the attribute of the user object in AD. We can place a certificate with a user (Publish certificate in AD) in several ways:
- When the certificate is issued - if we use MS CA, we can set the template to automatically publish the certificate to AD
- Using Outlook - users can publish their configured encryption certificate themselves in Outlook (in the same place where the certificate is set for use), in Outlook 2010 it's File - Options - Trust Center - Trust Center Settings - the Publish to GAL button
- Using ADUC - when we display the properties of a user account using Active Directory Users and Computers (ADUC) and have the Advanced Features display enabled, we see the Published Certificates tab, where we can add and delete certificates
- Other options - using some commands like certutil.exe, PowerShell, or even with an extension from Quest for AD
Problem with the Offered Certificate
Everything would seem simple and clear, especially as long as everything works nicely. But as is often the case with Microsoft, the reality is much more complex. Recently, I encountered a problem where we switched to a new certification authority. So users needed to be issued new certificates, which were automatically published to the GAL (using the CA). But when someone sent an email to such a user, it was still encrypted with their old certificate. I deleted the old certificates in AD, but that didn't help. I deleted all certificates, but Outlook still offered the old certificate. I tried all the various options I described in the article Encrypting emails in MS Outlook and troubleshooting. But still nothing, until I finally solved the situation by looking at the details of the user object using the PowerShell command Get-ADUser. Then I managed to find the documentation that explained why the whole situation occurred.
How Certificates Are Stored in AD
It turns out that certificates are stored in the userCertificate attribute, which is often mentioned. The certificates are stored here in DER Encoded X.509 v3 format, and these certificates are displayed in ADUC on the Published Certificates tab. But certificates are also stored in another attribute, userSMIMECertificate, where they are stored in PKCS #7 format, including the entire chain of authority certificates.
Then, when we want to use a certificate in a client, it depends on the client which attribute it uses. For example, MS Outlook looks in the userSMIMECertificate attribute and if it doesn't find the certificate, then in the userCertificate attribute. And to make it even more complex, Outlook Web Access (OWA) does the opposite.
So when we delete old certificates for a user using ADUC, Outlook will still use them (and we'll even get the interesting situation where the new certificate is used through OWA). If we use the Publish to GAL function in Outlook, the certificates are placed in both attributes. And they are added, not overwritten. But if we use certificate publishing to AD when issuing the certificate, it is only stored in the userCertificate attribute.
Microsoft itself states in its article that you should only use one of these two attributes and definitely don't want to use userSMIMECertificate. It also recommends preventing users from publishing certificates from Outlook (as this attribute will then be used). A somewhat strange claim...
Deleting Certificates in AD
So in many practical situations, we need to delete certificates from the userSMIMECertificate attribute. For manual operation, we can use ADUC (from RSAT), where in the user properties we have the Attribute Editor tab. There we can simply find any attribute and delete its value. If we need to do this for the entire company, it's not very practical, and PowerShell would be an obvious choice.
In PowerShell (expanded with the MS AD module), we can use the following command, for example, which will show us information about the certificates. But unfortunately, it still only works with the userCertificate attribute.
Import-Module ActiveDirectory (Get-ADUser username -Properties Certificates).Certificates
But we can look directly at the attributes.
Get-ADUser username -Properties userCertificate, userSMIMECertificate | FL Name, userCertificate, userSMIMECertificate
And we can delete the content of the userSMIMECertificate attribute with the command below. The second line shows the option to delete for all users in a given container.
Set-ADUser username -Clear userSMIMECertificate Get-ADUser -Filter * -SearchBase "OU=Company,DC=company,DC=local" | Set-ADUser -Clear userSMIMECertificate
Outlook 2010 - Disabling the Publish to GAL Button
Disabling the Publish to GAL button can be done simply and elegantly using Group Policy. But we need the templates for Office 2010 (or the corresponding version), a topic I covered in the article MS Outlook and configuration with Group Policy.
The setting is located at the path User Configuration\Administrative Templates\Microsoft Outlook 2010\Security\Cryptography under the item Do not display 'Publish to GAL' button.
Removing Invalid Certificates from AD
While we're talking about certificates in the GAL, we'll certainly all run into the situation where the Exchange server will log warnings that a user has an invalid certificate or one with an expired validity period, and it won't be added to the GAL. To avoid these warnings, it would be good to automatically delete invalid certificates. If the certification authority doesn't do this for us, we'll have to help ourselves with a script.
We could certainly write a script in PowerShell with the AD module that would use the following information, but it wouldn't be anything simple.
(Get-ADUser username -Properties Certificates).Certificates[0].GetExpirationDateString()
(Get-ADUser username -Properties Certificates).Certificates | foreach {New-Object System.Security.Cryptography.X509Certificates.X509Certificate2 $_} | fl * -f
Fortunately, there is the company Quest and their PowerShell extension ActiveRoles Management Shell for Active Directory. Unfortunately, even their command only works with the userCertificate attribute. Here are a few simple examples of how to delete a user's expired certificate, an invalid one if the issuer's name contains the word "Company", or all certificates of all users.
Add-PSSnapin Quest.ActiveRoles.ADManagement Get-QADUser username | Remove-QADCertificate -Expired Get-QADUser username | Remove-QADCertificate -Valid:$false Get-QADUser username | Remove-QADCertificate -IssuerDN '*Company*' Get-QADUser | Remove-QADCertificate
There are no comments yet.