TekWorkshop

Getting Started
Sure I can login into my Enterprise by typing user name, password and domain or computer name. And yes, my new T61p laptop is outfitted with a fingerprint reader, but how about the smart cards? While with Windows 2000 smart cards were a pain, there were also issues with vendor support at Vista rollout. Now we are on the verge of Windows 2008 going RTM, are we ready?

Before starting on the project I had to address a few concerns:

Support for my x64 OS
Interoperability with prior OS (Windows XP and Windows 2003 at the minimum)
Ability to “cut” my own certificates to be imported into the smart card.

Obtaining the Hardware
After exploring online retailers a few things had emerged:
Vista support was usually not listed and even if it was, there was no mention about x64 support in most places including manufactures own websites. Only after the close examination of the drivers the search was narrowed to a few candidates.

The most straightforward selection was GemPC smart card from Lenovo (OEMed from Gemalto). The card was available for purchase with a new ThinkPad for just $50, while priced at $59 when purchased separately. Surprisingly, the one that I ordered did not fit my PCMCIA slot and was returned back to Lenovo (luckily avoiding 15% restocking fee). Purchase of GemPC400 card (also OEMed from Gemaltoby Lenovo) was $85 and was not an option due to a 4 weeks backorder.

Since my next x64 compatible candidate was SCM's SCR243, I did find a broad range of prices it was available for. Finally not without hesitation I purchased one for $36 ( $9.00 shipping and handling) and although the vendor had a seriously damaged reputation, the card did arrive in a few days and was operational with no visible damage, although with no drivers.

SCM and Gemalto's Orange combination

Fig 1. SCM PCMCIA card and Gemalto's ".Net IM V2 - ORANGE" smart card

Now I had a PCMCIA smart card reader, downloaded and installed the drivers, how about the smart cards? Well, I had a few from the conferences I had attended, one of which turned out to be exactly what I wanted – the Orange .NET card which was given to all attendees of Citrix Expo 2007 in Las Vegas.

Gemalto made it easy to hunt all the tools I needed by providing URL on the smartcard itself. The beauty of the utilities with which I was able to flush the card and enable my own PIN was the fact it was browser based and compatible with my x64 hardware (use these on-line tools only for non-production systems, otherwise get local utilities).

Creating Certificates
Now it was the turn of my Windows 2003 certificate server to do the job. I did not expect any challenges using both Browser and MMC certificate enrollment, however that was not the case – I was facing the issue of incompatibility of the web certificate enrollment on Vista client with a Windows 2003 back-end. The solution to this puzzle is described in detail within the Microsoft article KB922706 which boils down to the following:

Install web certificate enrollment on Windows 2008 Server. The actual certificate authority is not required as long as we get the web components installed - asp (not aspx!) pages for the most part. You can point this installation to the actual certificate authority for testing purposes, but the web files are what we are after.
Restart Windows 2003 server in a “safe mode” (the 2003 server where the IIS server is to be updated with a file set from the Windows 2008). This is required since directory CertControl needs to be removed.
Keep only Certdat.inc file and Certenroll folder and delete the rest of the files
Change Certdat.inc include file by removing control versions entries (at the end of the file), or just quoting them out:
        sXEnrollVersion="5,131,3686,0"
        sScrdEnrlVersion="5,131,3790,1206"
        sScrdW2KVersion="5,131,2195,5583"
Make sure to update any references to include files in ALL the files (not only asp) since the path had changed – from to.
Restart Windows 2003 server and try to enroll the certificates – web pages should be operational.

At this point we are ready to create certificates. Make sure that Smartcard Logon or Smartcard User templates are available at your server for enrollment. To make sure they are you can use MMC to add these templates to the list of the available options:

Certs

Fig 2. Certificate templates (configured on Certificate Server)

In production template customization will be a big plus, but we skip it for now.

So, we continue with enrollment and get the certificate. The first indication that something is not going well is the absence of the PIN request at certificate installation – certificate did not go into the smart card storage but into the user’s personal certificate store. Although this is where certificates will show if they are found on the smart card, they are not on the card but on the computer itself. Examination of the new certificate reveals that it was not marked to have private key exportable and thus cannot be imported into the smart card from the PFX file.

Note: This is what we would expect if the certificate was already on the card – smart cards by design do not allow export of certificates with private keys and as such Microsoft Certificate server was configured to enforce that.

After googling around for some time without any luck, I did try to look through the certificate enrollment code to see if anything could be done to get around this limitation and generate the certificate based on the smart card compatible template with the exportable key which will allow the import of that certificate to the card. The solution was simple – issue exportable keys by changing one line of code in certrqma.asp file at Line 1495:

