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).
Pages to are hidden for
"Business Card Software - Download as DOC"Please download to view full document