July 6, 2011, 5:07 a.m.
posted by vdv
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.
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:
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 shows the default template list in the CA 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.)
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.
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.
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.
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.
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 shows the configuration settings for an XP client.
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.