FIM CM “Operation timed out” message while trying to add a new certificate template to a profile template

When trying to add a new certificate template to a profile template in FIM CM 2010R2, the product tries to enumerate all existing certificate templates in the configuration partition of Active Directory. When an organization has a large number of complex templates (with large ACLs, etc.) FIM CM times out while trying to enumerate them.
This is both an undocumented issue and a rare occurrence. I could (partly) reproduce this, by adding around 400 certificate templates in a FIM CM lab. The result was that the FIM CM certificate templates web page appeared after around 60-90 seconds, instead of the 5 seconds that the page takes to appear using the default templates loaded by AD CS.
There is a workaround that solves the problem – add an explicit Deny Read ACL for the CLMAuthagent account (or, even better, a security group that contains this account) to all templates that are not going to be used by FIM CM. This in effect makes the product unable to read them and thus prevents the timeout while doing it.

Having fun with Virtual Smart Cards for S/MIME usage (part 2)

After a long time of inactivity, we are back with the second part of this mini-series of the virtual smart card deployment guide.

Configuring Outlook
Luckily (or, should we say, by careful design?) there are very few things to configure in the Outlook client. The certificate(s) that we are going to issue, either encryption or digital signature ones (or both), are going to be immediately recognized by Outlook. Subsequently, they are going to be placed in the correct containers, which can be seen by taking a look at File -> Options -> Trust Center -> Trust Center Settings -> Email Security -> Settings. There, we can find the relevant text box which will indicate the encryption and the signing certificates. If we create two different certificate templates for the relevant purposes, Outlook will automatically understand the purpose of each certificate and place each one in the correct container. If we create one certificate for both purposes, which is not recommended due to the sensitive nature of the signing operations, Outlook will use this one for both operations and you will see it both text fields in that window.
One more thing to note about Outlook is that the sign and encrypt buttons will appear in the Outlook’s “New Email” window only after the first encryption or signing takes place. This is a bit awkward for users. One way to circumvent this behavior, and thus “instruct” Outlook to always show the buttons, is to push a specific registry to Outlook clients. This key can be found at HKEY_CURRENT_USER\Software\Microsoft\Office\15.0\Outlook\Preferences. The new entry should be SecurityAlwaysShowButtons (as a DWORD) with value 1. This example refers to an Outlook 2013 client, so for previous versions of Outlook, we need to replace 15.0 with the specific version (for example, 14.0 for Outlook 2010 etc.)

Creating the virtual smart card
We create a virtual smart card in the user’s PC by opening an administrative command prompt and running the following command: tpmvscmgr.exe create /name VSC /pin prompt /adminkey random /generate. Let’s explain what this command’s parameters mean (more information can be found in the Understanding and Evaluating Smart Cards document):

  • name refers to the name that we give to the virtual smart card – it could be anything we choose.
  • Pin is, of course, the PIN that protects the VSC – in this case, prompt prompts the user to enter one of his/her liking. It is highly advisable that, at this point, the PIN should be entered by the user and be known only to him/her. The documentation has small error at this point.
  • Adminkey is the administrator key that can be used to administratively access the VSC and reset it, if locked
  • Generate is needed if we are not using FIM CM for the creation of the VSC (which, by the way, is highly recommended for most demanding deployments)

The process of TPM virtual smart card creation will take some time (usually around 2-3 minutes, depending on the hardware). You have to wait until the final confirmation by the system is displayed. The Instance ID of the virtual smart card reader should appear as ROOT\SMARTCARDREADER000 by default. We can also verify the creation be checking the Device Manager, where we will find the newly created reader with the name that was entered at the creation command.

In the next post, we will share some final details on VSC creation and Outlook.

How the virtual smart card appears in Device Manager

VSC in Device Manager

Process of virtual smart card creation

Process of virtual smart card creation

Having fun with Virtual Smart Cards for S/MIME usage (part 1)

Recently, at one of our larger Premier customers, we designed and implemented (initially in a lab environment) a Certification Authority, mostly for SMIME usage. During initial discussions, we considered virtual smart cards (VSCs) for his Windows 8 computers. The experience was interesting enough to guarantee at least two blog posts🙂
In this first part, we are going to describe the prerequisites and prepare everything for a successful virtual smart card rollout.