if (document.UIForm.cbMarkKeyExportable.checked) {
    nGenKeyFlags|=CRYPT_EXPORTABLE;
   } else {
   // try to export anyway
    nGenKeyFlags|=CRYPT_EXPORTABLE;
   }
Now all certificates that were saved to the personal Certificate Store came with exportable private keys and thus could be exported as PFX files! With these PFX files I utilized convenience of Gemalto’s certificate import and populated my Orange .Net card with several identities including the key for my certificate authority:

Fig 3. Gemalto's on-line utilities for their Orange .Net cards

Please note that unlike some information on the web the private keys marked as not exportable are NOT EXPORTABLE and Microsoft stands behind this 100%.

Events triggered by Smart Card Removal
At this point the smart card was ready. The first test was to equip my Vista with ability to log me in via that card – that was smooth and easy with all identities on one card available with one PIN. But how about computer lockdown on smart card removal? Well, that required two steps:

Fig 4. Adjust your local computer policy to act on smart card removal.

On Vista there are 4 options available for REG_SZ value scremoveoption:

0:

No Action

1:

Lock Workstation – user session locked on smart card removal

2:

Log Off – User logged off on smart card removal

3:

Log Off – User logged off on smart card removal
Disconnect from remote Terminal Server Session – removal of the smart card disconnects the session without logging off the user. This allows the user to insert the smart card and resume the session later, or at another smart card reader-equipped terminal, without having to log on again.

Final step - make sure that smart cards service "Smart Card Removal Policy" SCPolicySvc is operational to act on smart card events:

Fig 5. Smart card related Services

One can go further and lock the system down for interactive logons to be limited to smart cards only, which was not implemented within this test.

Working with MSTSC on Vista-to-Vista or Windows 2008 server
The next target was smart card logon with Terminal Services client. Smartcard authentication support by Microsoft RDP Client MSTSC.EXE provides both convenience and enhanced security. One can store certificates for different identities on one smart card and provide a single Smartcard PIN for any of the identities to login with.

Fig 6. MSTSC and multiple smart card identities

As it turned out it was very straightforward to get smart card authentication going with RDP connections to either another Windows Vista machine or Windows 2008 servers. However the same turned to be more adventurous when trying connection to Windows XP or Windows 2003 servers. Since the smartcard authentication is assumed operational between two Vista machines, MSTSC.EXE client is a priori configured for smartcard redirection:

Fig 6. Smart card device redirection

RDP Connections from Vista to "legacy" XP or Windows 2003 server
Login to Windows 2003/XP machine might present the following message:
“The card supplied requires drivers that are not present on this system. Please try another card.”

Fig 7. Smart card authentication error within RDP connection Vista-to-Windows 2003 server.

This is encouraging since that does assume the remote server was aware of the smartcard redirection. Further behavior examination of the redirected smart card on the remote server via free diagnostic tools (we have used both SCM Microsystems and web-browser based tools from Gemalto) confirms that card is functional but… not for authentication.
What can be that different? Look at smartcard related Registry key:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Cryptography\Calais\SmartCards

Shows that our test Vista machine (happened to be Sp1 Beta build 6.0.6001.17128) has only two smartcard types listed: “Axalto Cryptoflex .NET” (owned by Gemalto) and “Infineon SICRYPT CardModule Card”.

Fig 8. Smart cards on Vista

Our Windows 2003 Server with SP2 and all the latest default patches does list more smartcards (10 of them to be exact) but not the ones listed on Vista:

Fig 9. Smartcards on Windows 2003 Server, Sp2

Fortunately the discrepancy can be fixed with an updated Microsoft Base Smart Card Cryptographic Provider which was available at the time for x86, x64 and ia64 systems - KB909520
Update produced… the missing 2 providers and did resolve the login issue on both x86 and x64 tested during this exercise:

Fig 10. Windows 2003 server after Microsoft Base Card Cryptographic Provider update

Fig 11. Prompt for the smartcard pin at the remote Windows 2003 server

As a closing note I have to praise smart card redirection within RDP - cards are fully functional not only for authentication when accessed from within the remote session but for certificate enrollment as well.

Test system:

Smart card reader: SMS-243 PCMCIA
Smart card: Gemalto’s Orange .NET Card
Client computer: Lenovo T61p laptop
OS: Windows Vista Sp1, build 6.0.6001.17128, Windows 2003 E R2 Server, SP2