Deploying Smart Cards for Remote Access
Passwords of one form or another have been used for computer-based authentication for over a half a century. The day is coming quickly, though, when password-based authentication will seem as antiquated as crank-starting an automobile or having a television without a remote control. Oh, passwords will never go away completely, but they are fundamentally insecure, and that makes them increasingly dangerous as the computing climate changes.
The most obvious challenger to passwords is biometrics. The problem with biometric logons is deciding what characteristics to use for user recognition and how to analyze those characteristics quickly and with as little error as possible using technology that is relatively inexpensive. Faced with these requirements, it may be several years before biologons become common.
There is a compromise between biometrics, which uniquely identify an individual, and passwords, which only identify a user who knows a secret. That compromise uses smart cards. A smart card contains PKI key pairs issued to a user along with a small processor that can deliver those keys when called upon by a properly coded driver. Used in conjunction with a PIN, which is really just a fancy term for a password, the smart card links a unique commodity, the PKI tokens in the smart card, with a user who knows a secret, the PIN for the card.
The PIN is used solely by the Crypto Service Provider to give access to the tokens on the card. The PIN is not used in any logon function. When the user logs on to the domain, the public key certificate is sent to the domain controller as part of the Kerberos transaction.
You may doubt that your organization needs the level of security that smart cards offer, at least at the local desktop, but you should definitely consider them for remote users. Remote access opens your network to all sorts of nefarious galoots. By using smart cards to validate external logon requests, you have better protection against someone pounding away at your system looking for password vulnerabilities.
Smart cards come with sufficient memory to store tokens for a variety of purposes, such as logon, secure email (S/MIME), secure web access, and so forth. Many organizations put a picture on the card, as well, making them a physical access pass along with a virtual one.
Smart cards come in a variety of packages. Most look like credit cards with gold contacts on the outside for connection to the reader. (More advanced cards use magnetics and therefore do not have external contacts.) The reader connects to the computer via USB or the serial port. It is managed by a Cryptographic Service Provider (CSP).
Another popular form factor is a small dongle that can fit on a key chain. The dongle slides right into a USB port where it can be accessed by the CSP. The advantage is that no special reader is required. The disadvantage is the cost of the dongle, which is 3 or 4 times more expensive than a smart card.
The SecurID smart card from RSA does not incorporate a PKI token. Instead, it uses a two-part PIN consisting of a fixed portion known by the user and a dynamic portion that is generated and displayed by the card. The dynamic portion of the PIN (call the authenticator) changes every 60 seconds and is synchronized with a master server on the network. When the user logs on, she enters her static portion of the PIN and the dynamic portion of the PIN from the card along with her logon name.
If you want to avoid the need for a user to enter a PIN, you might want to take a look at the Sony FIU-710, also called the "puppy." This unit combines a fingerprint scanner and a smart card reader. The fingerprint takes the place of a PIN. The fingerprint scanner resists common exploits such as copper-sulphate coated gelatin impressions of fingerprints.
Selecting Smart Cards
Installing the infrastructure for smart cards looks complicated at first, but the steps are fairly straightforward. The hardest part is deciding which vendor to use. There are dozens to choose from. Visit the Hot List web site at www.andreae.com/hotlist.htm to start your search.
Two obvious candidates are products from Gemplus and Schlumberger because their drivers are built into the operating system. (Infineon - formerly Siemens - also ships a CSP in the shrink-wrap, but their chips are typically OEM'd in other solutions that might not use the same CSP.)
Even the two built-in vendors have elements that must be distributed. For example, the drivers for the Schlumberger USB reader are included in XP but the INF script isn't, so you must copy the INF script to the \Windows\INF folder on each desktop before inserting the reader in the USB port. The Gemplus reader requires a full setup to install the most recent drivers.
Here are additional vendors that have smart card solutions with support for Windows Server 2003 and XP and their products:
Active Directory Integration
Active Directory integration is important to avoid maintaining dual databases of user accounts. Some smart card vendors maintain a separate database that may or may not be coupled to Active Directory. This includes SecurID from RSA and ActivCard. There is nothing inherently wrong with a solution that is not fully AD integrated, but it adds complexity.
I prefer smart cards that use the existing Windows Kerberos authentication rather than their own proprietary certificate validation mechanism. This marries the certificates in the cards with a proven methodology for transporting them rather than a proprietary method that might have as-yet-unknown holes in it.
Here's how Kerberos integration works. When you use a Kerberos integrated smart card solution, the timestamp used as an authenticator, which is normally encrypted with the user's password hash, is instead digitally signed using the private key in the smart card. A copy of the public key certificate is included in the ticket-granting ticket request sent to the domain controller. The DC validates the public key certificate then uses the key to check the digital signature on the authenticator. If that succeeds, the remaining portion of the Kerberos transaction proceeds as it would with a password.
Token Management Utilies
Finally, during your evaluation, look closely at the utilities that ship with the card to set the PIN and format the cards. Make sure the vendor is keeping up with Windows XP and Windows Server 2003 support for these utilities. Often you'll find that the tools only run on Windows 2000 because the vendor hasn't adjusted the tool to run with the new Crypto Service Providers in Windows XP and Windows Server 2003.
A final checkpoint on your evaluation list should be ease of deployment. USB smart card readers are an ideal choice if your desktops have USB ports. You can use serial port readers for the older machines, although they are a bit slower and somewhat fussy to install, especially if you have modems and scanners and other paraphernalia stuffed onto the serial ports already.
Preparing the PKI for Smart Cards
While you're evaluating potential smart card vendors, you may want to start deploying a PKI and making preparations to issue certificates to smart card users. You must have at least one CA capable of issuing Smart Card User and Smart Card Logon certificates. Ideally, you would have multiple CAs for fault tolerance and security. See Chapter 18, "Managing a Public Key Infrastructure," for details on deploying a Windows Server 2003 PKI. If you choose to deploy a third-party PKI, be absolutely sure that you test the mechanisms for enrolling users and certifying the key pairs generated by the cards. Some vendors make this simple. Others don't.
As you deploy the PKI, keep in mind that you will need to have certain workstations dedicated to initializing the smart cards and certain individuals with administrative rights to burn tokens into the cards. The security of your smart card deployment is only as good as your processes for managing the cards. If Sally's admin assistant can call you on the phone and obtain a smart card for her boss, you don't have sufficient controls on your processes.
Also, remember that you may someday need to revoke a user's smart card certificate as well as disable his logon account. It is extremely important that you verify the functionality of the Certificate Revocation List (CRL) distribution in your PKI prior to beginning your smart card deployment.
You will also need to obtain Computer certificates for all remote access servers that accept smart card logons. The certificate is used to digitally sign the authentication responses so the client can verify the server's identity.
When you have selected your vendor, deployed the reader hardware, set up the PKI, and you have secure processes in place to enroll users, you're ready to proceed. Here are the basic steps:
Configure an enrollment station.
Prepare certificate templates in the CA and Active Directory.
Designate enrollment agents who can issue smart cards.
Prepare the cards using the vendor prep utility.
Issue certificates to the smart card on behalf of a user (enrollment) and test the result.
Configure remote access servers to accept smart card authentication and enroll the servers for Computer certificates.
Test the smart card authentication from various client types.
Configuring Smart Cards
Start by designating a particular workstation as an enrollment station. This should be a secure workstation with a smart card reader installed along with the vendor's card configuration utility. You'll need the utility to set the user's and the administrator's PINs on the cards and to unblock the card should the user exceed the maximum number of PIN attempts (typically three tries).
The enrollment station should be running XP or Windows 2000, depending on the vendor. If you are using a Windows Server 2003 PKI, you will need IE5 or later to interact with the Certification Authority via the web.
Prepare the Certificate Templates
The templates used for smart card logons are not installed by default on a Windows Server 2003 CA. Neither is the template for Enrollment certificates, which the administrators responsible for user enrollment will need. You must install these templates manually using the Certification Authority console (see Procedure 20.4). Figure 20.14 shows the default template list in the CA console.
Figure 20.14. Certification Authority console showing default list of certificate templates.
Procedure 20.4 Enabling the Smart Card User Template
Right-click Certificate Templates and select NEW | CERTIFICATE TEMPLATE TO ISSUE from the flyout menu. The Enable Certificate Templates window opens (see Figure 20.15).
Figure 20.15. Enable Certificate Templates window showing a list of templates that have not yet been enabled.
Select Smartcard User from the list and click OK.
Do the same for the Smartcard Logon template if you want to deploy only the logon features.
Do the same procedure again and this time select the Enrollment Agent template.
Verify that the templates are now listed in the main window of the console.
Close the console.
At this point, the certificate templates are ready for use in enrollment. Copies of the templates are placed in Active Directory where they are available to all Enterprise CA servers. (Standalone CAs do not use templates.)
The next stage is to issue Enrollment Agent certificates to the administrators who will be running the enrollment station.
Issuing an Enrollment Agent Certificate
A Windows Server 2003 CA will not issue a Smart Card User or Smart Card Logon certificate unless the administrator making the request has an Enrollment Agent (EA) certificate to use for digitally signing the request. The administrator's EA certificate must be physically present on the enrollment workstation.
The simplest way to obtain an EA certificate is to request it via the Certificates snap-in while logged on at the console of the enrollment workstation. Alternatively, you can obtain the certificate at the administrator's home workstation then make a copy of the certificate and put the copy on the enrollment workstation.
For security purposes, the CA will not issue an EA certificate to someone unless they have access permission to the associated template in Active Directory. By default, only the Domain Admins group and the Enterprise Admins group is on the access list for this template. To avoid giving your EA administrators such wide-ranging privileges, create a new group called Enrollment Agents and put this group on the access control list (ACL) for the Enrollment Agent certificate with Read and Enroll permission. This is explained in Procedure 20.5.
Procedure 20.5 Issuing Enrollment Agent Certificates to Operations Administrators
Log on at the console of the enrollment station as a Domain Admin or Enterprise Admin.
Use the AD Users and Computers console to create a new group called Enrollment Agents (or some other name you prefer).
Make the Operations administrator responsible for issuing smart cards a member of this group.
Open the AD Sites and Services console.
From the menu, select VIEW | SHOW SERVICES NODE to display the Services container. (If that option is not in the VIEW menu, make sure the very top icon in the tree is highlighted then try again.)
Expand the tree to Services | Public Key Services | Certificate Templates and locate the Enrollment Agent icon in the right pane (see Figure 20.16).
Figure 20.16. AD Sites and Services console showing Certificate Templates container holding the Enrollment Agent certificate.
Open the Properties window for the Enrollment Agent template and select the Security tab.
Add the Enrollment Agents group to the access list and give the group Read and Enroll permissions.
Close the console.
Open an empty console by entering MMC at the Run window.
From the menu, select FILE | ADD/REMOVE SNAP-IN.
Click Add to open the Add Standalone Snap-In window.
Select Certificate from the pick list and click OK. The Certificates Snap-In window opens.
Select My User Account and click Finish.
Click Close to close the Add Standalone Snap-In window.
Click OK to close the Add/Remove Snap-In window. The Certificates tree for the current user is now listed in the main window.
Expand the tree to Personal | Certificates.
Right-click Certificates and select ALL TASKS | REQUEST NEW CERTIFICATE from the flyout menu. The Certificate Request Wizard starts. If the wizard does not start, you either do not have sufficient rights to select any certificate (unlikely) or the workstation is not a member of the domain or it is unable to communicate with a domain controller to retrieve a list of certificate templates.
Click Next. The Certificate Types window opens (see Figure 20.17).
Figure 20.17. Certificate Types window showing list of certificate templates for which the user has Enroll permissions.
Highlight Enrollment Agent and click Next. The Certificate Friendly Name and Description window opens. Leave this blank.
Click Next. A summary window opens. Click Finish to save the changes and obtain the certificate. A message will notify you when the certificate has been successfully issued.
At this point, the administrator holding the EA certificate is ready to prepare smart cards for users at the enrollment workstation.
Enrolling a Smart Card User
The process called enrollment consists of obtaining a certificate for the public key generated as part of a public/private key pair by an engine on the smart card. This is done using a web interface rather than the Certificates snap-in because the web interface includes an ActiveX control for transferring the certificate securely to the smart card's memory.
To perform this procedure, you'll need a card that is compatible with the smart card reader. You can prep the card with a new PIN using the vendor utility, or you can assign the PIN during the enrollment process. For vendors other than Gemplus and Schlumberger, you will need to install the vendor's CSP in the enrollment station and all workstations using that vendor's smart card. There may also be additional components to install in Active Directory and the enrollment station.
You can only issue smart card certificates to users in the same forest as the CA. This ensures that domain controllers in the forest can validate the certificate when it is presented during logon. When you have the prerequisites in place, you're ready to begin. To enroll a user, follow Procedure 20.6.
Procedure 20.6 Enrolling a Smart Card User
At the enrollment station, point the web browser at the CA by entering its fully qualified name with a /certsrv tacked on—for example, server1.company.com/certsrv. A Welcome page like that shown in Figure 20.18 opens.
Figure 20.18. Welcome page from the Certificate Services web site running on a Windows Server 2003 CA.
Click Request a Certificate. The Request a Certificate page opens.
Click Advanced Certificate Request. The Advanced Certificate Request page opens (see Figure 20.19).
Figure 20.19. Certificate Services—Advanced Certificate Request page.
Click the option that starts out Request a Certificate for a Smart Card... The Smart Card Certificate Enrollment Station page opens (see Figure 20.20).
Figure 20.20. Certificate Services—Smart Card Certificate Enrollment Station page.
If the field next to Administrator Signing Certificate is empty, you did not obtain an Enrollment Agent certificate or you did not transfer the certificate to this computer.
Next to Certificate Template, select Smartcard User. This certificate type includes the Smart Card Logon usage, so there is no need to issue a separate certificate for the logon function.
If the Certificate Authority field does not now list a CA, you forgot to enable the associated template in the Certification Authority console.
Next to Cryptographic Service Provider, select the name of the vendor you're using for your smart cards.
If the vendor name does not appear on the list, you have not installed the vendor's CSP on the enrollment workstation.
Click Select User and find the user's name in the Active Directory search window. The user must have domain credentials. For testing, it's best to enroll yourself so you can immediately check the results.
Place the smart card in the reader and click Enroll.
If you've done everything right, the CSP will take over and display a window for entering the PIN assigned to the card. (Figure 20.21 shows example from the Schlumberger CSP.)
Figure 20.21. Confirm Smart Card PIN window.
The default PIN for a Schlumberger card is 00000000 (8 zeros). The default PIN for a Gemplus card is 1234. Never leave the card with the default PIN.
When the certificate has been stored in the card, the Enrollment Station page updates with a completion status message. Click View Certificate to make sure the certificate was issued to the proper user (see Figure 20.22). This is extremely important. You do not want to accidentally enroll one user then give the card to another user.
Figure 20.22. Certificate contents for a newly issued smart card user.
This completes the enrollment process. Now test the card to make sure it gives access.
Testing the Certificate
Any Windows Server 2003 or XP machine will accept a smart card logon request if the appropriate reader for the card has been installed. When the reader is found by the system, the window displayed by Winlogon is modified to show an icon of a reader and a prompt for the user to either enter a password or insert a smart card.
When you insert the card, you are prompted for a PIN. Enter the PIN that was assigned during enrollment. The only reason the logon should fail is if the user no longer exists in Active Directory or a domain controller and Global Catalog (GC) server are not available. (Like standard logons, a GC is required to obtain the user's Universal group memberships and to crack the UPN into the name\domain components.)
You should also perform at least one test of certificate revocation handling. Do this using the Certification Authority console to revoke a card issued to a test user. Publish a Delta CRL then validate that the user cannot log on using the smart card. The user should get a notification that the card has been revoked. See Chapter 18, "Managing a Public Key Infrastructure," for details on revocation publishing.
Now that the smart card infrastructure is in place, you're ready to configure the remote access server to accept smart card authentication at logon.
Configuring RRAS to Accept Smart Cards
Any Windows Server 2003 or Windows 2000 remote access server is capable of accepting smart card logons. You only need to configure the RRAS service to use Extensible Authentication Protocol (EAP) and to select smart card logons as the EAP method.
What makes the process a little more complicated than you would otherwise expect is that you must also configure the remote access policies if you are in Native. Don't forget to do this, because the RRAS server will refuse the connection even though you think that you've done everything correctly. Procedure 20.7 contains the details for preparing the server to accept smart card logons.
Procedure 20.7 Preparing a Remote Access Server for Smart Card Logons
Open the RRAS console.
Open the Properties window for the server.
Select the Security tab.
Select Windows Authentication then click Authentication Methods.
Select the Extensible Authentication Protocol (EAP) option then click EAP Methods.
From the selection list, double-click Smart Card or Other Certificate and click OK.
Uncheck all other authentication options then click OK to return to the Properties window.
Click OK to save the changes, close the window, and return to the main RRAS console.
Navigate down the tree to Remote Access Policies. You can create a new policy for smart card logons or you can modify the existing policy. In this instance, let's modify the existing policy.
Double-click the Allow Access If Dial-In Permission Is Enabled icon to open its Properties window.
Click Edit Profile.
Select the Authentication tab (see Figure 20.23).
Figure 20.23. Edit Dial-In Profile window showing Authentication tab with all options other than EAP deselected.
Click EAP Methods. The Select EAP Providers window opens.
Click Add. The Add EAP window opens.
Select the Smart Card or Other Certificate option and click OK to return to the Select EAP Providers window.
Click Edit. The Smart Card or Other Certificate Properties window opens.
In the Certificate Issued To field, select the Computer certificate issued to the server (see Figure 20.24).
Figure 20.24. Smart Card or Other Certificate Properties window showing the selection of the computer certificate issued to the RRAS server.
Click OK then OK again and OK once more to close all the windows and return to the main RRAS console.
The remote access server is now ready to accept smart card authentication. Now test to make sure it works.
Smart Card Remote Logon Testing
Configure a dial-in client to use smart card authentication. The exact procedure for doing this varies depending on the platform. Figure 20.25 shows the configuration settings for an XP client.
Figure 20.25. XP dial-in connection properties showing smart card settings in the Security tab.
After the client has been configured to use smart card logons, double-click the dial-in connection icon to initiate the connection and insert a smart card into the reader when prompted. (You can also insert the card first to avoid the first prompt.) A pop-up window collects your PIN then the system makes the dial-in connection.
If the CSP refuses to read the card because of an improper PIN, use the vendor prep utility to reset the PIN. The authentication transaction to the remote access server does not involve the PIN in any fashion.
If the system accepts the PIN and reads the card but you get an Access Denied - Unknown User or Password error, verify once again that you can use the card to log on to the domain from the console of a computer that is on the network. If this works, you may have a situation where the remote access server cannot resolve the user's UPN. The server must have access to a domain controller and a Global Catalog server.
At the completion of a successful test, you're ready to begin production deployment. All you need now is time and budget.