Multifactor authentication in Windows – Part 2: Preparing Devices on XP and Windows 2003

If you missed the first part in this article series please read Multifactor authentication in Windows – Part 1: Smart Cards and USB Tokens

If you would like to be notified when Martin Kiaer releases the next part of this article series please sign up to the WindowSecurity.com Real time article update newsletter.

Why you need a CSP client

In the previous article, we advised to make sure that the chip OS on a smart card or token is compatible with the CSP you want to use. Before we get started with a deployment sample, it would be a good idea to briefly cover what a CSP is and why it’s such an important component when working with multifactor authentication in Windows.

Basically, a Cryptographic Service Provider (CSP) is a piece of middleware that lies between the security device and the Windows OS. Figure 1 below illustrates how this is done in Windows XP and Windows Server 2003:


Figure 1: The role of the CSP in Windows XP and Windows Server 2003
As you can see in the above illustration, the communication between an application that uses multifactor authentication and the crypto device is done through the CryptoAPI functions. Some vendors handle various advanced functions and features in their own CSP, while others take advantage of the functions and features that are already included in Windows. This is an important concept to understand, since this is where things differ between Windows XP / Server 2003 and Windows Vista / Server 2008, as we’ll explain in our next article of this series.

For example, the Windows versions that are currently supported by Microsoft already include built-in support for various smart cards. This means that you don’t need to install a separate CSP. All communication to/from the smart card is done through the CryptoAPI as mentioned before. However, if your preferred smart card solution is not on this list, then you simply need to make sure that you have implemented a CSP that’s supported by the card vendor, so that you can use your smart card solution with Windows. What’s important to note however, is that CSP functionality is always needed, no matter whether you use built-in supported features or use vendor specific features that are included with the security device.

Now that you have learned the basics of a CSP, it’s time for us to take a quick look at how this could be done in real life.

How to prepare a 3rd party CSP client for Windows XP and Windows Server 2003

We are not going to give a detailed step-by-step guide on how this is done. We will however show you some of the various options you can include with a CSP and how you can install a 3rd party CSP client, once you have attached a policy to the CSP client.

For this example, we want to accomplish the following:

  • Implement a smart card solution that prepares the card so that we can use it with Windows XP and Windows Server 2003 by integrating it with a Microsoft based PKI.
  • Include a secure policy that is enabled when users enter their pin code to access the contents on the smart card.
  • Create a CSP client that can easily be installed on computers or server in an enterprise environment.

To help us accomplish the requirements listed above, we will be using a product from SafeNet called “Borderless Security”. We don’t want to focus on the application itself as such, but rather use it to show the principles behind a smart card implementation, so you can get an idea of how you configure a 3rd party CSP for your multifactor authentication solution. With all this information, it’s time to get started with our example.

  1. We have installed the SafeNet Borderless Security application on a server and are ready to create and configure a CSP client for our Windows XP and Windows Server 2003 based computers.
  2. We start the management console for SafeNet Borderless Security. The first thing we need to do is associate an existing PKI to our smart card solution. This is an important step in our example, because we would like to use certificates for authentication when we enroll and configure smart cards for the users of our infrastructure. A typical smart card solution in a Microsoft based infrastructure requires a PKI to provide certificates with public key/private key pairs that enables account mapping in Active Directory. It should be noted however, that a PKI is not necessarily required when implementing a smart card solution, but this depends on the 3rd party CSP solution. Some vendors support regular password protection of the contents being stored on the security chip. Certificates are a useful setup for various reasons, including that it enables us to centrally disable a smart card by revoking the associated user certificate from Active Directory. Notice the following arrows in Figure 2 below:


Figure 2:
Here we link the smart card solution with an existing PKI

  • The Certificate Authority Name is configured to point to an issuing CA in our Microsoft based PKI.
  • Once we are linked to a CA, we’re able to choose one of the available certificate templates in our PKI. For this example, we’ve chosen one of the default certificate templates called “Smart Card User”, but it might as well have been a version 2 (Windows Server 2003) or version 3 (Windows Server 2008) based multipurpose certificate template that was chosen instead.
  • It’s highly recommended that you choose a key pair size of 1024kb or more, to protect the certificate that will be used during the preparation of a smart card. A key size of 512kb for a certificate is not recommended anymore.
  1. Whenever a user needs to have a smart card issued, the smart card should be initialized (i.e. prepared) with a security policy that controls the pin code length, number of retries, etc. In Figure 3 and 4, you can see some of the security options (policies) that we can attach to our CSP.


Figure 3 and 4:
Here you can configure various policies settings for the pin code protection, etc

  1. For our example here, the final thing we need to do is prepare a CSP client package that contains our settings from the previous steps. With SafeNet Bordless Security, we have many wizard driven options that can be configured. Please see Figure 5, 6 and 7 for some of the many options you can include with your CSP client.


Figure 5


Figure 6


Figure 7

  1. Once you are done selecting what features you want included with your CSP client, the wizard will create an MSI package for you, which can be distributed to your client computers and servers, using your preferred method of software deployment (see figure 8 and 9).


Figure 8


Figure 9

  1. The final thing you need to do is go to the desktop client or server, where you want smart card support to be enabled.
    a. Make sure that the newest driver for your multifactor authentication device is installed and working.
    b. Install the CSP client package and make sure that Windows can see the authentication device. Figure 10 shows you how this looks like, when our CSP client we created in this example is installed on a computer.


Figure 10:
Our CSP client has been installed and is ready to serve as the middleware for our multifactor authentication tasks in Windows. The blue card on the taskbar icon indicates that a smart card has been inserted

  1. The CSP client is installed and ready for use, by applications that support or require multifactor authentication. Some of these applications could be the following:
    a. MSGINA (i.e.) your Windows Logon screen. Insert a smart card or token, enter your pin code and authenticate. You can control how Windows behave when you use smart cards by adjusting a few settings in a group policy.
    b. EAP-TLS or PEAP-TLS for authentication during VPN connections and wireless access, etc.
    c. A CMS (Card Management System) solution used to issue smart cards and tokens. In our example, we used a “light” product from SafeNet, but if you need to issue 50 or more smart cards then consider a real CMS solution from Intercede (SafeNet), Microsoft, Entrust, Aladdin, etc.
    d. Various biometric solutions, that use everything from finger print readers to iris and face recognition.

A CSP can also be important in other scenarios which we haven’t covered in detail in this article. For example during a PKI implementation, you will have the choice of using either Microsoft’s own CSP or a 3rd party CSP. You would normally use a 3rd party CSP when you choose an HSM solution to protect the CA’s private keys.

Conclusion

In this article we have tried to show you the importance of the middleware that’s responsible for linking a multifactor authentication solution with Windows. In the next article we will show you how the game changes a bit with Windows Vista and Windows Server 2008 and what you should be aware off, when implementing a multifactor authentication solution for these platforms.

Links:

If you missed the first part in this article series please read Multifactor authentication in Windows – Part 1: Smart Cards and USB Tokens

If you would like to be notified when Martin Kiaer releases the next part of this article series please sign up to the WindowSecurity.com Real time article update newsletter.

Leave a Comment

Your email address will not be published.

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top