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.
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
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
- 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.
- Use Control Panel | Add/Remove Programs | Add/Remove
Windows Components. Select Certificate Services, then
- 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.
- Select the Certification Authority Type: enterprise
- On the same screen, select the Advanced Options check
box and click next.
- Select the CSP. (I selected Schlumberger.)
- 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.
- Click Next.
- 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
- 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.
- 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.
- Click Next.
- 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
- 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.
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
- Open the Certification Authority Console.
- Click on Policy Settings in the console tree.
- Click on New in the Action menu.
- Click on Certificate To Issue.
- 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).
- Repeat steps 2 through 4 and this time select “enrollment
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
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:
- Open Active Directory Sites and Services.
- Click Active Directory Sites and Services in the
- Open the View menu and select Show Services Node.
- Click Certificate Templates in the console.
- 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:
- Dedicate a PC to be the enrollment station and provide
it with a card reader.
- As Administrator, give the enrollment group permission
to obtain enrollment certificates. (Use the process
above for smart cards, except select “enrollment” certificates.)
- Log on as the intended enrollment agent.
- 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
To use the local certificate console:
- In the Run window, type “mmc” and press Enter.
- From the Console menu, select Add/Remote Snap-In.
- Click the Add button.
- Select Certificates.
- Click Add.
- Leave the default “My user account” and click Finish.
- Click Close and OK.
- Expand the Certificates folder.
- Right-click the Personal folder and select All Tasks/
Request new certificate.
- Select your CA.
To use the Web enrollment pages:
- 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.
- Click Request a Certificate and Next.
- Click Advanced request and Next.
- Select the certificate template for an enrollment
- Select the CSP for your smart card vendor (in my
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.
- Log on as administrator to the system that already
has IIS 5.0 installed.
- Choose Certificate Services from the Add/Remove Programs
| Add/Remove Windows Components wizard in Control Panel.
- Clear the Certificate Services CA check box. You
don’t want to install another CA.
- Verify the Certificate Services Web Enrollment Support
box is selected.
- Click OK and Next.
- Enter the name of the computer on which the CA is
installed and click next.
- Stop the WWW services when prompted.
- 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:
- 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.
- Open the Web enrollment pages from the enrollment
- Click Request a Certificate and click next.
- Click Advanced request and click next.
- 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
- In the Certificate Template box, select Smart Card
- Click the name of the CA to use to issue the smart
- In the Cryptographic Service Provider box, select
the cryptographic service provider.
- In the Administrator Signing Certificate dropdown
box, select the enrollment user.
- Enter the name of the user account from the dropdown
- Insert a new smart card and click Submit certificate
- Click OK.
- When prompted, enter the PIN for the smart card.
The default PIN for Schlumberger is eight zeros; for
Gemplus it’s 1234.
- To set a unique pin for the user, check the box Change
- When prompted, set the user pin.
- Choose the option to view the certificate when prompted.
- Remove the card and select Create New User.
- Give the smart card and PIN to the user.
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