With last month’s foundation in smart card technology under your belt, it’s time to implement the test system.

Smart Card Education, Part 2

With last month’s foundation in smart card technology under your belt, it’s time to implement the test system.

• By Roberta Bragg
• 10/01/2000

To show you how to implement a simple smart card test lab, I’ve chosen to install a single enterprise root. Although this may not be the best situation from a security point of view, it allows me to show you the entire scope of configuration necessary to get smart cards up and working in a test system. I’ll use this same system as an enrollment station, something you should never do in a production system. If you’re doing more than just attempting to understand smart cards, you’ll want to set up a more complex lab. To set up a lab like mine, follow these steps.

First, Install the Reader

After you’ve obtained a smart card reader and some cards, install the reader. Win2K comes with the cryptographic service providers (CSP) for two smart card vendors, Schlumberger (www.schlumberger.com) and Gemplus (www.gemplus.com). Schlumberger was nice enough to provide me with a free reader and some cards, and so I’m more familiar with that offering. A CSP is software required to work with Win2K. A CSP specific to the vendor’s smart cards is required.

Second, Install the CA

To make installation simpler for the test lab, I installed the reader first. You don’t need to have a smart card reader to install a Certificate Authority (CA)—see my September column for additional details on the CA. I installed an enterprise Root CA. I wanted to show you integration with AD but didn’t want to set up a hierarchy. Your design will probably be slightly different.

To install the CA to be used with smart cards, follow these steps:

1. To install an enterprise Root CA, log on as a member of the Win2K Domain Administrators group. To install the CA, you must have the right to write to the AD. By default, domain administrators do, but this right can be removed. The AD, of course, must be available.
2. Use Control Panel | Add/Remove Programs | Add/Remove Windows Components. Select Certificate Services, then click Next.
3. Note the warning, “After installing Certificate Services, the computer cannot be renamed and the computer cannot join or be removed from a domain. Do you want to continue?” Click Yes. (Remember, before starting the CA installation process, to rename if necessary and establish domain membership or lack thereof, depending on your needs.) Since I’m installing an enterprise CA, I’m doing so on a domain controller.
4. Select the Certification Authority Type: enterprise Root CA.
5. On the same screen, select the Advanced Options check box and click next.
6. Select the CSP. (I selected Schlumberger.)
7. You may decide to select a different hash algorithm or change the key length. In general, the bigger the key, the better. However, you may have compatibility issues (if you integrate with third parties) or import/export issues with some key lengths. For our test system I left the defaults.
8. Click Next.
9. Name the CA. This doesn’t have to be the name of the server—in fact, a different name is a good idea. Granted, this is security through obscurity. (The attacker may easily learn the name of the CA, but if its name is different from the name of its server, it’ll be harder to locate.) The name of the CA can’t be changed after installation.
10. Set the Valid for: time. This determines when the CA certificate expires. You’ll want this to be long enough that you can plan to renew the certificate long before it’s necessary, yet short enough to protect the system. CA certificate life also affects the certificates of subordinate CAs and user and computer certificates. These certificates won’t be valid if the root is invalid. I left the default in place.
11. Specify the storage location. For an enterprise root, the default places the database and log in the \system32\folder. In the real world, you may wish to change this. You do have the option to store the CA certificate to a file; however, for an enterprise CA this is usually stored in the AD. I kept the defaults.
12. Click Next.
13. If prompted to stop the World Wide Web Publishing service, do so. The installation process needs to install enrollment and other pages on the Web server.

Third, Configure for Action

Let’s look at other details you may need to configure before issuing smart cards,

• Adding smart card and enrollment templates to the CA.
• Delegating authority for the CA.
• Setting enrollment permissions on enrollment and smart card logon templates.
• Setting up an enrollment station.
• Adding Web enrollment pages to IIS.

Adding Templates

For enterprise CAs, you need to determine what kind of certificates can be supplied by a given CA and who can receive them. Templates provide the information required for a specific use. When a requestor asks for a certificate of a certain type, his or her success depends on access rights to specific templates. The process requires two steps. First, the templates must be added to the CA, then the right to obtain these types of certificates needs to be configured.

By default, a CA can’t issue every type of certificate. You must configure them with the types appropriate for your network. To select the type of certificates a CA can issue:

1. Open the Certification Authority Console.
2. Click on Policy Settings in the console tree.
3. Click on New in the Action menu.
4. Click on Certificate To Issue.
5. For our test lab, select the smart card logon user certificate. There are two types of smart card certificates: smart card user (email and authentication) and smart card logon (authentication only).
6. Repeat steps 2 through 4 and this time select “enrollment agent.”

Delegation

It may be appropriate on your network to delegate control of the CA. For my test lab, I left Domain Administrators in charge. To set permissions on the CA, use the Certification Authority Console.

Configure Enrollment Permissions

In our scenario, we need to configure enrollment rights for two types of certificates, Smart Card Logon and Enrollment Agent. Enrollment Agent certificates should be limited to a specific individual who will provide enrollment services for all other users. This person will create the smart cards and distribute them to users. Every user who needs to log on will need a smart card logon certificate. For our test CA, we’ll set the permissions on the Smart Card Logon template to Read and Enroll for Authenticated Users; then we’ll create a special “enrollment” group and give them Read and Enroll rights for the enrollment template. To do so:

1. Open Active Directory Sites and Services.
2. Click Active Directory Sites and Services in the console.
3. Open the View menu and select Show Services Node.
4. Click Certificate Templates in the console.
5. Set security permissions for each template by opening the security tab of the templates properties page.

Setting up an Enrollment Station

Users can request their own certificates by using Web pages. However, this can be confusing to many users and may not fit your idea of tight security. A better idea is to establish an enrollment station or stations and designate an individual or group to be an enrollment agent. The enrollment station can be used to enroll or provide smart cards for all employees. Enrollment can be just another part of the orientation process. Renewals can be handled the same way. You must give these accounts enrollment certificates. To set up an enrollment station:

1. Dedicate a PC to be the enrollment station and provide it with a card reader.
2. As Administrator, give the enrollment group permission to obtain enrollment certificates. (Use the process above for smart cards, except select “enrollment” certificates.)
3. Log on as the intended enrollment agent.
4. Request an enrollment certificate.

To obtain an enrollment certificate for an enterprise CA, you have two choices: A user may use his or her local certificates console or the Web enrollment pages. Web enrollment pages are installed by default when you install a CA on a Win2K system also running IIS. For better security, don’t run IIS on your CA; install the Web pages on a different system.

To use the local certificate console:

1. In the Run window, type “mmc” and press Enter.
2. From the Console menu, select Add/Remote Snap-In.
3. Click the Add button.
4. Select Certificates.
5. Click Add.
6. Leave the default “My user account” and click Finish.
7. Click Close and OK.
8. Expand the Certificates folder.
9. Right-click the Personal folder and select All Tasks/ Request new certificate.
10. Select your CA.

To use the Web enrollment pages:

1. Open Internet Explorer and enter the URL http://nameofserver/certsrv, in which name of server is the name of the server on which a CA resides.
2. Click Request a Certificate and Next.
3. Click Advanced request and Next.
4. Select the certificate template for an enrollment agent certificate.
5. Select the CSP for your smart card vendor (in my case, Schlumberger).

Set Up Enrollment Pages on IIS

If you install certificate services on a system that already has IIS 5.0 installed, then enrollment pages are installed by default. This is our situation in this simple test lab. In the real world, you probably don’t want to do that. Deselect the pre-checked option when setting up the CA and use the following procedure to set up the pages on an alternative system. If all smart card enrollments are to take place over the intranet, be sure to secure the IIS server from the outside world.

1. Log on as administrator to the system that already has IIS 5.0 installed.
2. Choose Certificate Services from the Add/Remove Programs | Add/Remove Windows Components wizard in Control Panel.
3. Clear the Certificate Services CA check box. You don’t want to install another CA.
4. Verify the Certificate Services Web Enrollment Support box is selected.
5. Click OK and Next.
6. Enter the name of the computer on which the CA is installed and click next.
7. Stop the WWW services when prompted.
8. Provide the path to the Certificate Services installation files if prompted.

Fourth, Enroll Users

The enrollment agent can now request certificates for smart card users. In order to do so, follow these steps:

1. The enrollment station must have at least one card reader. If you want the enrollment agent to log on using a smart card, then you must have two readers on the enrollment station computers. One will hold the smart card that belongs to the enrollment agent, and the other creates the smart cards for users.
2. Open the Web enrollment pages from the enrollment station.
3. Click Request a Certificate and click next.
4. Click Advanced request and click next.
5. In the Certificate Request box, select Request a certificate for a smart card on behalf of another user using the Smart Card Enrollment Station, and then click next.
6. In the Certificate Template box, select Smart Card Logon.
7. Click the name of the CA to use to issue the smart card.
8. In the Cryptographic Service Provider box, select the cryptographic service provider.
9. In the Administrator Signing Certificate dropdown box, select the enrollment user.
10. Enter the name of the user account from the dropdown list.
11. Insert a new smart card and click Submit certificate request.
12. Click OK.
13. When prompted, enter the PIN for the smart card. The default PIN for Schlumberger is eight zeros; for Gemplus it’s 1234.
14. To set a unique pin for the user, check the box Change pin.
15. When prompted, set the user pin.
16. Choose the option to view the certificate when prompted.
17. Remove the card and select Create New User.
18. Give the smart card and PIN to the user.

What’s Next?

Now that you’ve set up some users and tested the operation, you can perform a couple of other steps to lock down systems: You can require that users use a smart card to log on, and you can require that a particular computer can be used only if a smart card is used.

By default, users are prompted to log on with a card, but they can use the Ctrl-Alt-Del function to obtain a logon screen, then use their user accounts and passwords to log on. To ensure that users use their smart cards, you can check the box within their Account properties | Account options box labeled, “Smart Card is Required for interactive logon.” Be sure to allow at least one administrator account to log on with a password. Some administrative functions require an administrator to enter a password or they won’t work.

To make computers require smart cards, you must set the policy in the Group Policy Object for the Organizational Unit in which the computer account resides. You’ll find the policy item to set in “Security Options”: “Disable CTRL + ALT + DEL.”

Remember, if this ability isn’t there, the user can’t get to a logon screen.

I strongly suggest you institute these requirements; otherwise, you’re allowing users to circumvent your new security.