Starting from the clients – TPM chips
We are not going to get into details about TPM architecture, as there is abundant information in the internet. We will just mention the details which are important for VSC implementations.
First off, we have to make sure that the computers which are going to be part of the implementation actually contain a TPM chip. I was not planning to mention that at all – however, I found out that there are computer (and/or motherboard) manufacturers who claim to support TPM instead of supplying TPM chips within the systems. This is especially true in desktop computers, some of which might have a TPM slot, but no TPM module inside. So, you have to make sure that your systems do actually contain the module before rolling out the VSCs.
After that, make sure to enable TPM support in the BIOS’ settings. This is the most common mistake, as many people fail to understand that even if a computer has a TPM chip, most probably it is not enabled by default in the BIOS. Finally, after initializing TPM on Windows (http://technet.microsoft.com/en-us/library/cc753140.aspx), we are ready to set up our Certification Authority (CA).

Back to the CA – Virtual Smart Card Certificate template
We are not going to describe how to setup a CA, since it is out of the scope of this blog post. However, it is essential that we get into details about how to properly create the needed certificate template for VSC issuance.
Since VSCs are not that much different from a regular smart card (at least from a CA perspective), the steps that we have to perform in order to configure the VSC template are pretty much the same as the ones for a real, hardware smart card deployment. The certificate template that has to be duplicated is, as expected, the Smartcard Logon one and the fields that have to change are in the following tabs:
a) In the General tab, we just have to label the duplicated template
b) In the Request Handling tab we have to change the Purpose to Signature and smartcard logon. If not already selected, we should select Prompt the user during enrollment. Finally, we should click Requests must use one of the following providers and select Microsoft Base Smart Card Crypto Provider.
d) Since we are going to use the resulting virtual smart(s) for S/MIME operations, we should also make sure that the fields in the Subject Name tab include e-mail name in subject name and E-mail name are also checked.

Virtual smart card settings for SMIME
Virtual smart card settings for SMIME

Now we are ready to delve into the wonderful world of virtual smart card deployment. In the next blog post, we are going to visit the client once again, prepare it for VSC issuance, issue the VSC and configure it for Outlook/Exchange S/MIME operations.

Strong key protection for Windows client’s private key encryption operations

During customer visits, I am often asked what is the most secure way to store and handle private key material. As we probably all know, two-factor authentication methods are the ones that are usually described when private key protection is of the utmost importance. So, in case of storing the private key of an Offline or Issuing Certification Authority, a Hardware Security Module (HSM) would be proposed, and for digitally signing emails or documents, a smart card would be ideal to store the key pair. Some companies, however, are reluctant to introduce hardware devices to their environment for two reasons: a) they believe they will add complexity to an already complex IT environment and that would degrade the end-user experience and b) they are not prepared to bear the added cost. In case of smart cards, that would amount to a pretty cheap device (around $20-40 or more, depending on quantity and software used). In both situations, the companies’ IT (or Security) departments do have a point, but they usually still need to have an extra layer of security for their end users. So, is there any “poor man’s added security” for private key usage?

Strong key protection while enrolling a certificate

Strong key protection while enrolling a certificate

Strong key protection password

Strong key protection password window during enrollment

Well, in the client-side of the Windows PKI world, the folks that designed CryptoAPI added an extra security feature called strong key protection. In essence, what strong key protection does, is to force the user to enter a user-defined password which protects the private key whenever (almost, as we are going to see later on) this is going to be used for a cryptographic operation. When such an operation (for example, digitally signing an email) is performed, the user will have to provide this password and only then the underlying client (Outlook, in this case) will be able to have access to they key.

 

The prerequisites to enable and use this feature are to select the relevant option in the Request Handling tab of the certificate template, and then have the user enter a password during user certificate enrollment. There are two caveats here that are hard to spot: a) there is now way to force a user to select the High security option and b) once you enter the password in Outlook, for example for signing or decrypting, the system will not ask for it again except if you close and re-open the application. Moreover, the password entered by the user if the certificate is generated by a Windows XP client will not conform to the domain policy’s complexity requirements – Windows Vista and later clients, though, will conform to it.

Partly due to the previously mentioned problems, but mainly due to the fact that strong key protection is not an actual two-factor authentication, I do not recommend it as a viable security solution for handling private key material. However, there are organizations where security is not a top priority, and it’s good to have choices🙂

Certificate template settings for strong key protection

