Business Card Software - Download as DOC by ofm18586

VIEWS: 23 PAGES: 32

More Info
									 C H A P T E R                      1 7


Planning a Smart Card
Deployment

 Smart card support in Microsoft® Windows® Server 2003 enables you to enhance the security of many critical
 functions, including client authentication, interactive logon, and document signing, in your organization. If you
 are using or planning to use public key certificates, deploy smart cards to increase security for your network and
 critical applications.

       In This Chapter
 Overview of Smart Card Deployment ...............................................................................................844
 Creating a Plan for Smart Card Use .................................................................................................846
 Selecting Smart Card Hardware .......................................................................................................852
 Creating a Smart Card Deployment Plan ........................................................................................861
 Planning for Ongoing Smart Card Support ......................................................................................869
 Additional Resources .........................................................................................................................874
       Related Information
                      For more information about creating a public key infrastructure, see “Designing a Public Key
                       Infrastructure” in this book.
                      For more information about Windows Server 2003 Certificate Services and public key
                       infrastructure features, see the Distributed Services Guide of the Microsoft® Windows®
                       Server 2003 Resource Kit (or see the Distributed Services Guide on the Web at
                       http://www.microsoft.com/reskit).
844 Chapter 17 Planning a Smart Card Deployment




Overview of Smart Card
Deployment
Most organizations use passwords to manage access to computer networks and resources. However, some users
set weak passwords, write passwords down in insecure locations, or forget their passwords and require help
desk assistance for password reset. For this reason, passwords alone might not provide the level of security and
manageability that your organization requires.
Smart card support in Microsoft® Windows® Server 2003, Standard Edition; Windows® Server 2003, Enterprise
Edition; and Windows® Server 2003, Datacenter Edition operating systems provides users with stronger
credentials than even the most complex passwords. If you use, manage, and deploy smart cards properly, you
can enhance the security of your organization and reduce your support costs.
Smart cards offer the following benefits:
               Protection. Smart cards provide tamper-resistant storage for private keys and other data. If a
                smart card is lost or stolen, it is difficult for anyone except the intended user to use the
                credentials that it stores.
               Isolation. Cryptographic operations are performed on the smart card itself rather than on the
                client or on a network server. This isolates security-sensitive data and processes from other
                parts of the system.
               Portability. Credentials and other private information stored on smart cards can easily be
                transported between computers at work, home, or other remote locations.
The number and variety of smart card–enabled applications is growing to meet the needs of organizations that
want to rely on smart cards to enable secure authentication and to facilitate services.
Before you can deploy smart cards in your organization, you must have a public key infrastructure (PKI) in
place. Next, you need to identify applications to enable for use with smart cards, and plan how to implement and
support a smart card infrastructure before you can take advantage of the security benefits of smart cards.

                   Note
                   For a list of the job aids that are available to assist you in deploying
                   smart cards, see “Additional Resources” later in this chapter.
                                                                                  Overview of Smart Card Deployment 845




Process for Planning a Smart Card
Deployment
Planning a smart card deployment involves making decisions about technical standards, hardware purchases,
smart card management, and the logistics of smart card distribution.
Figure 16.1 shows the process for planning a smart card deployment.
Figure 16.1 Planning a Smart Card Deployment




Smart Card Fundamentals
Windows Server 2003 supports a variety of secure smart card applications and business scenarios. Before you
begin to plan your smart card deployment, it is important to understand the basic components of smart card
technology.
    Components of a Smart Card Infrastructure
A number of hardware and software components are required in order to support a smart card infrastructure.
               Certificates Digital data that securely bind a public key to the entity that holds the corresponding
private key.
               Certification authorities Trusted entities or services that issue digital certificates.
846 Chapter 17 Planning a Smart Card Deployment



              Active Directory The Windows Server 2003 directory service that serves as a repository for
account information, primarily user credentials, security group memberships, and certificate templates. In
addition, you can also use the Active Directory® directory service to store certificates, certificate revocation
lists, and delta certificate revocation lists, and to publish root certification authorities (CAs) and cross-
certificates.
            Smart cards Hardware tokens containing integrated processors and memory chips that can be
used to store certificates and private keys and to perform public key cryptography operations, such as
authentication, digital signing, and key exchange.
            Smart card readers Devices that connect a smart card to a computer. Smart card readers can
also be used to write certificates to the smart card.
           Smart card software The software provided by the smart card vendor to manage smart cards.
In some cases, organizations might choose to create their own software tools if customized functionality is
required.



Creating a Plan for Smart Card
Use
Before deploying smart cards in your organization, you must determine which processes, users, and groups of
users require smart cards.
Figure 16.2 shows the process for creating a plan for smart card use in your organization.
Figure 16.2 Creating a Plan for Smart Card Use
                                                                                Creating a Plan for Smart Card Use 847




Identifying the Processes That Require
Smart Cards
A smart card deployment can help your organization meet numerous sensitive business requirements. You can
use smart cards for any or all of the following processes:
               Interactive user logons, including remote access connections to the network
               Administrator logons
               Third-party authentication across the Internet
               Signing and encrypting e-mail
Evaluate additional equipment and administrative costs, procedures, and changes to user work patterns that each
smart card–enabled process requires. Ensure that the benefits of deploying smart cards for each process
outweigh the costs from hardware, administration, and potential user difficulties.
For a worksheet to assist you in documenting the processes in your organization that require smart cards, see
“User and Group Smart Card Requirements” (DSSSMC_1.doc) on the Microsoft ® Windows® Server 2003
Deployment Kit companion CD (or see “User and Group Smart Card Requirements” on the Web at
http://www.microsoft.com/reskit).


Interactive User Logons
Use smart cards for an interactive user logons if you want to enforce the use of secure encrypted logon
credentials. If you require users to log on by using smart cards, you do not have to worry about the quality and
security of user passwords.
Requiring smart cards for interactive user logons requires additional network administration for smart card
distribution and support. This is problematic for organizations that are spread across different geographic
locations and that do not have network or physical security personnel in each location to administer and support
smart cards.
You can also use smart cards for remote access logons, and for Terminal Services and shared client logons.
    Remote Access Logons
Local interactive logons require that users have both physical access to a computer that is a logical member of
the organization and a network password. Remote users, however, can log on from any computer outside of the
organization. If a malicious user obtains the password of a remote user, he or she can use it to access network
resources from any computer. For this reason, conventional password-based remote access logons are more
vulnerable to attack than local interactive logons.
848 Chapter 17 Planning a Smart Card Deployment




You can secure the remote access process by requiring users to use smart cards when they connect to the
corporate network by means of remote access logon. This solution prevents hackers from using the remote
access dial-up or Internet connections to compromise the network, even if they have physical access to laptops
or home computers.
One problem with requiring the use of smart cards for remote access logons is the fact that remote users often
own computer hardware and software that does not conform to minimum corporate standards and, therefore,
might not support smart card use. This complicates the process of administering and supporting smart cards for
remote access logons. Also, users might experience longer logon times when they use smart cards, especially
over slow dial-up connections.
    Terminal Services and Shared Clients
If your organization is deploying Terminal Services, consider using smart cards for kiosk computers that are
shared by multiple users. This can improve security in environments in which multiple users share a single
computer terminal, relocate frequently, and do not use the conventional logoff procedure every time they move
away from the terminal. This is often the case in hospitals, factories, or other businesses.

                   Note
                   Smart card logons require Microsoft® Windows® XP or Windows
                   Server 2003 Terminal Services clients, even on computers running
                   Microsoft® Windows® 2000.

Providing smart card support for kiosks or Terminal Services clients that are in critical locations in your
organization and are shared by several users is less costly than providing smart card support for interactive user
logons, because you do not need to purchase and deploy a large number of smart card readers.
For more information about deploying Windows Server 2003 Terminal Services, see “Hosting Applications
with Terminal Server” in Planning Server Deployments in this kit.


Administrator Logons
There is greater potential for harm to the network when administrator credentials, as opposed to user credentials,
are misused. As a result, preventing unauthorized users from using administrative credentials to access their
network is an important security priority for most organizations. Another vulnerability is introduced when you
allow people to perform network administration tasks by using generic administrator accounts that are shared by
multiple users; this limits the ability of the organization to track which user performs a specific action. Allowing
administrators to log on by using administrative credentials when they are not performing administrative tasks
also creates a significant security risk because attackers who compromise an administrator account can do a
greater amount of damage to the system.
                                                                                     Creating a Plan for Smart Card Use 849




By requiring individuals to use smart cards to perform administrative tasks, you can significantly reduce the
possibility that unauthorized users can gain administrative access to your network. You can use smart cards for
administrator logons in the following two ways:
               By using smart cards for individual administrative operations.
               By using smart cards for an administrative shell.
In most cases, the best solution is to use a combination of these two strategies. For example, you can require that
all administrators use smart cards to access data center servers. If the administrator is using a Windows 2000 or
Windows XP client, he or she can use a smart card and administrative credentials to open a Terminal Services
client session in order to log on to the data center servers.

                   Important
                   It is not possible to utilize multiple credentials stored on a single smart
                   card. Therefore, administrators who have more than one domain account
                   require a smart card for each account.


    Using Smart Cards for Individual Administrative Operations
When you use smart cards for individual administrative operations, administrators log on by using their standard
user credentials, and then use administrative credentials when they need to perform specific administrative
operations. For example, you might require an administrator to log on by using a smart card in order to install
Active Directory on a member server. Administrative credentials apply only to the specific operation, which
helps to protect the security of the system.
An administrator can also use smart cards to perform individual administrative operations on target computers
running versions of the Windows operating system earlier than Windows XP or Windows Server 2003, as long
as they use a smart card to log on to a computer running Windows XP or Windows Server 2003.
Not all administrative tools work with smart cards. Therefore, before you implement this solution, test it to
ensure that you can perform the required administrative tasks and use the necessary administrative tools. If some
of your required tools and tasks are incompatible with using smart cards, you must communicate to your
administrators which tasks require smart cards and which must be completed by using administrative
credentials.
    Using Smart Cards for an Administrative Shell
When you use smart cards for an administrative shell, administrators log on by using user credentials. Then,
when the administrator needs to perform administrative operations, he or she logs on by using a smart card and
administrative credentials to open a Terminal Services client session. The administrator then performs the
required administrative operations within the administrative shell.
850 Chapter 17 Planning a Smart Card Deployment




This approach simplifies the process of performing multiple sequential administrative operations during a single
session. However, the server that has Terminal Server enabled must be running Windows Server 2003.
Although the Windows XP Terminal Services client can run on Windows 2000, the server-side support is only
provided by Windows Server 2003.


Authenticating Third Parties
Use smart cards for third-party authentication if you want to verify that queries, orders, or other communications
originate from the appropriate individual or organization and that they conform to preestablished standards, such
as purchase order limits. For example, banks that allow users to check their transaction histories or pay bills
online, and distributors that accept purchase orders over the Internet can benefit from using smart cards for
third-party authentication.
Deploying smart cards to third parties, however, requires careful administration. For example, you must ensure
that attackers cannot obtain smart cards and guess the PIN to gain unauthorized access to the system. Also, if the
customer services that are based on smart card authentication are an important part of your business, you need to
ensure that the services are always available. If you do not administer your third-party smart card authentication
process effectively, it can have a negative impact on your Internet business transactions.


Signing and Encrypting E-mail
You can use smart cards to enable digital signing and the encryption of electronic communications such as e-
mails or contracts.
If you choose to deploy smart cards for digital signing, you need to determine the types of e-mail messages that
require smart card–validated digital signatures. Use smart cards for the digital signing of e-mail messages where
it is important to verify the identity of the sender and that the message has not been tampered with while in
transit. Digitally signing routine e-mails creates unnecessary network traffic and can slow down ordinary
communication between users. Note that when you use smart cards for the digital signing of sensitive
documents, such as legal contracts or purchase orders, you must configure the certificate policies and extensions
that control smart card certificate use.
Depending on the types of documents that you want users to sign digitally, you also need to make additional
decisions about smart card–enabled digital signatures, such as whether assistants are allowed to sign documents
on behalf of their superiors, whether send and read receipts are required, and how the receipts are to be stored.
For more information about certificates and certificate use, see “Designing a Public Key Infrastructure” in this
book.

                   Note
                   You must ensure that users know how to verify digital signatures. Unlike
                   a hand-written signature, a digital signature is not embedded in a
                   message or document, and might be overlooked.
                                                                                  Creating a Plan for Smart Card Use 851




Defining Smart Card Service Level
Requirements
Before you deploy smart cards, establish service level agreements to help your IT organization align smart card
performance with the objectives of the organization in areas such as reliability, response times, and support
procedures.
For example, you need to define smart card service level standards for:
               The types of identification required to obtain a smart card. You might choose to require a
                specific type of personal identification, such as a driver’s license or other photo ID, in order for
                a user to obtain a smart card.
               Unique service guarantees for special classes of employees, such as executives or roaming
                employees. Define whether certain classes of employees are permitted to operate under support
                agreements that differ from those of other users.
               Acceptable time needed for users to log on. It is best to ensure that the different steps and
                time needed for smart card logon time are comparable to the steps and time needed for
                conventional password logons.
               Acceptable logon times for remote access users. Remote access logon times are more
                vulnerable to slowdowns than local network connections, especially if users have slow dial-up
                access connections. You might need to upgrade your remote access configuration in order
                ensure acceptable logon times for remote users.
               Remote access exceptions. The computer configurations of some users might not be
                compatible with smart cards, and remote users might lose or forget their smart cards. Identify
                the circumstances, if any, in which remote users are allowed to use remote access without using
                a smart card.
               Number of unsuccessful PIN entries allowed. Do not allow an unlimited number of attempts
                to enter a PIN. Allowing three or four attempts is generally adequate.
               PIN reset requirements. Decide whether users are allowed to reset their own PINs, or whether
                they need to provide personal identification to security or help desk personnel to have their
                PINs reset. If you decide that users need to provide positive identification, decide whether the
                user must present the identification in person, such as a photo ID, or demonstrate knowledge of
                a predefined secret, such as a mother’s maiden name.
               Service guarantees to users who cannot use their smart cards because of loss, damage, or
                blocking. This includes:
                    Establishing when and how users can regain access to the network.
                    Determining whether to restrict these users’ access to the network to certain areas, or to
                     allow them access to any areas of the network that were previously accessible to them.
Defining these limits helps you to establish user expectations and support procedures.
Document your service level standards. You will need to apply these standards in your smart card operations
plan, test them in your lab and pilot deployments, communicate them to help desk personnel and to your users,
and include them in your support and maintenance plan.
852 Chapter 17 Planning a Smart Card Deployment




For a worksheet to assist you in documenting your service level agreement, see “Smart Card Service Level
Agreement” (DSSSMC_2 .doc) on the Windows Server 2003 Deployment Kit companion CD (or see “Smart
Card Service Level Agreement” on the Web at http://www.microsoft.com/reskit).

                   Important
                   Incorporate your smart card service level agreements in the Certificate
                   Practice and Policy Statements for your public key infrastructure. For
                   more information about creating Certificate Practice and Policy
                   Statements, see “Designing a Public Key Infrastructure” in this book.




Selecting Smart Card Hardware
Single smart cards and smart card readers are relatively inexpensive. However, when you deploy smart cards
and smart card readers to hundreds or even thousands of users, equipment cost becomes an important
consideration. You must evaluate smart card hardware in order to select the devices that best meet the needs of
your organization at the best price.
Figure 16.3 shows the process for selecting smart card hardware.
Figure 16.3 Selecting Smart Card Hardware
                                                                                     Selecting Smart Card Hardware 853




Creating a Smart Card Specification
A wide variety of smart cards and smart card readers are available to choose from. Windows Server 2003
is designed to work with any cryptographic smart card that has an associated CryptoAPI cryptographic
service provider. The physical characteristics of smart cards and readers are governed by published
standards. Cards from any manufacturer that adheres to the ISO 7816 standard will likely be compatible
with the reader you select. Be sure, however, to test smart cards and smart card readers to verify
compatibility before deploying them in your production environment.
For more information about testing smart cards and smart card readers, see “Evaluating Smart Cards and
Readers” later in this chapter.

                   Note
                   For more information about ISO 7816, see the Smart Card Alliance link
                   on the Web Resources page at
                   http://www.microsoft.com/windows/reskits/webresources.

Because smart cards both store and process data, it is important to create a specification for your smart cards.
Creating a smart card specification involves making decisions about the following:
               Smart card hardware type
               Amount of memory required
               Intended useful smart card lifetime
               Intended smart card roles
               Smart card reader hardware
               Smart card management software
Table 16.1 lists some of the critical specifications that you need to define when you create your smart card
specification.
Table 16.1 Smart Card Hardware Specifications
                   Specification                                   Description
             Memory                       How much data you need to store on the smart card.
             Life expectancy              The useful lifetime of the smart card.
             Reuse                        Whether or not the smart card can be configured for
                                          use by a second user, if the original user leaves the
                                          organization.

                                                                                     (continued)
854 Chapter 17 Planning a Smart Card Deployment




Table 16.1 Smart Card Hardware Specifications (continued)
                   Specification                                   Description
             Type of card                 The type of card that is most appropriate for your
                                          organization. You might choose one or more of the
                                          following:
                                             Credit card or token style
                                             Single purpose or dual purpose
             Card dimensions              The size, length, and thickness of the card, depending
                                          on the type of card that you specify.
             Number of cards              How many cards you need.
                                           If you have more users than computers, you need
                                            fewer readers than smart cards.
                                           If you use your smart cards on multiple systems, you
                                            need more readers than smart cards.
                                             If you specify more than one type of card, indicate the
                                              number of each type.
             Type of smart card           The type of reader that is most appropriate for your
             reader                       organization. Options include:
                                             USB
                                             PCMCIA
                                             Serial
             Number of smart card         How many readers you need.
             readers                       If you have more users than computers, you need
                                            fewer readers than smart cards.
                                           If you use your smart cards on multiple systems, you
                                            need more readers than smart cards.
                                             If administrators use one smart card for user logons
                                              and a second smart card for logging on with their
                                              administrative credentials, this will also impact the
                                              number of smart card readers that you require.
             Performance                  The type of performance that you can expect. This
             requirements                 includes:
                                           Minimum acceptable logon times for direct network
                                              logons.
                                             Minimum acceptable logon times for remote access
                                              logons.
                                             Ability to handle alternate credentials.
                                             Ability to restrict logons by using alternate credentials.
             Smart card                   The types and quality of the tools provided by the
             management tools             hardware vendor to manage smart cards.
                                                                                         Selecting Smart Card Hardware 855




For a worksheet to assist you in preparing a product specification, see “Smart Card Hardware Specification”
(DSSSMC_3 .doc) on the Windows Server 2003 Deployment Kit companion CD (or see “Smart Card Hardware
Specification” on the Web at http://www.microsoft.com/reskit).
In the beginning of your deployment, you can meet user needs by using a single type of smart card with a single
configuration option. However, as you expand your smart card infrastructure, you might need to deploy a
variety of smart card types and configuration options.
    Smart Card Type
Two types of smart cards are available for use with Windows Server 2003 and Windows XP: conventional
credit card–shaped contact cards and smaller token-style cards that plug directly into the USB port of a
computer.

                   Note
                   Another type of smart card, called a contactless smart card, is not
                   supported by Windows XP or Windows Server 2003.

            Credit card–shaped contact cards
Credit card–shaped smart cards are available in three-volt and five-volt versions. They are the most common
smart card solution, in part because they resemble the corporate card keys or badges that many organizations
use.

                   Note
                   You can specify that your smart cards be screen-printed with your
                   corporate logo and a picture of the user. If you plan to add graphics to
                   smart cards, ask your vendor about the methods available for bulk
                   printing and customizing cards.

If your organization uses card keys or badges, you can apply smart card chips to the existing card key or badge
as a sticker or “skin.” However, your card keys or badges need to fit into your smart card readers with a minimal
amount of friction; therefore, be sure to include the physical thickness of the smart card in your specifications.
This is an important factor to consider when you select a vendor to manufacture the stickers, as the material
thickness for smart card chips can vary.
            Token-style smart cards
Token-style smart cards are typically the size of a house key or automobile key. They plug directly into a USB
port, providing a more compact solution than separate cards and readers. Token-style smart cards are ideal for
laptop users who want to carry a minimum number of peripherals, or for workers who use a number of different
computers. However, you cannot use token-style smart cards if your computers do not have USB connections,
or if the USB connections are full or difficult to access.
856 Chapter 17 Planning a Smart Card Deployment




    Memory
Your smart card requires enough memory to store the certificate of the user, the smart card operating system,
and additional applications. Smart cards run embedded operating systems, and in many cases, a form of file
system in which data can be stored. To enable Windows smart card logon, you must be able to program the card
to store a user’s key pair, retrieve and store an associated public key certificate, and perform public and private
key operations on behalf of the user.
To calculate the amount of memory that you need, determine the space requirements for:
               User certificates. A certificate typically requires about 1.5 kilobytes (KB). A smart card logon
                certificate with a 1,024-bit key typically requires 2.5 KB of space.
               The smart card operating system. The Windows for Smart Cards operating system requires
                about 15 KB.
               Applications required by the smart card vendor. A small application requires between 2 KB and
                5 KB.
               Your custom applications.
               Future applications.
Figure 16.4 shows the additional space requirements of a typical 32 KB smart card. The smart card operating
system requires about 15 KB, leaving 17 KB for the file system, which includes space for the card management
software, the certificate, and any other custom applications.
Figure 16.4 Memory Use on a 32 KB Smart Card
                                                                                      Selecting Smart Card Hardware 857




It is possible to configure smart card file systems into public and private spaces. For example, you can define
segregated areas for protected information, such as certificates, e-purses, and entire operating systems, and mark
this data as Read Only to ensure the security of the smart card and restrict the amount of data that can be
modified. In addition, some vendors provide cards with sub-states, such as Add Only, which is useful for
organizations that want to restrict the ability of a user to revise an existing credential, and Update Only, which is
useful for organizations that want to restrict ability of a user to add new credentials to a card.
The data capacity available on smart cards is increasing as smart card technology improves. However, storage
space on smart cards is expensive. Card vendors often restrict the amount of storage available to individual
applications so that multiple applications or services can be stored on the card. Therefore, in your vendor
specification, define all of your anticipated present and future card usage requirements and the memory
requirements for each certificate and application that you require. If you plan to use your smart cards for
multiple purposes, such as physical access to facilities and user logon, or to store additional data, you must
increase your memory requirements. Also, when planning storage space on the chip, allocate space for
applications that you are planning for future implementation.

                   Note
                   Windows Server 2003 and Windows XP do not support the use of
                   multiple certificates on a smart card.


    Life Expectancy
You must define the length of time for which you will use a smart card before you replace or upgrade it. Contact
your vendor for information about smart card life expectancy based on normal wear and tear.
In addition, you must take into account your current and future space requirements, including the anticipated
need for additional applications and certificates with larger keys. Anticipate adding new applications, and
potentially issuing new smart cards, over an 18-24 month card lifecycle. In the future, vendors are likely to
introduce smart cards with more memory and other enhancements for a lower cost.
Also, determine whether you want your smart cards to be reusable in the event that users leave the organization.
Reusing smart cards reduces the costs associated with issuing new ones. However, the cost associated with
removing existing data and writing new data and applications is often equal to or more than the cost of
preparing and issuing new smart cards.
858 Chapter 17 Planning a Smart Card Deployment




    Smart Card Roles
You can use smart cards for one of three roles. Determine how many smart cards you need to issue for each of
the following roles:
               Enrollment card. Issue enrollment cards to individuals who enroll smart cards on behalf of
                other users. Enrollment cards have a special enrollment agent certificate. Issue the smallest
                possible number of enrollment cards that will enable you to enroll all required smart card users.
                This protects the security of your system.
               User cards. These are the standard cards that you issue to each user. Two types of user cards
                are available:
                     Permanent. Permanent user cards are cards that employees carry with them. They contain
                      the cardholders’ credentials, certificates, data, and applications. They might also have a
                      photograph or a decal applied to the card. In a Windows Server 2003 environment, the
                      permanent card points to a permanent certificate server.
                     Temporary. Temporary cards are a limited-use cards that are issued to guests, temporary
                      employees, and users who have forgotten their permanent cards. They point to a temporary
                      certificate server and can have a limited lifetime.
For a worksheet to assist you in documenting the roles for the smart cards that you issue, see “Smart Card
Hardware Specification” (DSSSMC_3 .doc) on the Windows Server 2003 Deployment Kit companion CD (or
see “Smart Card Hardware Specification” on the Web at http://www.microsoft.com/reskit).

                    Important
                    To ensure system security, issue master and enrollment cards to the
                    smallest possible number of trusted employees. For more information
                    about issuing enrollment agent cards, see “Establishing Enrollment
                    Agents” later in this chapter.


    Smart Card Readers
A variety of types of smart card readers are available. The majority of smart card readers connect to the
computer through an RS-232 serial port, a Type II Personal Computer Memory Card International Association
(PCMCIA) slot, or a universal serial bus (USB) port.
Although USB-compatible smart readers are the simplest type of reader to connect, the USB ports on some
computers might be occupied. For this reason, it is best to order a mix of card reader connector types based on
the types of connections that are available on your systems.
For a list of Windows-compatible smart card readers, see the Windows Catalog link on the Web Resources page
at http://www.microsoft.com/windows/reskits/webresources.
                                                                                   Selecting Smart Card Hardware 859




    Smart Card Management Tools
You can perform most smart card–related tasks by using the Windows Server 2003 Certificate Services and
software tools provided by the smart card vendor. However, it is important to assess the smart card tools that are
available to determine whether they are sufficient to meet your needs. You might need to create additional tools
for some smart card tasks.
For example, you might require tools to assist you in moving from a limited pilot phase to a full production
deployment. Also, developers in your organization might need to create a direct interface between the smart
card certificate and your building access systems. You might also choose to write a script that automatically
enters critical data into a database when a smart card is created. This includes data such as smart card serial
numbers, the names or e-mail names of the users who are assigned smart cards, the types of certificates that are
issued to the users, when the certificates are issued, and when they expire.
For more information about creating scripts for Windows Server 2003, see the Windows Deployment and
Resource Kits Web site at http://www.microsoft.com/reskit, or see the TechNet Script Center link on the Web
Resources page at http://www.microsoft.com/windows/reskits/webresources.


Evaluating Smart Cards and Readers
You need to evaluate your prospective smart cards and readers throughout your smart card deployment process.
Initially, obtain and evaluate a variety of smart cards and smart card readers to determine which vendors provide
the best balance of specifications, performance, and price. As you deploy your smart card infrastructure,
continue to evaluate your hardware to make sure that it performs as expected.
The smart cards and smart card readers that you deploy and the smart card production processes that you
develop are likely be used many times every day. Therefore, you must ensure that your hardware is reliable. The
service level agreements that you created when you defined your smart card requirements provide objective
standards for measuring and documenting satisfactory performance.
To minimize user dissatisfaction and maximize manageability, be sure to test the following:
               Installation and removal of the smart card software. Make sure the smart cards work after
                you install the software. If the installation is faulty, use the Windows Event Viewer to access
                error messages that might explain the cause of the failure.
               Fit of smart cards in readers. Smart card dimensions, such as thickness, are governed by
                international standards. However, some organizations have found that, if the card-to-reader
                interface is too tight or abrasive, the cards deteriorate more rapidly.
860 Chapter 17 Planning a Smart Card Deployment




               Reader reliability. To test reliability, create an environment that includes systems that have
                slower CPUs and less memory than computers in your organization. Test how well your smart
                card readers operate in this environment, as well as in other configurations. You can, for
                example, run a number of memory-intensive applications or use the smart cards and readers
                over slow connections to evaluate how each combination of smart cards and readers functions
                in these conditions. Your smart card service level agreements provide objective criteria for
                acceptable and unacceptable performance.
               Card production. Slow card production processes can impede your deployment. If your
                organization is unable to produce cards efficiently, use a third-party vendor to produce smart
                cards.
               Ability to deploy multiple types of cards and readers. If you are unable to efficiently deploy
                the types of cards, readers, and servers that you require, your service might be inconsistent and
                inefficient.
For a worksheet to assist you in documenting the results of your smart card reader evaluation, see “Smart Card
Reader Evaluation” (DSSSMC_4 .doc) on the Windows Server 2003 Deployment Kit companion CD (or see
“Smart Card Reader Evaluation” on the Web at http://www.microsoft.com/reskit).
Figure 16.5 shows an example of a completed Smart Card Reader Evaluation worksheet.
Figure 16.5 Example of a Smart Card Reader Evaluation Worksheet
                                                                            Creating a Smart Card Deployment Plan 861




Creating a Smart Card Deployment
Plan
Deploying a smart card infrastructure is a time-consuming process because it involves deploying physical
components (smart cards and smart card readers) and issuing digital certificates individually to every user who
requires a smart card. Careful planning can significantly reduce the amount of time this process takes and enable
you to enhance the security of your organization. Figure 16.6 shows the steps involved in creating a smart card
deployment plan.
Figure 16.6 Creating a Smart Card Deployment Plan
862 Chapter 17 Planning a Smart Card Deployment




Establishing Certification Authorities
It is important to ensure that your public key infrastructure can support the issuance and verification of smart
card certificates for the users and applications that you have identified. To ensure that your PKI can support a
smart card infrastructure, you must do the following
               Configure your certification authorities (CAs) as enterprise CAs. Windows Server 2003 smart
                card certificates require enterprise CAs.

                          Important
                          CAs that issue smart card certificates need to be trusted in the CA
                          hierarchy and must be continuously online while the user is enrolled.

               Make sure that your issuing CAs are installed on servers that have enough storage and central
                processing power to support the smart card users in your organization.
For more information about planning your CA infrastructure, see “Designing a Public Key Infrastructure” in this
book.


Planning Smart Card Certificate Templates
You can use any of the following types of Windows Server 2003 certificate templates to enable smart card use
in the Windows Server 2003 PKI:
               Enrollment Agent. Allows an authorized user to serve as a certificate request agent on behalf
                of other users.
               Smart Card User. Enables a user to log on and sign e-mail.
               SmartCardLogon. Enables a user to log on by using a smart card.
You can also create your own certificate templates to serve multiple purposes. For example, the smart card
logon certificate template is designed for smart card logon only. If you intend to use your smart card
infrastructure to support multiple applications, you can choose multipurpose templates instead. Multipurpose
templates generate certificates that you can use for multiple applications, such as smart card logon and e-mail
signing.

                   Note
                   Windows 2000 only supports version 1 templates, which cannot be
                   customized or extended. Use Windows Server 2003, Enterprise Edition,
                   which supports version 2 templates, if you need to create new certificate
                   templates, copy an existing template, or replace templates that are
                   already in use.
                                                                                 Creating a Smart Card Deployment Plan 863




As part of your planning for smart card certificate templates, you need to establish values for public keys,
certificate lifetimes, and certificate renewal policies. These values are interrelated. For example, if you select a
larger key value, you can implement a longer certificate lifetime. Or, you can use a small public key value if a
certificate has a relatively short lifetime. Note, however, that the amount of memory that is available on the
smart cards that you select also limits the size of the public keys that you can use.

                   Important
                   Many organizations pre-enroll users for smart card certificates several
                   weeks before they distribute smart cards to users. The certificate lifetime
                   is determined by the date that you issue the certificate, not the date that
                   you distribute the card to the user. Therefore, factor any distribution
                   delays into your certificate lifetime and renewal strategy.

A Windows Server 2003 CA allows you to select a certificate public key length from 384 bits for minimal
security to 16,384 bits for maximum security. For typical logon applications, a 1,024-bit key is adequate.
You can establish certificate lifetimes that are as long or as short as you need, and you can configure certificates
to be nonrenewable, renewable a finite number of times, or renewable indefinitely.
To define public key values and certificate lifetimes and renewal policies, take into account:
                The physical capacity of your smart cards. Most of the smart cards that are available today
                 have adequate space for all but the largest certificates.
                How you define acceptable logon times. Public key–based authentication often takes longer
                 than authentication without certificates.

                          Note
                          The smart card and smart card reader that you choose might also impact
                          logon performance. Test different combinations until the terms specified
                          in your service level agreements are satisfied.

                The nature of the business relationship. Smart card certificates issued to permanent
                 employees usually warrant a longer lifetime and renewal cycle than certificates issued to short-
                 term workers or to nonemployees.
                The level of security that you want to enforce. Highly sensitive operations warrant larger
                 public key values and, typically, shorter certificate lifetimes.
For more information about planning public key and certificate renewal values, see “Designing a Public Key
Infrastructure” in this book. For more information about how to configure certificate templates, see “Certificate
Templates” in Help and Support Center for Windows Server 2003.
864 Chapter 17 Planning a Smart Card Deployment




Establishing Issuance Processes
You must establish a plan for the issuance of the smart cards and for the writing of smart card certificates to the
cards. This involves making decisions about the following:
               Smart card distribution requirements
               Certificate enrollment options
               Physical distribution of smart cards
               A user preparation plan


Defining Smart Card Distribution Requirements
Define the procedures for preparing and distributing smart cards and smart card certificates and replacing lost,
stolen, or damaged smart cards, as well as contingencies such as when employees change jobs, names, or
occupational status.
If you have an existing employee badge process, one solution for smart card distribution is to combine smart
card preparation and distribution with badge preparation and distribution. Obtaining a badge typically requires a
visit to a security office where the employees must prove their identity and then have their pictures taken. With
smart cards, employees can have company-issued certificates attached to the badges that they use for building
entry. In this case, the security office requests and installs the certificates on employees’ badges, which also
serve as their smart cards.
Requiring a person to appear in person and with physical credentials such as a driver’s license is the most secure
way to distribute smart cards, but this is not always possible. If your organization includes remote offices or
traveling users, you need to establish a distribution strategy that accommodates the users’ circumstances while
minimizing the security risk. For example, you can have a receptionist or administrative assistant give the user a
blank smart card and then have the user download the smart card certificate by using self-enrollment. The
administrative assistant has physical access to the cards, but not to the PINs or the certificates necessary to
activate the card.
You can also use registered mail or another delivery service that requires a signature upon receipt to distribute
smart cards to individuals who do not have access to a security office. Otherwise, you can choose a designated
individual to physically distribute smart cards. This is the least secure method of smart card distribution.
You must also plan for the physical distribution of replacement cards, especially for mobile or remote office
users.
For more information about replacement card planning, see “Planning for Ongoing Smart Card Support” later in
this chapter.
                                                                             Creating a Smart Card Deployment Plan 865




Selecting Certificate Enrollment Options
By default, only domain administrators can modify smart card certificate templates. Domain administrators can
modify the access permissions on the certificate template to enable either of the following enrollment options:
               Enrollment agents, which allows one or more agents to initialize smart cards on behalf of users.
               Self-enrollment, which allows end users to initialize their own smart cards.
You need to select between the enrollment agent or self-enrollment options, based on the security requirements
of your organization and your plan for smart card management and distribution. Using an enrollment agent
provides the greatest level of security, but requires the highest level of IT support and is the most expensive.
Self-enrollment provides the greatest amount of flexibility, and accommodates remote users, but is not as
secure.
    Establishing Enrollment Agents
If you decide to control smart card issuance from a central location, you need to authorize one or more
individuals within the organization to be enrollment agents.
The enrollment agent needs to be issued an Enrollment Agent certificate, which makes it possible for the agent
to enroll for certificates on behalf of users.
The advantages of using an enrollment agent include:
               A highly trusted individual processes all certificate and smart card requests.
               Domain administrators can delegate a potentially time-consuming task.
               It simplifies the smart card setup process for users.
The disadvantages include:
               It is difficult to ensure that enrollment agents are trustworthy. One way to enhance this trust is
                to require approval from several enrollment agents.
               Users in remote locations might not be able to obtain new or replacement smart cards when and
                where they need them.
Enrollment agents are typically members of the security, IT security, or help desk teams because these
individuals have already been trusted with safeguarding valuable resources. In some organizations, such as
banks that have many branches, help desk and security workers might not be conveniently located to perform
this task. In this case you might need to designate a branch manager or other trusted employee to act as an
enrollment agent.
The number of enrollment agents you need depends on:
               The number and proximity of locations in your organization, especially if enrollment agents
                will be authenticating users in person.
               The number of smart cards that need to be prepared by the enrollment agent.
               The number of other duties that enrollment agents need to perform.
866 Chapter 17 Planning a Smart Card Deployment




Select the individuals to whom you issue Enrollment Agent certificates carefully. These individuals can enroll
for smart card certificates on behalf of any domain user, including an administrator. If these individuals are not
trustworthy, they can compromise the security of your organization. To ensure the security of your organization,
allow only a limited number of your most trusted employees to serve as enrollment agents.
If you decide to use enrollment agents, prevent unauthorized users from becoming enrollment agents by placing
strict controls on the CA used to issue Enrollment Agent certificates. Establish a subordinate CA that is only
used to issue Enrollment Agent certificates. After you issue the initial Enrollment Agent certificates, you can
either disable certificate issuance or take the CA offline until you require additional enrollment certificates.

                   Note
                   For information about delegating enrollment agent authority to individuals
                   who are not domain administrators, see “Prepare a smart card certificate
                   enrollment station” in Help and Support Center for Windows
                   Server 2003.

    Pre-Enrolling User Smart Cards
If you decide to pre-enroll users for smart card certificates, make sure that the enrollment agent has the blank
smart cards as well as the following information:
               The CA selected to issue the smart card certificates to the user, if there are multiple CAs in the
                organization. If there is only one CA in the organization with smart card certificate templates
                enabled, that CA is automatically selected.
               The cryptographic service provider that matches the brand of smart card that is to be issued to
                the user.
               The name of the user to be enrolled. This user must have Enroll permissions for the Smart Card
                certificate template. A domain administrator can set this either for the individual or for a group
                of users, such as Authenticated Users or Purchasing.
               The default PIN for the smart card, which is set by the card manufacturer.

                          Note
                          You can create a script to force the user to change the PIN upon first use
                          of the smart card.

Also, ensure that your enrollment agents review the certificates to verify that the information is correct before
they distribute them to users.
    Using Self-Enrollment
Although using enrollment agents requires more administrative time than allowing users to enroll themselves,
the security benefits usually outweigh the overhead costs. However, using enrollment agents might not always
be possible or necessary. For example, if it is unlikely that smart cards will be misused, or if the consequences
of misuse are minimal, then you might use self-enrollment. In situations in which physical distribution is not
possible, self-enrollment is the best alternative.
                                                                                   Creating a Smart Card Deployment Plan 867




If you decide to use certificate self-enrollment, users can request a certificate from a Windows Server 2003 CA
either manually or automatically. This request can be held pending administrator approval, if you decide that
manual approval is required, or until the verification process is completed. Whichever option you choose, the
certificate self-enrollment process installs the certificate automatically, or automatically renews the certificate
on behalf of the user as soon as the certificate request is approved, based on the specifications in the certificate
template.


Educating Users
User education is an important component of a smart card management plan. Ensure that users understand the
purpose of the smart card deployment. Educate them about proper smart card handling and protection so that
they can help the organization to meet its security goals. Emphasize that a smart card is a valuable resource that
needs to be protected.
For example, be sure that users understand:
                The hardware and software that they need in order to use smart cards.
                How to install and use their smart cards and readers.
                How they can obtain their smart cards and smart card readers.
                What they need to do in order to configure their systems to use their smart cards.

                          Note
                          Setup instructions are particularly important for traveling users, or for
                          users who use remote access connections on their home computers.

                What to do if a smart card is lost or stolen.
                Who to call or contact for help and support.
In addition, provide the following guidelines to users:
                Protect the external smart card chip. If the chip becomes damaged (scratched, dented, and so
                 forth) the reader might not be able to read the data on the chip.
                Do not bend the card. This can break critical internal components. It is risky, for example, to
                 put a smart card in a back pocket, because the individual might sit on it and break its internal
                 components.
                Do not expose the smart card to temperature extremes. Leaving a smart card on the
                 dashboard of a car on a hot day can melt or warp the card and harm the chip. Cold temperatures
                 can make the smart card brittle and easier to break.
                Keep the smart card away from magnetic sources. This includes credit cards and scanners at
                 retail stores.
It is useful to have a printed version of this user training information available for distribution along with the
smart card itself. If your organization also maintains an intranet, publish this information as an easy-to-locate
Web page so that users can refer back to your instructions at a later date.
868 Chapter 17 Planning a Smart Card Deployment




Preparing a Smart Card Deployment
Schedule
Deploying smart cards to a large organization is a major undertaking, often involving thousands of employees. It
is essential that you plan the deployment schedule so that your deployment is orderly, controlled, efficient, and
secure. For example, you might stagger your deployment so that a defined number of users migrate each week.
You can organize this by building or by organizational unit structure.
For a worksheet to assist you in documenting your smart card deployment schedule, see “Smart Card
Deployment Schedule” (DSSSMC_5.doc) on the Windows Server 2003 Deployment Kit companion CD (or see
“Smart Card Deployment Schedule” on the Web at http://www.microsoft.com/reskit).
Figure 16.7 shows an example of a completed Smart Card Deployment Schedule worksheet for an organization
that deployed smart cards according to building.
Figure 16.7 Example of a Smart Card Deployment Schedule Worksheet




In this example, smart card–enabled badges replace the existing building access badges. The plan is to have one
member of the distribution team verify the credentials and status in the corporate database, while a second
person deactivates the old physical access badge and activates the new smart card. The users receive the smart
card, and a document that includes basic instructions, links for more information, an initial PIN, and a reminder
that they need to change their PINs within eight hours.
For more information about preparing users for the smart card deployment, see “Educating Users” earlier in this
chapter.
                                                                           Planning for Ongoing Smart Card Support 869




Planning for Ongoing Smart Card
Support
It is important to have all of the smart card management processes and policies in place before you distribute the
smart cards to your users. Therefore, you need to create a plan for the ongoing use of and support for smart
cards in your organization. When creating a smart card management plan, balance the level of security that you
require against the need for ease of use and supportability. Figure 16.8 shows the steps for planning for ongoing
smart card support.
Figure 16.8 Planning for Ongoing Smart Card Support
870 Chapter 17 Planning a Smart Card Deployment




Selecting Group Policy Settings to Manage
Smart Card Use
Several Group Policy settings are specific to smart card management. You can use these Group Policy settings
to manage smart cards in your organization.

                   Note
                   Other security policy settings, such as lockout policy or restricted logon
                   times, can also impact smart card users if they use their cards for
                   account logon.

            Smart card required for interactive logon
When you set this policy on a user account, the user cannot log on to the account by using a password. They can
only log on by using a smart card.
The advantage of using this policy setting is that it enforces strict security. However, if users are unable to log
on by using conventional passwords, you must provide an alternate solution in the event that smart cards
become unusable.

                   Note
                   This policy setting applies to interactive and network logons only. It does
                   not apply to remote access logons, which are managed by policy settings
                   that are configured on the remote access server.

The Smart card required for interactive logon policy is not recommended for users who need to:
                Join a computer to a domain.
                Perform administrative tasks such as installing Active Directory on a member server.
                Configure a network connection for remote access.
If you choose not to use this security policy setting, users can revert to their standard network passwords if their
smart cards are damaged or unavailable. However, this weakens security. In addition, users who use their
passwords infrequently might forget them, and either write them down, or call the help desk for a password
reset, increasing help desk costs to the organization.
                                                                              Planning for Ongoing Smart Card Support 871




            On smart card removal
Users who walk away from computers that are running an active logon session create a security risk. To enforce
the security of your system, it is best if users either log off or lock their computers when they leave. The On
smart card removal policy allows you to force users to log off or lock their computers when they remove their
smart cards.

                   Note
                   If you select the forced logoff option, users need to make sure they have
                   saved changes to documents and other files before they remove their
                   smart cards. Otherwise, they lose any changes they have made.

Whether or not you set the On smart card removal policy depends on how your users interact with their
computers. For example, this policy is a good choice if using computers in an open floor or kiosk environment.
This policy might not be necessary when users have dedicated computers or exclusive use of multiple
computers. You can use a password-protected screensaver or other means to lock the computers of these users.

                   Note
                   The On smart card removal policy is a local computer policy that is
                   administered on a per computer basis. Set the On smart card removal
                   policy on a per user account basis, along with other domain security
                   policy settings.

            Do not allow smart card device redirection
Use the Do not allow smart card device redirection policy if you do not want to use smart cards in
conjunction with Terminal Services sessions. Restrict this use of smart cards if you are concerned about the
network resources required for Terminal Services sessions in your environment.
            Account lockout threshold
Use the Account lockout threshold policy to disable accounts after a set number of failed logon attempts. An
account that is locked out cannot be used until an administrator resets it, or until the account lockout duration
expires. You can specify a value of between 1 and 999 failed logon attempts, or you can specify that the account
is never locked out by setting the value to 0.
To thwart unauthorized attempts to use a smart card and PIN, establish account lockout thresholds to a low
value, such as four or five attempts.
For more information about creating a strategy for unlocking smart cards, see “Defining Administrative and
Support Processes” later in this chapter.
872 Chapter 17 Planning a Smart Card Deployment




Defining Administrative and Support
Processes
Many smart card–related problems cannot be addressed by means of Group Policy. In some cases, such as with
account lockout policy, Group Policy settings can create support issues for smart card users. You must create a
support plan to address potential contingencies related to smart card use. Use the following steps to create your
plan:
               Identify the person in your support organization who is authorized to perform security-related
                smart card administrative tasks, such as resetting PINs, distributing temporary smart cards, or
                enabling temporary passwords.
               Define and document your plan for escalating and resolving smart card logon problems.
               Define and document any special policies and procedures that you want to establish for specific
                types of employees, such as senior executives, support personnel, or traveling users.
               Define and document the processes for handling name changes.
               Define and document processes for handling changes in employee status, such as when
                employees change from contract to full-time employment, or from full-time to part-time
                employment.
               Define and document the level of smart card support that users can expect to receive outside of
                regular business hours.
    Creating a Plan for Forgotten Smart Cards
Before you deploy smart cards, you must establish a contingency plan in the event that users forget their smart
cards. You can choose to do one of the following:
               Allow users to maintain passwords that they use for interactive logons when their smart cards
                are not available. This is the simplest, but least secure option.
               Issue temporary smart cards with certificates that have short lifetimes, such as one day. This
                solution is useful if your organization has someone on site who is authorized to distribute
                alternate smart card credentials. However, if an authorized agent is unavailable when the user
                needs assistance, the user cannot access the network.
               Enable help desk or security personnel to issue users limited-time passwords that are valid for
                the day. This solution is helpful when no one at the location is authorized to distribute
                temporary or replacement smart cards, or when you need to provide assistance to traveling
                users. If you use this option, you must identify how the identity of the user can be validated.
                Make sure your plan requires the help desk or security administrator to reset the limited-time
                password after the allotted time has expired.

                   Tip
                   When you issue temporary smart cards or passwords to users, you can
                   place those users in a security group that is only able to access a subset
                   of the network resources of your organization. In this way, they can
                   perform their job tasks without compromising the security of your
                   resources.
                                                                             Planning for Ongoing Smart Card Support 873




    Managing PINs
Using smart cards in combination with PINs simplifies the credential management process for your network.
However, you need to create a plan for use in the event that a PIN is forgotten or the account lockout policy
causes contingencies related to PIN management. Specifically, you need to define:
               How locked smart cards can be unlocked. Decide whether you want the help desk to unlock
                smart cards or enable users to unlock their own smart cards.
               How to enable the help desk to unlock locked smart cards. If you determine that the help
                desk is responsible for unlocking smart cards, you need to use some form of secret information
                to verify that the user is who he or she claims to be. For example, you could have every user
                complete a set of predefined questions and answers, which are then stored in a secure database.
                Help desk personnel cannot view the answers to questions. Instead they type in user-provided
                answers to the questions. The database reports back to the help desk staff member whether the
                answers match the predefined answers in the database.

                         Tip
                         Allow users only one attempt to answer the questions correctly, so that
                         an impersonator does not have multiple opportunities to guess the
                         correct responses to the questions.

               How to enable users to unlock their own smart cards. You can enable users to unlock their
                own smart cards by using a secure Web page linked to a database. The user answers a list of
                personal questions, the correct answers to which are stored in the secure database. When users
                need to reset their PINs, they must answer the questions correctly. If they do so, they are
                allowed to reset their PINs.
                This solution does not require help desk support. However, it exposes the PIN reset user
                interface to a larger audience, which is a potential security risk. In addition, it requires the user
                to have Internet access, which might not be possible if the user’s smart card is locked.
874 Chapter 17 Planning a Smart Card Deployment




Additional Resources
These resources contain additional information and job aids related to this chapter.
            Related Information
               The Distributed Services Guide of the Windows Server 2003 Resource Kit (or see the
                Distributed Services Guide on the Web at http://www.microsoft.com/reskit) for more
                information about Certificate Services and Encrypting File System.
               “Connecting Remote Sites” in Deploying Network Services in the Windows Server 2003
                Deployment Kit.
               “Hosting Applications with Terminal Server” in Planning Server Deployments in this kit.
               The Microsoft Platform SDK link on the Web Resources page at
                http://www.microsoft.com/windows/reskits/webresources.
            Related Help Topics
For best results in identifying Help topics by title, in Help and Support Center, under the Search box, click Set
search options. Under Help Topics, select the Search in title only checkbox.
               “Certificate Templates” in Help and Support Center for Windows Server 2003 for information
                about how to configure certificate templates.
               “Prepare a smart card certificate enrollment station” in Help and Support Center for Windows
                Server 2003 for information about delegating enrollment agent authority to individuals who are
                not domain administrators.
            Related Job Aids
               “User and Group Smart Card Requirements” (DSSSMC_1.doc) on the Windows Server 2003
                Deployment Kit companion CD (or see “User and Group Smart Card Requirements” on the
                Web at http://www.microsoft.com/reskit).
               “Smart Card Service Level Agreement” (DSSSMC_2.doc) on the Windows Server 2003
                Deployment Kit companion CD (or see “Smart Card Service Level Agreements” on the Web at
                http://www.microsoft.com/reskit).
               “Smart Card Hardware Specification” (DSSSMC_3.doc) on the Windows Server 2003
                Deployment Kit companion CD (or see “Smart Card Hardware Specification” on the Web at
                http://www.microsoft.com/reskit).
               “Smart Card Reader Evaluation” (DSSSMC_4.doc) on the Windows Server 2003 Deployment
                Kit companion CD (or see “Smart Card Reader Evaluation” on the Web at
                http://www.microsoft.com/reskit).
               “Smart Card Deployment Schedule” (DSSSMC_5.doc) on the Windows Server 2003
                Deployment Kit companion CD (or see “Smart Card Deployment Schedule” on the Web at
                http://www.microsoft.com/reskit).

								
To top