Certificate template settings for strong key protection

Troubleshooting certificate autoenrollment

Troubleshooting one of the most important and versatile parts of the Windows PKI world is a fairly complex process, since it involves a plethora of prerequisites in order for it to work correctly. Most of the times, consultants and administrators create a lab before a PKI deployment where autoenrollment usually works relatively easy – especially if the lab does not resemble the true production environment in anything other than the domain names.

In a very recent Windows PKI lab deployment for a major customer, we had a fairly lengthy autoenrollment troubleshooting session. The lab setup was a close-match replica of the production environment, as the Active Directory has been recreated using a backup of an actual production domain controller, as well as restored Exchange servers. The case was interesting: as it always seems to happen, everything was in place for autoenrollment to work, yet the process would not fire up at all.
To make a long story short, and after finding that no firewall, virtualization or general networking issues were involved, we finally tracked the autoenrollment failure down to two issues: the one is frequently seen in large organizations and has to do with GPO (Group Policy Object) precedence and settings’ overlapping. In our case, a GPO with no autoenrollment configured would prevail in the OU that the auto-enrolled users would reside and thus would not push the relevant settings to the clients. The second issue, however, was much more complex to target: as the environment has been set up many years ago, many administrators and third-party software packages have made a lot of changes in the production. One of the changes we found out that created problems, was the membership of two built-in groups: the Users and the Certificate Service DCOM access group. In the first one, the default membership should consist of Authenticated Users, Domain Users and Interactive (it did not, as you can imagine). In the second one, the Authenticated Users group should exist as a member (again, it was not – the list was empty).

We should say that in cases of autoenrollment failures, one should focus on:

  1. Certificate template security – make sure your users/computers have Read, Enroll and Autoenroll permissions and that the Authenticated Users group has not been deleted (it should be there with Read-only permissions).
  2. GPO precedence – make sure that you create a separate, enforced GPO to enable autoenrollment or, at least, that the GPOs applied to your users/computers finally lead to an enabled state for autoenrollment (RSOP is a great client-side tool to discover such issues).
  3. Group membership – the Issuing CA’s computer account should be a member of the Cert Publishers group in the intended enrollment domain; also, the Users and the Certificate Service DCOM Access built-in groups should have the membership detailed previously in this post.
  4. Server-side certificate issuance errors – a poorly configured certificate template (for example, one that requires an e-mail address in order for certificates to be issued when some user accounts may not have an e-mail address in AD) could lead to a certificate issuance request that is left in a pending or failed status, as seen in the Certification Authority console. Do check this by manually initiating a certificate request through an MMC console or a Web enrollment page (if configured) and make sure that the manual enrollment method actually succeeds in creating the intended certificate.
  5. Networking issues – blocked ports (RPC, HTTPS etc.) as well as problematic networking software or hardware (drivers etc.) could lead to problems in autoenrollment, Again, check if a manual request can succeed.

Update for CTLs in disconnected environments

In June 2013, Microsoft issued an update that makes the update of CTLs (Certificate Trust Lists) easier in disconnected environments. For the purposes of automatic updating, Microsoft considers any environment that does not have access to the Windows Update site as “disconnected.”

The new update enables Windows PKI administrators to:

  • change the update location from the predefined Windows Update URL to an intra-organizational shared folder that is reachable from disconnected clients
  • selectively disable/enable updating of either trusted or untrusted CTLs
  • create a custom set of trusted root certificates and distribute it via Group Policy.

The relevant knowledge base article can be found here, and its supporting documentation here. It is worth noting that the update is included in Windows Server 2012R2 and Windows 8.1, and does not apply to Windows XP and/or Windows Server 2003.

Microsoft advisory and update on MD5 deprecation

On August 13th, Microsoft released a security advisory update (2862973 – Update for Deprecation of MD5 Hashing Algorithm for Microsoft Root Certificate Program), applicable to Windows Vista/2008 and later client and server operating systems. According to the associated TechNet article (Protecting Against Weak Cryptographic Algorithms) the functionality is already built into Windows Server 2012R2 and Windows 8.1 preview editions and should be included when the final bits of 2012R2 and 8.1 ship. Essentially, this update gives administrators control on logging and/or blocking weak algorithm-based certificates that are known to be vulnerable to multiple attacks. More detailed information can be found on the link above.