Smart Card Deployment TWP

Smart Card Deployment at Microsoft
Technical White Paper

Published: June 2005; updated August 2008
CONTENTS
Executive Summary.............................................................................................................6
Introduction ..........................................................................................................................7 Improving Remote Network Access Security ...................................................................8 Requiring Two-Factor Authentication 8 Selecting Smart Cards as the Microsoft IT Solution 8
Smart Card Solution.............................................................................................................11 Smart Card 12 Client Hardware Client Software Server Software 15 15 18
Deployment Planning...........................................................................................................20 Approach and Strategy 20 Delegated Issuance Model User Install and Setup Training and Support Issues Schedule 22 22 22 22
Deployment Process ...........................................................................................................24 Card Creation Process 24 Initial Card Distribution Process Communication Considerations for Distribution Distribution Tools Delegated Issuance Model Administration Tools and Issues Enrollment Agent (EA) Delegated Enrollment Agent User Install and Setup Training and Support Issues Network Remote Access Architecture Requirements Extensible Authentication Protocol-Transport Layer Security (EAP-TLS) Virtual Private Networking (VPN) 25 26 27 27 28 29 29 29 30 30 30 30
Internet Authentication Service (IAS) New Remote Access Authentication Process Pilots Managing Authentication Policy Exceptions Helpdesk PIN Management Access Management Security Team Ongoing Maintenance and Operations Post-Deployment Responsibilities Using Existing Network Security Infrastructure
30 31 31 31 32 32 34 34 34 34
Results .................................................................................................................................35 Security Gains 35 Minimized Client Impact Updating the Card Infrastructure 36 36
Lessons Learned .................................................................................................................38 Product Lessons 38 Deployment Process Lessons 39
Other items and Future Considerations ............................................................................42 New Tools 42 Application Support Elimination of Passwords New Technologies Strengthening Account Management Providing for Other Future Uses 42 42 42 43 43
Conclusion ...........................................................................................................................44 For More Information...........................................................................................................45
Situation
Enterprises that allow remote access to network assets are becoming increasingly vulnerable to malicious intruders.
EXECUTIVE SUMMARY
Securing the assets of corporations and governments has taken on a new priority worldwide. With the ever-increasing sophistication, availability, and ease of use of computer and network hacking tools, remote access pathways into enterprise networks previously considered secure are now often virtually unprotected from malicious intruders. The Microsoft Information Technology (Microsoft IT) group responded to this threat by requiring users to employ smart cards, a form of two-factor authentication, for remote access into the network. This change substantially increased the overall security of enterprise network assets and data at Microsoft. The purpose of this white paper is to share architecture, design, and deployment considerations and experiences of the Microsoft remote access solution, demonstrating the value of current Microsoft products in the security hardening and management of remote access. This paper briefly discusses the development of a deployment plan for an initial release of 61,000 smart cards (which subsequently increased to over 120,000); the remote access infrastructure and client software functions currently in place; and the operational processes and tools developed to manage the smart card infrastructure. This paper assumes that readers are technical decision makers and are already familiar with Windows Server 2003 remote access technologies, such as Connection Manager, Remote Authentication Dial-In User Service (RADIUS), and virtual private network (VPN), as well as with associated technologies, such as Public Key Infrastructure (PKI) security. Many of the principles and techniques described in this paper can be employed to manage remote network access risk within any organization, and the design considerations for remote access infrastructure can likewise be applied to most any enterprise-scale IT environment through Microsoft products. However, this paper is based on Microsoft IT experience and recommendations as an early adopter. It is not intended to serve as a procedural guide. Each enterprise environment has unique circumstances; therefore, each organization should adapt the plans and lessons learned described in this paper to meet its specific needs. This paper, last published in June 2005, was updated in August 2008 to reflect the deployment of new Microsoft products within the corporate infrastructure, including the Windows Server 2008 and Windows Vista operating systems. Note: For security reasons, the sample names of forests, domains, internal resources, organizations, and internally developed security file names used in this paper do not represent real resource names used within Microsoft and are for illustration purposes only.
Solution
Using an existing Windows 2000 Server or Windows Server 2003 infrastructure, enterprises can employ smart cards to substantially increase the strength of their network security.
Benefits Strengthen security: The twofactor authentication of smart cards requires more than entering valid credentials. You must possess the smart card and know the PIN. Flexible: Smart card memory contains security certificates, and can be used for in-house development projects. Simple: Smart cards are easy to use. No cumbersome password generators to carry around. No bulky device to break. Leverage existing infrastructure: Using the PKI of Windows 2000 Server or Windows Server 2003, you can create your own security certificates and manage the process internally without dependence upon an external partner.
Products & Technologies Windows 2000 Server and

Windows Server 2003
Active Directory directory

service
Windows-based Public Key

Infrastructure (PKI) and certification authority (CA) Remote access technologies Smart cards
Page 4
INTRODUCTION
As a leading technology company, Microsoft offers its employees the ability to access their corporate e-mail accounts, data files, and company computer network resources through remote access. Remote access is a broad term for the services and connections that allow enabled employees to connect to the Microsoft corporate network from remote locations such as their homes or hotel rooms. Microsoft is a global company with more than 120,000 employees, contingent staff, and contract vendors on staff in over 400 locations worldwide, many of whom use remote network access. Managing the security risks posed by the sheer number of all these remote access accounts has long been an ongoing effort for Microsoft IT. To access corporate network resources, employees use remote access to connect to more than 175 remote network access points worldwide. Remote access methods supported at Microsoft include dial-up, Internet Service Providers (ISPs), and direct Internet connections, such as Digital Subscriber Line (DSL) or cable modems.
Page 5
IMPROVING REMOTE NETWORK ACCESS SECURITY

In the past, employees using remote access to authenticate to networked resources employed the same set of credentials they used to access the network at work: a network username and password. However, employee network user names are commonly distributed on business cards, in magazine articles, or are easily guessed. As a result, the only remaining security mechanism safeguarding the corporate network was the network password. The chief concern of Microsoft IT centered on the fact that there were too few additional security boundaries once authenticated users were given access to the network. Furthermore, activity by unauthorized individuals using valid credentials was difficult to detect and prevent in an environment requiring only a logon name and password for access. Microsoft IT currently enforces a strong password policy for all network users. This standard includes requirements that the password:
Be at least 15 alphanumeric characters long on accounts with administrator privileges on the domain and at least eight alphanumeric characters long on all other accounts. Contain both upper and lower case characters, that is, a-z, A-Z. Have digits and punctuation characters as well as letters, that is, 0-9, !@#$%^&*()_+|~=\`{}[]:";'<>?,./, with one or more of these punctuation characters being within the second (2) to sixth (6) positions. Contain no slang, dialect, or jargon words in any language. Not be based on personal information, names of family, and so on. Not contain words that have the Os changed to zeros or Is to pipes. Be significantly different from prior passwords, that is., users must not use cyclical passwords that contain the same basic content as previous passwords, but with only a part of the content changed.
Despite this policy, Microsoft IT determined that a stronger form of authentication was needed, especially for those accessing the corporate network from a remote computer.
Requiring Two-Factor Authentication

As opposed to the simple network user name and password method of securing network assets, smart cards offer two-factor authentication. Two-factor authentication consists of something the user hassuch as a smart cardand something the user knowsthe smart cards access Personal Identification Number (PIN). The PIN enables the user to access the digital certificate stored on the smart card which, in the case of the Microsoft IT implementation, enables the user to be authenticated on the corporate network. The requirement that a user must have a smart card in hand for remote access authentication significantly reduces the likelihood that an intruder will gain access to the corporate network.
Selecting Smart Cards as the Microsoft IT Solution

To counter the problem of unauthorized users potentially gaining access to the Microsoft corporate network, Microsoft IT studied a number of technologies for securing remote access to the network. After much consideration, Microsoft IT decided to implement smart card technology as its security solution.
Page 6
Microsoft IT did consider several alternative technology solutions before selecting the smart card. Evaluated technologies included biometrics, such as thumbprint scanning; hardware tokens, such as RSA Security's Secure ID, a keychain-sized device that automatically calculated new one-time use passwords at predefined intervals that matched a similar number-changing device on the server; and USB Token reader devices that are somewhat similar to smart cards. Smart cards rated relatively well in all areas and provided the best comparative value overall on the basis of reliability, performance, cost, features, mobility benefits, ease of support, and integration with the Microsoft IT network environment based on the Windows operating system. At the time of the evaluation, Microsoft IT initially judged that smart cards were a less mature technology than was desired. They were considered similar to hardware tokens in that either solution required the user to carry a component that could be lost, damaged, or fail. However, unlike smart cards, hardware tokens require consumables, such as batteries, whose replacements may not always be easily available in all locations worldwide. One significant advantage smart cards offered over hardware tokens was their extensibility for future development and alternative uses. Smart cards were also judged more reliable than biometric scanning devices for security and authentication purposes. Smart cards also compared well to the alternatives on the basis of cost. Microsoft IT did not have experience with the support costs of two-factor authentication solutions and needed to make some assumptions. Smart cards were considered one of the more complex solutions to manage, mainly due to administration issues, such as securely distributing and maintaining the cards, the lack of commercially available management tools, and managing the PKI and certificate architecture used to enable the security technology. In the end, though, all the alternative technologies were judged as either less robust, less scalable, more difficult to support, or much more expensive per head, and many alternatives possessed all these traits, in comparison to smart cards. In addition, the feature richness and extensibility of smart cards provided the opportunity for future applications of smart card technology. Note: Digital certificates, similar to identification cards, are an encrypted set of electronic authentication credentials that are used to certify the online identities of individuals, organizations, and computers. Certificates are issued and certified by certification authorities (CAs). Like driver's licenses, digital certificates are issued by CAs to provide proof for verifying the identity of online entities. However, instead of containing a photograph and the signature of the owner of the certificate, a digital certificate contains information that identifies the certificate's owner on the network and the owner's public key, binding the two elements together. Furthermore, a certificate identifies the CA (called the issuer) that issued the certificate, and this CA must be authorized within the enterprise, to issue authentication certificates. Microsoft IT estimated that the deployment cost of smart cards was a one-time expense of approximately $70 per user, including labor for deployment, server hardware and enrollment stations. However, after deployment was completed, the maintenance and management costs for the Microsoft smart card infrastructure fell significantly. The cost for issuing, replacing, or renewing a card where the card must be physically touched, such as when a new employee is hired, or a smart card is lost or broken, is approximately $36 per card. This is based on a 1.5% per user per month replacement rate. The annual cost per card for
Page 7
activities where the card does not need to be physically touched by support staff, such as certificate auto-renewal, is less than $0.40 per card per certificate. The overall benefits provided by the smart card platform were judged by Microsoft IT to outweigh the associated liabilities, so Microsoft IT proceeded to plan the smart card deployment.
Page 8
SMART CARD SOLUTION

The original smart card selected by Microsoft IT was essentially a 32-bit microprocessor and 32 kilobytes (KB) electrically erasable programmable read-only memory (EEPROM) random access memory (RAM) chip embedded on a card. Most smart chip implementations are on credit card-sized form-factors, but they can also be included in Global System for Mobile communications (GSM) phones, Subscriber Identity Module (SIM) cards, and Universal Serial Bus (USB) Token devices. Most smart cards available today contain between 4 KB and 256 KB of RAM for security-enhanced data storage. The expected life span of a typical smart card at Microsoft is between 18-48 months. Although smart cards are often compared to hard drives, they are "security-enhanced drives with a brain"they both store and process information. They have an operating system and file system configurations with the ability to be partitioned into public and private spaces that can be made available or locked from public access. The segregated locked areas provide protection for information, such as certificates and entire operating systems. In addition to traditional data storage states, such as read-only and read/write, some vendors are working with sub-states best described as "add only" and "update only." Smart cards are also tamper resistant. The smart card operating system used in the initial deployment, Microsoft Windows for Smart Cards, rendered the card useless if anyone tampered with it. Without a smart card reader, the data the card contains is not accessible and the card is not usable. Even with a smart card reader, the user must know the PIN associated with the card in order to access the smart cards protected contents. This ensures the security of the data stored on the smart card, including the private cryptographic key of the logon certificate, the e-mail signing certificate, and the users personal information. Notes: The Windows for Smart Cards operating system is no longer available as a technology solution for sale from Microsoft. However, several smart card solutions that are fully compatible with Windows XP Professional are available from independent solution providers. As new and replacement smart cards are created and distributed, Microsoft IT is temporarily running its smart cards infrastructure in a mixed-mode environment as it slowly migrates all smart cards onto its new 128 KB card platform running a Microsoft .NET Frameworkbased card operating system. The expanded memory capacity of this new card supports a Microsoft IT future-planned expansion of smart cardbased certificates. A key feature of smart cards is that they provide security-enhanced storage for data. Smart cards must support authentication and authorization: the cardholder is authenticated through the PIN, and can be authorized to access only a particular range of data on the card, or carry out a particular range of activities with the card. Using software utilities that are installed on the client computer, users have the ability to view the contents of their smart cards, reset the PINs, renew certificates, and add additional certificates. In the future, users will be able to add new certificates for different applications to the card for added functionality, authenticating that process with the existing logon certificate. Microsoft IT sees the investment in the smart card process as paying dividends in the future when more functionality is added to the enterprise environment to take advantage of this platform.
Page 9
Because smart cards are portable, users can carry personal security certificates and their corresponding key pairs with them wherever they go. Smart cards also enhance softwarebased solutions, including strengthened authentication processes such as local logon, Wide Area Network (WAN) logon, and application authentication. If an employee loses a smart card, it is a simple administrative process to revoke the validity of the lost network logon certificate, thereby rendering the lost smart card unusable for remote access. Even with access to a valid smart card, an intruder would also need the PIN to unlock access to the logon certificate of the smart card. This further minimizes the risk of unauthorized network access. The smart card solution originally implemented by Microsoft IT had five main components: the smart card, the required client hardware, client-side software, server-side software, and network requirements. Table 1 provides a listing of sample components that made up each element. Table 1. Detailed Elements of the Original Microsoft IT Smart Card Solution
Component Smart card Features
Client hardware Client software
Radio Frequency Identification (RFID) Badge card with 32 KB of RAM in chip Windows for Smart Cards operating system File system and personalization Computer capable of running Windows XP Professional or Windows Vista Smart card reader device Windows XP Professional or Windows Vista Cryptographic Service Provider (CSP) Smart card reader device drivers Connection Manager Smart card user management tools
Server software
Microsoft Windows 2000 Server, Windows Server 2003, or Windows Server 2008 Active Directory directory service Public Key Infrastructure (PKI) Smart card administration tools
Network
Extensible Authentication Protocol-Transport Layer Security (EAP-TLS) Virtual Private Networking (VPN) Internet Authentication Service (IAS)
Smart Card
The card management team carefully considered the following elements about the smart card in its technical evaluation:
The card and chip The card operating system The file system and personalization
Card and Chip

A key criterion for choosing a particular smart card and chip was its compatibility with a particular smart card operating system. Like any other microprocessor, smart cards cannot run all possible operating systems.
Page 10
Another key criterion for choosing a smart card was its form factor. Microsoft IT wanted to avoid adding an unnecessary burden to employees, giving them another card or device to carry and possibly lose. Employees already carried an RFID-style photo ID cardkey used to gain building access at Microsoft. The card management team went to the vendor of its RFID cardkey solution, Indala, and asked whether they could embed a smart card chip into the existing employee ID card. The vendor agreed to the request, thereby simplifying the smart card deployment planning effort for Microsoft. No new card key infrastructure needed to be deployed to consolidate the RFID cardkey with smart card technology. The card management team specified the use of a particular model of smart card chip for consolidation with the RFID card key, primarily because of its compatibility with the selected smart card operating system. The combination of the RFID badge and smart card technology provided employees the means with which to access Microsoft physical and logical assets. Furthermore, it meant that smart cards with employee logon certificates would always be kept with the employees rather than being left in a desk drawer or in smart card readers next to computers.
Smart Card Operating System

Smart cards run embedded operating systems and a form of file system in which data can be stored. The card management team demanded that the smart card operating system selected be able to perform the following tasks:
Store a user's public and private keys. Store an associated public key certificate. Retrieve the public key certificate. Perform private key operations on behalf of the user.
Furthermore, the card management team considered the factors listed in Table 2 when deciding which smart card operating system to use. Table 2. Operating System Selection Criteria
Issue Compatibility Concern Is the cards operating system compatible with both the smart card chip and the CSP selected? If one of these elements has been specified, the remaining parts of the solution must match that selection. Does the cards operating system offer extensibility toward other applications? Microsoft IT primarily needed the card for authenticating remote network access. However, adding additional certificates to a card for other purposes, such as e-mail signing and encryption, is a future possibility. Are there management tools available for the card operating system? If not, what expertise is required of an internal development staff to build custom tools for managing the deployment? Can the internal development staff use the card operating system platform for developing additional internal applications?
Extensibility
Ease of management Development platform
The smart card operating system selected by the card management team is a componentbased architecture that supports multiple card chips and platforms. It was selected not only
Page 11
because it could perform the tasks shown in Table 2 but because it also offered the additional following features: security, interoperability with the existing PKI, and extensibility.
Smart Card Security

The card management team configured the smart card operating system to use unique, security-enhanced Administrator PINs on each card created. It further configured the operating system to permanently destroy the card in the event of an attempt at unauthorized access of the Administrator PIN. The card management team also required that the user create a User PIN before using the card for remote access authentication.
Smart Card File System and Personalization

The smart card file system, analogous to file systems used with disk technology, is the structure on which the data on the card is stored. Figure 1 below illustrates the structure of data stored on the original smart card platform implemented by the card management team.
Figure 1. Memory usage in the original Microsoft IT smart card configuration Of the available 32 KB of memory, 15 KB was used for the Windows for smart card 2.0 operating system. The remaining 17 KB was configured as the smart cards file system, upon which the rest of the solution was built. Within the remaining memory, a Microsoft PIN/card management application, which facilitates communications from the server down to the card, used approximately 3.5 KB. Additional files and folders consumed approximately 4 KB and the smart card user logon certificate took up another 2.5 KB. There was approximately 7 KB of available memory left on the current smart card. In all, the original 32 KB smart cards supported up to five certificates. Plans are already being considered for how to best use this remaining empty memory capacity in future expansions of smart card applications. The data contained in the user logon certificate included employee identification, the identification of which CA server issued the certificate, the CA-issued ID number, the certificate implementation and expiration dates, the CAs digital signature, and the public key value.
Page 12
Once the operating system was applied to a blank smart card, the file system structure was created. Once that was completed, other data could be stored onto the card, such as authentication certificates.
Client Hardware
The second component of the card management teams smart card solution was hardware specific to the client computer.
Computer Capable of Running Windows XP

In order to use smart cards for remote access, users were required to have a client computer capable of running Windows XP or Windows Vista.
Smart Card Readers

Smart card readers attach to standard peripheral interfaces, such as RS-232 serial, PS/2, PC Card, and USB. Readers are considered standard Windows devices and carry a security descriptor and Plug and Play identifier. They are controlled through standard Windows device drivers and are introduced to and removed from the system using the Hardware Wizard in Windows. Microsoft IT now also supports the use of new USB Chip/Smart Card Interface Devices (CCID) Plug and Play smart card readers. Over the past two years, the Windows USB Team has worked with various industry partners on the USB smart card class-driver project. This class driver reduces the need for hardware vendors to create a device-specific driver for smart card readers. Eliminating the need for a device-specific driver will potentially reduce the driver development cost, improve driver and system stability, reduce time to market, and lead to a simplified Plug and Play experience for customers using card readers compliant with the CCID specification (revision 1.0 or later). CCID card readers are automatically accepted by the client computer and provide users with enhanced performance. Differences among manufacturers mean that not all card readers perform well with all cards. There are performance differences between card reader devices, so the card management team tested the performance and reliability of several models with the specific smart card selected. Several models passed review and were approved for use at Microsoft. These devices were added to the Microsoft MS Market intranet site for employee purchases. Each employee who used remote access either at home or while traveling was issued one smart card reader when the smart cards were initially distributed company-wide.
Client Software
Client software made up the third component of the card management team's smart card solution. Specific elements of this component are detailed in the following sections.
Windows XP Professional
The card management team stipulated that all client computers using smart cards for remote access to connect to the Microsoft corporate network must have Windows XP Professional or Windows Vista installed. Windows XP and Windows Vista offer support for the EAP-TLS protocol. Although the EAPTLS protocol, a requirement in the new smart card remote access process, has been available since the release of Windows 2000 Workstation, Windows XP Professional was
Page 13
selected as the standard remote access platform to help simplify support issues for the corporate Helpdesk team.
Cryptographic Service Provider (CSP)

Every client computer needed to install a CSP to enable access to the contents of the smart cards chip. A CSP:
Performs all cryptographic operations, such as digital signing. Manages private keys. Facilitates security-enhanced communication between the client computers smart card reader and the smart card.
While each smart card solution vendor provides a CSP to be used for reading the certificate from the operating system on its smart cards, not all CSPs are the same. The card management team tested several CSPs built for use with the smart card operating system and discovered that the level of performance and card security provided by these CSPs varied greatly. After determining that none of the commercially available CSPs built to work with the smart card operating system met its specific security and performance needs, the card management team worked with the Windows product development team to create a new CSP that fully met its requirements. This new CSP was based on a new smart card framework Microsoft was already developing, The benefits the card management team derived from using a CSP developed by Microsoft were that it was small, very secure, efficient, fast, very reliable, and offered clear end-user error messaging. In short, its performance met all Microsoft IT requirements for its clients.
Device Drivers
A device driver for a specific smart card reader maps the functionality of the reader to the native services provided by Windows XP, Windows Vista, and the smart card infrastructure. The reader device driver communicates card insertion and removal events to the Resource Manager and provides data communications capabilities to and from the card by either the T=0 or the T=1 protocols. Microsoft worked closely with reader device manufacturers and enhanced the performance of smart card reader device drivers, including CCID devices, as part of the card management teams initial smart card deployment and ongoing management.
Connection Manager
Connection Manager, a standard feature of Windows XP and Windows Vista, is a tool to facilitate and manage network dial-up and VPN connections. Microsoft IT modified the default Connection Manager by creating specifically configured connectoids with the appropriate server connection settings for using dial-up or VPN into Microsoft remote access servers. The card management team also added specific support user interface text into the program to help users understand the process, set expectations, and communicate what to do if problems arose. This greatly simplified support issues related to users and remote access connectivity. Developers in the card management team used the Connection Manager Administration Kit (CMAK) to customize its Connection Manager implementation. The CMAK is a wizard-based administration tool that allows ISPs, corporations, or administrators to create custom Connection Manager profiles, which can include:
Page 14
Connection actions that the dialer will perform, such as running scripts to check and configure machine security. Customized icons for the desktop. A branded logon screen with animation. Support and local dial-up access telephone numbers and help files that are unique to the customer's organization. The language the dialer will display to the customer.
The client-side changes included a policy requiring remote users to connect using Connection Manager with customized profiles that perform system configuration checks at logon for:
Up-to-date antivirus software and signature files. Internet Connection Firewall (turned on). Internet Connection Sharing (turned off). Current corporate standard operating system with required hot fixes (Windows XP Professional SP1 at the time of this writing). Authentication certificate expiration (all must be valid). Removal of all duplicate and expired certificates of the same certificate type (also known as object identifierOID).
Only if all the checks are confirmed is the remote user granted access to the network. Using CMAK, these configuration checks could be further customized and updated, based on relevant security threats using auto-update features available in the security scripts.
Smart Card Management Tools

The card management team required that the client computer install a collection of client smart card management, connectivity, and security tools to use the card for remote access. Using these smart card management tools provided by the card management team, users were given the ability to view the contents of their smart cards, to reset the user PINs, and to add additional certificates. In the upgraded smart card solution, Microsoft IT designed and implemented a new end-user PIN management tool. This tool is a self-help PIN reset tool to allow end users to perform this function without the direct intervention of Helpdesk personnel. Previously, this task was a complicated task requiring the assistance of Helpdesk. This tool saves the end user time and reduces the number of smart card-related phone calls to Helpdesk, thereby reducing support costs for Microsoft IT. Microsoft IT also required tools to manage and process smart cards. Initially, several third party vendors were evaluated, and Microsoft chose to standardize on one platform. After some time, however, it became apparent that the third party solution was not up to the requirements of the very complex worldwide Microsoft enterprise. Microsoft IT decided to build its own smart card management tools in-house. This had the additional benefit of supporting the delegated issuance model made possible by Windows Server 2003.
Tools for Card Issuance, Distribution, and Management

Another complicating problem was that there were several smart card processing platforms available at the time, and there was no standardized compatibility between them. This lack of
Page 15
standardized compatibility was not a significant issue for Microsoft IT. Once a particular platform was selected, Microsoft IT determined that it would standardize on that selection. The lack of tools was resolved when Microsoft IT made the decision to develop the necessary tools in-house.
Server Software
The fourth component of the card management team's smart card solution consisted of server-side software requirements.
Active Directory
Active Directory is the Lightweight Directory Access Protocol (LDAP) V3-compliant directory service available in Windows 2000 Server, Windows Server 2003, and Windows Server 2008. It stores information about objects on the network and makes this information easy for administrators and users to find and use. Active Directory uses a structured data store as the basis for a logical, hierarchical organization of directory information. Microsoft IT implemented Active Directory service with its initial rollout of Windows 2000 Server in 1999. Security is integrated with Active Directory through logon authentication and access control to objects in the directory. The digital certificates used with smart card remote access authentication are stored in Active Directory, along with user account groups and associated rules. The card management team used the existing Microsoft IT Active Directory infrastructure as the security management foundation for the smart card deployment.
Public Key Infrastructure (PKI)

Windows 2000 Server PKI was already in place at Microsoft when the decision was made to implement smart cards for authenticating remote access. As a result, the card management team decided to use its existing security infrastructure instead of contracting third-party services to create and manage certificates for smart cards. Using the in-house PKI service, the card management team created the digital certificates that were installed onto smart cards. The Windows Server running this service is the CA. Initially Microsoft IT used the Windows 2000 Server PKI to deploy more than 25,000 smart cards and certificates to users in Redmond. If not for the fact that Microsoft is a global enterprise with now more than 120,000 employees and staff scattered all around the world, the Windows 2000 Server would have been an excellent platform upon which to build the smart card solution. However, as the number of deployments increased, the card management team recognized that deployment and support times for users outside Redmond were not going to meet target requirements. Furthermore, with the card management teams standard of setting certificates to expire in one year, large support costs were likely to be incurred in manually updating tens of thousands of annually-renewed user certificatesan administrative workload the card management team was not set up to manage. The card management team needed greater flexibility with its PKI. The enhanced PKI features of Windows Server 2003 and Windows Server 2008 offered the card management team the greater flexibility it needed. The added granularity in assigning permissions to elements of a default certificate template as well as customizing their own templates helped the card management team meet the service and security goals it required as a global enterprise. The improved granularity of template permissions was a key element enabling the card management team to begin securely using a delegated certificate issuance model used for deployments outside Redmond.
Page 16
Certificate templates were set up to specify default properties, such as certificate expiration dates. Microsoft IT uses a one-year period for its authentication certificate life cycle. The card management team also took advantage of the greater flexibility and improved PKI features of Windows Server 2003 to set up rules for certificate auto-renewal. Using the new granular certificate template permission features, the card management team was able to set a requirement that all new smart card certificate enrollments must be performed by the card management team security officers (SOs). However, users would be able to renew their own smart card certificates by employing the existing valid certificate to sign the renewal request for its replacement. Had the card management team used the PKI for Windows 2000 users would not have been able to renew their own smart card certificates because the template configuration options are not available in a Windows 2000 PKI. All smart card renewals would have had to have been performed manually, by the smart card management team. The ability to leverage the auto renewal functionality of the Windows 2003 PKI has resulted in significant cost savings for the ongoing costs of smart card usage. Note: The improved PKI features that provide the flexibility to set up rules for certificate autorenewal are also included in Windows Server 2008.
Card Management System (CMS)

In order to facilitate security-enhanced management and support of their smart card infrastructure, Microsoft IT designed its own card management system (CMS). The CMS includes tools to allow SOs and delegated issuance officers (DIOs) to manage the deployment and lifecycle of smart cards. Some of the key tasks performed using the management system included:
Activating smart cards. Querying a card to see what certificates are present, their expiration dates, and status. Checking a card to make sure it is valid and functioning correctly. Resetting a smart card PIN. Replacing an expired certificate. Revoking certificates for a card that has been reported as lost. Reporting on a card or user's history, including dates of certificate issuance, renewal, revocation, and PIN reset attempts. Reporting on the shipping and delivery history of a smart card. Migrating users from an old smart card to a new smart card if required.
When smart cards certificate requests are submitted by the DIOs, they go into a pending state. The CMS allows card management team members to review and approve or deny pending certificate requests. These pending requests are then evaluated by the SOs and the certificates are only issued upon approval. Once issued, the certificates can then be retrieved and written onto the card, then distributed to the end user. When the user obtains the newly issued card, it must first be activated before it can be used. The activation process allows the user to set his or her own unique PIN. Only after successful activation is the card and certificate available for use.
Page 17
DEPLOYMENT PLANNING
Microsoft IT had two primary goals for the smart card deployment project: 1. 2. Increase the security of the Microsoft corporate network by securing remote access connectivity. Minimize the impact of the resulting solution upon the user.
In migrating to a new technology for a new application, Microsoft IT had much to consider. It was necessary to understand the technical capabilities of smart cards and how they could be applied to the need at hand. They had to consider the fact that in the end, more than 55,000 people (the number of initially planned smart card recipients) would be affected by the decisions they made for its application. They had to consider the user base, which ranged from extremely technical senior developers and technology researchers to far less technical administrative staff. The solution and its requirements had to be understood and usable by everyone. Microsoft IT also considered the security of the proposed system. What changes would be required to the internal security infrastructure? How would the cards, once created with digital certificates applied, be distributed to all employees around the world in a secure manner? What tools would be needed to securely and efficiently distribute the cards to employees? What tools would users need to set up their computers to use smart cards? What distribution and maintenance procedures would be required to insure security was maintained while minimizing any complications to the user base? How would the technology be supported? There were many questions to be considered. This was especially challenging for Microsoft IT, because at the time the project was initially considered, there were no examples anywhere in the world of smart card deployments used for authenticating remote network users on the scale Microsoft IT was considering. Furthermore, there were no mainstream, commercially available, smart card deployment or administration tools for Microsoft IT to use. Every problem needed to be thoroughly considered and custom tools needed to be developed to solve problems. Microsoft IT really had to start from scratch and design an enterprise-level security system using the technology potential made available in smart cards. Microsoft IT had no choice but to move forward and design a deployment plan that considered all the aforementioned issues.
Approach and Strategy

Microsoft IT decided that the only way to be successful and safeguard company security was to leverage internal resources in the development of this solution. A side benefit would be the knowledge gained from the experience, which would be fed back to the product development teams for enhancements in Microsoft enterprise server products. Microsoft IT determined first that it was best capable of managing the internal security needs of Microsoft, so its Windows 2000 PKI security infrastructure (particularly the internal CA) was selected to create all the digital certificates needed for the deployment. Microsoft IT wanted tight control over who got what levels of certificates and how they were issued and distributed. This internally based solution also saved money for Microsoft IT because they did not have to pay for a third-party, digital certificate issuance service.
Page 18
For more information about how Microsoft IT set up its own internal PKI, refer to the IT Showcase white paper Deploying PKI inside Microsoft at http://www.microsoft.com/technet/itsolutions/msit/security/deppkiin.mspx. With regard to network technology accommodations, Microsoft IT recognized that little change was needed to implement the solution as planned. Microsoft IT leveraged the existing trusts between the multiple forests in the Microsoft network architecture. Microsoft IT also used the existing structure of the Remote Authentication Dial-in User Service (RADIUS) Internet Authentication Service (IAS) servers for authenticating remote access users. The only change IAS required was that it had to be upgraded to use EAP-TLS. For more information about how Microsoft IT manages its remote network access process, refer to the IT Showcase white paper Security Enhancements for Remote Access at Microsoft at http://www.microsoft.com/technet/itsolutions/msit/security/rasecwp.mspx. Microsoft IT recognized that the deployments would have to be phased in over time. Employees were organized into groups defined by their geographic locations. Within Redmond, this meant by building; elsewhere, it was typically by regional offices. Microsoft IT addressed the need for tools by examining the tasks required for both the card distribution and client installation and configuration processes. Tools to manage the certificates and card life cycle were also needed. Due to the lack of commercially available tools, Microsoft IT committed to investing in the development of its own tools and procedures. By doing so, it controlled the security of the process from beginning to end. It also took into consideration the employees and their needs for ease of installation and physical deployment to their remote computers.
Initial Card Distribution Process, Redmond vs. Rest of World

Distributing smart cards securely in over 400 locations around the world posed a serious challenge to Microsoft IT. Microsoft IT needed to ensure that the worldwide deployment went smoothly and caused as little disruption to end users as possible, while maintaining security. As in Redmond, card issuance required a physical exchange of the old ID card for the new smart card. Distribution events were planned for the initial deployment of smart cards at each location. Microsoft IT developed a structured communication plan to prepare users for the event. Special attention was paid to exceptions, just as in the Redmond deployment. Microsoft IT chose a delegated issuance model for smart cards in order to help establish and maintain the security of the smart card lifecycle. Special efforts were made to train staff in the DIOs and to keep the lines of communication open. Microsoft IT also scheduled, and still carries out, regular conference calls with DIO staff. This has the added benefit of helping to ensure that the smart card experience remains consistent throughout the world.
Card Management Team

To better organize the smart card planning and deployment effort, as well as to maintain the highest level of security for the project, Microsoft IT created the centralized card management team. This teams role covered project planning, tools development, piloting, certificate issuance, smart card distribution management, and later escalated end-user support (after Helpdesk).
Page 19
Delegated Issuance Model

Microsoft IT realized that worldwide distribution of smart cards to all employees from Microsoft corporate headquarters in Redmond, Washington, would be a significant challenge. Requiring that the distribution be managed in a secure manner complicated the matter. The decision was made early in the project that each smart card required a physical exchange of the old ID badge for a new smart card badge between a trusted Security Officer (SO) and the employee. The SO would, in effect, visually validate the identity of the user receiving the new smart card. Because of this decision, Microsoft IT recognized that the resources in Redmond could not do it all effectively, so it decided to find people regionally who could assist with distribution. Microsoft IT initially designated 45 delegated issuance sites and appointed one Delegated Issuance Officer (DIO) per site to support various global regions (the number of DIOs has since grown to 100 as of this writing). DIOs were allowed to build and distribute new smart cards as needed, but they still needed to submit requests for new certificates to Redmond. Once the requests were approved by the Microsoft IT SOs, the DIOs were then authorized to create and apply the approved certificates to the cards and distribute them to users. The use of DIO regional representation also filled the anticipated need for local program support and speedy card delivery. Global employees did not have to wait for Redmond to issue and ship new cards. However, Microsoft IT was not able to implement the delegated certificate issuance model of distribution until it upgraded its network to Windows Server 2003 to take advantage of its enhanced PKI features.
User Install and Setup

The user installation and setup process had to be planned to ensure that remote access users were able to connect to network resources with minimal difficulty. Once a card was issued, users would need to activate the card. They would need a functioning smart card reader on the machine they intended to use to access the network. The Microsoft CSP and Connection Manager would also have to be installed on this machine. Over time, the card management team was able to refine and streamline this process. Documentation was developed and improved to enable users to carry out the process with minimal helpdesk intervention.
Training and Support Issues

Microsoft IT determined that the smart card system would require an organized level of ongoing support for internal employees. They worked with Helpdesks existing remote access networking support technicians and provided them with technical documentation and support scripts. Microsoft IT maintained regularly scheduled communications with the support staff to improve technical knowledge on the part of the support teams and to provide program and technical feedback to Microsoft IT.
Schedule
The card management team began investigating the use of smart card technology in the latter half of 2000. A small proof-of-concept pilot was run in early 2001. Three months later, in mid-2001, a much larger second pilot was conducted successfully. The full production rollout was done initially in Redmond on a building-by-building basis, starting in the autumn of 2001 and running through winter of 2002. Due to continuing changes in the technologies used, the rollout was halted temporarily while adjustments were made. The rollout resumed in
Page 20
Redmond in summer of 2002, moved on to global employees in the autumn of 2002, and was completed worldwide by the end of 2002. The production rollout schedule was based on distributing to a defined number of users per week, taking into account their anticipated support needs. At the end stages of the deployment, the card management team was producing smart card user ID badges at the rate of 2,000 per week.
Page 21
DEPLOYMENT PROCESS
Insuring the final integrity of the smart card deployment operation required rigorous security measures. The card management team limited the number of people who had the ability to perform these tasks. The servers that administer the PKI service needed to be run securely, so only a small number of system administrators were granted access to those computers. These system administrators had the ability to easily revoke a logon certificate if a card was lost or an employee left the company. Companies should consider carefully whether to host their own PKI solution or use a third party provider. Third party PKI CA solutions can be very expensive. Microsoft IT chose to host their PKI solution internally using their existing infrastructure built on the native PKI support in Windows 2000 Server and Windows Server 2003, and migrated to current and future versions of Windows Server. Using the existing self-hosted PKI yielded significant savings for Microsoft in per-certificate costs. In comparison to some of the other security technologies considered, the cost of smart card deployment and administration was generally considered relatively high. That was mainly because all the end-to-end issues involved were taken into account, from the management of the PKI servers and certificates, to the smart cards held by the users, and including the security measures used to manage the distribution process. The card management team budgeted approximately $70 per head for the initial deployment of the whole solution, including the smart card and the smart card reader as well as the infrastructure for management, tools development, and support costs.
Card Creation Process

Because the card management team already had the operating system it wanted to use, it purchased blank smart cards from the card vendor. The card management team was given the option of buying cards with the specified operating system already on them. However, the card management team wanted to maintain total control of the security of its cards from beginning to end. The card management team also had the unusual advantage of already possessing the facilities (used for creating the original RFID cards) and the technical staff support (experienced in managing the Microsoft IT PKI) needed to initially prepare the more than 61,000 individual smart cards. Building each smart card for the initial deployment was a multi-step process for the card management team: 1. Load the operating system onto the smart card chip. The card management team built a custom tool to apply the smart card operating system onto the cards chips. Note: Smart card manufacturers commonly supply cards with the operating system preloaded, per the purchase specification, so this step may not be necessary. The Microsoft IT migration to a .NET Frameworkbased smart card will eliminate this step for future card deployments as the cards supplied to Microsoft will already have the operating system loaded onto the chip. 2. Load the file system onto the chip. The setup of the file system on the cards was a function of the smart cards' intended use in the corporate enterprise. The card management team considered the size and number of certificates to be applied, the
Page 22
security permissions needed for the Administrator and User PINs, and the PIN management tools space requirements. Once these plans were in place, the card management team developed its own tool to create the file system storage area and directory structure necessary to meet these needs on the cards. The unique Administrator PIN and the cards globally unique identifier (GUID) were applied at this stage. Note: These first two steps are done by the card management team in bulk prior to specific requests being received for individual smart cards, which are then custom-built one at a time. Smart cards built in this stage either can be securely stored for later processing in Redmond or sent to the DIOs for further processing. 3. Apply printing onto the card. The existing card printing application was used to print the cards, which also served as RFID-enabled employee ID badges. Each card was printed with the employees photo, full name, employment status (employee or vendor staff), employee number, and the Microsoft logo. Note: Smart cards built for user roles, such as administrator accounts, rather than specific individual employees, do not have photos printed on them. However, they still have the individual employee name for whom the smart card is being built printed on the card. 4. 5. Personalize the card. Each card is personalized by adding a unique GUID to the card. This card and GUID will then be associated with a particular user. Apply the certificate to the card. Once the card has everything else applied to it, the users logon certificate and unique random PIN were applied to the card.
Initial Card Distribution Process

Prior to the card distribution process, the card management team placed prospective smart card recipient accounts into a global group in Active Directory. Once the physical smart card was fully prepared for distribution, great care was taken in getting the correct card into the hands of the correct user. The card management team authorized trusted smart card Security Officers (SOs) to distribute the new smart card badges to employees upon verification of their identity. Once the identity of the recipient was confirmed, the smart card SO exchanged the recipients old building access badge for the new smart card badge. The SO also provided an instruction sheet explaining the remote computer setup requirements, including the installation of Windows XP Professional, smart card driver updates, the customized Connection Manager, the CSP, and a Microsoft IT-approved antivirus program. The smart card SO then recorded the card status in the card management teams smart card management database tool so the user could activate the card. All cards were distributed in a state requiring activation before they could be used. To facilitate the activation process, activation workstations were present at smart card distribution events. Smart card recipients logged onto an activation workstation computer, navigated to a security-enhanced, intranet-based Web page, and inserted their new smart cards into a reader device. Part of the process of activating a card forced the card's user to create the initial PIN associated with the certificate. That PIN was known only to the user.
Page 23
Microsoft chose not to use preset PINs on undistributed cards for two reasons: 1. 2. It wanted to protected itself in case smart cards that were fully prepared but not yet distributed were lost or stolen. PINs created by the end user were far more likely to be remembered than preset PINs assigned by the card management team.
The second reason reduced the need for Helpdesk support for PIN resets as well as minimized the likelihood that users would write the PIN on a sticky note attached to the card or on the card itself, thereby diminishing much of the security value built into the smart card's two-factor authentication design. The card management team required that PINs be alphanumeric and be between five and eight characters in length. After the initial PIN was set during activation, users managed their PINs with the client card management software installed on the remote access computer. This client software was supplied by the card management team. Once the initial distribution event for a particular location passed, regardless of whether or not the employee was actually there to pick up the new smart card, the use of the smart card for remote access was enforced. Only employees who had made prior exception arrangements with the card management team, such as those who were traveling during the event, were allowed to continue temporarily using their standard network logon credentials for remote access. Some Microsoft employees worked from very distant locations in offices with very few staff members. In those situations, the new smart cards were sent to the closest location with a DIO available. The DIOs were supplied with a series of pre-built smart cards, including everything except user certificates, whose unique serial numbers were carefully tracked in the smart card management tool. Person-to-person distribution of smart cards, which enabled the DIO to validate the users identity, was still a requirement. Some employees had to travel moderate distances to get their new smart cards.
Communication Considerations for Distribution

Employees were notified in advance of the coming switch to smart cards and instructed on how to prepare for the change. E-mail communications were prepared, based on location. The first e-mail message was sent two weeks ahead of time to alert the employees at that site to the upcoming smart card distribution event. A reminder e-mail message was sent one week prior to the scheduled event. In Redmond, each building was scheduled for a visit by the smart card distribution team. The notification message contained the scheduled date and hours of the distribution event for that location or building, what to expect when the old RFID badge was exchanged for the new smart card, and what an employee had to do to activate the smart card after receipt. There was also information about how to get the smart card if the employee could not attend the locations pre-scheduled distribution event. This was critical information, for the card management teams distribution process required both a visual identification of each person receiving the new smart card and a physical hand-off exchange of the old RFID badge for the new smart card ID badge. This was required to maintain the highest levels of security and integrity in the system.
Page 24
The card management team created a special smart card distribution team e-mail alias to organize the distribution process. Distribution lists of prospective users were created for each distribution location. Given the size and scope of the smart card distribution, which affected more than 61,000 users at the time, special Microsoft Exchange Server mailboxes were created to account for the anticipated e-mail feedback and questions. Staff was assigned to track feedback and respond, as required, to questions and special requests. Special notice was paid to "out-of-office" auto-replies in e-mail, which often indicated the recipient might not be able to participate in the distribution as planned. This helped minimize the churn of managing the distribution process to the same employees multiple times. In addition to e-mail, handout flyers were developed for distribution along with new cards to help users understand what was required of them to get the smart card working (the activation process), how the card solution worked, and what to do if they ran into trouble. To back up the flyer, a special intranet Web site dedicated to the smart cards program was developed. It served as a centralized portal for all information related to setup, use, and problem resolution for smart cards. The new card activation steps were outlined in detail, offering access to software downloads and procedures for setting up a client computer. Additional information about smart cards was made available in the form of Frequently Asked Questions (FAQ), user videos, and distribution schedules.
Distribution Tools
Tools were developed specifically for managing the smart card distribution process. As a card was distributed, its unique serial number, previously added to the database, was marked as user received. This allowed that card to be activated by the recipient. Another tool developed by the card management team was the smart card activation intranet Web page, which compared the users Windows authentication to the smart cards serial number. If there was a match, the user was allowed to set the initial PIN for the smart cards user certificate, which was required for accessing the certificate later during the remote access validation process.
Delegated Issuance Model

To offer support that would be more responsive and ensure that the highest level of security would be maintained when distributing cards to employees around the world, the card management team developed its own delegated issuance model for smart cards. The delegated issuance model was the distribution model the card management team used to deploy smart cards outside Redmond. Before the deployments outside Redmond began, the card management team went out on a worldwide tour to personally visit and train the various DIOs on the procedures required of them, their duties, secure smart card distribution methods, and how to use the internally developed smart card tools. Afterwards, DIOs participated in weekly teleconferences with the card management team to keep up-to-date on emerging and continuing issues.
Page 25
The flowchart in Figure 2 illustrates the steps taken in the delegated issuance model for getting a certificate request approved:
1. User requests smart card from DIO
2. DIO submits request to SO in Redmond
4. DIO receives approval, issues new certificate , and distributes smart card
Yes
3. Redmond SO approve? No
5. Need to audit user Figure 2. Architecture used to implement smart cards in the remote access process request 6. Request completed
1. 2. 3. A user requests a smart card from the DIO either as a new hire or as a replacement for a lost, damaged, or stolen card. The DIO validates the users identity by looking up the users account within the domain. If valid, the DIO submits a certificate request to the Security Officer (SO) in Redmond. The SO validates the request by checking to see if any prior certificates had been issued in that users name. The SO also checks to see if there is an ongoing audit of other requests made in behalf of that user. If the SO determines there is no reason for objection, the approval is given. If the SO does uncover a problem, the process skips ahead to step 5. The DIO receives the approval and uses the EA account to issue the requested certificate. A new smart card is created in the steps outlined in the section Card Creation Process. The completed card is then personally distributed to the user. The process then skips to step 6. The SO initiates an audit of the request to determine if the user can be approved for a smart card. A new request must be made after the audit has been concluded. The delegated issuance process is finished.
4.
5. 6.
The implementation of the delegated issuance model was only possible after Microsoft IT migrated the corporate CAs to Windows Server 2003. The enhanced flexibility of its PKI, particularly with the ability to specify detailed permissions to portions of the certificate templates, allowed the delegated issuance model to support the required limited functionality of Delegated Enrollment Agents.
Administration Tools and Issues

When the card management team began preparing for its testing and deployment of smart cards, the relative immaturity of the smart card industry in the United States meant that there was little to no availability of commercial smart card system administration and management
Page 26
tools, especially those that met all the enterprise-level deployment needs of the card management team. Because the card management team could not get the tools needed to implement its delegated enrollment model from a commercial vendor, it had to design and build its own tools.
Enrollment Agent (EA)

An enrollment agent is an administrator-privileged certificate enabled to request and issue certificates on behalf of any user in Active Directory. The card management team created and stored special EA certificates and user accounts used by its DIOs on other smart cards to better manage their use and monitor their security. This way, only a person who had physical access to the EA smart card (which was physically secured when not in use) and who knew the EA PIN could use the EA. During a typical enrollment process, the EA wrote the certificate on a user's smart card. The EA then became a member of the Certificate Requester Group in Active Directory.
Delegated Enrollment Agent

Once smart card deployment was launched beyond Redmond, a delegated enrollment agent program was created to manage and support the effort of creating new and replacement smart cards with Redmonds EA-generated certificates. These roles became the DIOs discussed earlier. Each DIO was given access to his or her own permission-limited EA. The certificate permissions assigned to the DIOs allowed them to issue requests on behalf of employees in their regions for authentication certificates for new or replacement smart cards. If their requests were approved by a card management team SO, the DIO then had the authority to take the new certificates and apply them to new, blank smart cards.
User Install and Setup

Recipients of a new smart card were required to activate the smart card and set a user PIN. Recipients could activate their cards on either one of the activation workstations provided at the distribution event or on any computer directly accessing the Microsoft corporate network that had been previously equipped with the necessary client components, smart card reader, and CSP. Prior to using a card, the user needed to install the card management teams customized version of Connection Manager, the CSP, and the smart card reader device and associated device drivers onto the computer intended for use as the remote access computer. The software components were available on the activation intranet Web page. If the user was setting up a laptop computer for this purpose, the laptop simply connected to the corporate network so the software could be downloaded and installed. If the users remote access computer was a desktop system at home or some other remote location, the card management team set up an extranet Web site that required the user to enter corporate network logon credentials to gain access. Once validated through the extranet authentication process, the same smart card setup software available from the intranet site was available for download and installation. Alternatively, if only the CSP was needed, it was small enough to be copied onto a floppy disk and carried to the home computer. The card management team worked diligently, throughout the distribution process, to continuously streamline the smart card installation process for Microsoft employees. Much of
Page 27
the installation was automated, and five simple steps, described in useful detail, resided on the intranet activation Web site. The steps helped users: 1. 2. 3. 4. 5. Walk through the process of installing the smart card reader device and its corresponding driver. Install the CSP. Activate the smart card. Install the card management teams customized Connection Manager. Delete any older versions of smart card software (possibly remaining on the computers of early adopters and pilot users).
Training and Support Issues

A major component of the smart card deployment project was preparing support teams. This effort was primarily directed toward the Microsoft Helpdesk remote access networking team. However, the DIO staff also needed training in preparation for assuming their new roles within the security infrastructure at Microsoft.
Network Remote Access Architecture Requirements

Network requirements were the last component of the card management team's smart card solution. The same basic remote access architecture, consisting of VPN servers and IAS RADIUS proxies and authentication servers previously used for authenticating network credentials, was used with the new smart card project.
Extensible Authentication Protocol-Transport Layer Security (EAP-TLS)

Extensible Authentication Protocol - Transport Layer Security (EAP-TLS) is an authentication protocol supported by the Windows operating system that can use certificates for authentication. EAP-TLS is an extension of the Point-to-Point Protocol (PPP). The card management team had to enable the use of EAP-TLS on the corporate network for the smart card deployment project to work.
Virtual Private Networking (VPN)

There were not any major changes required of VPN other than enabling EAP-TLS authentication on the VPN server. Microsoft IT continued to use Point-to-Point Tunneling Protocol (PPTP) technology for use with remote access connections as before, enabling it to work with smart card authentication.
Internet Authentication Service (IAS)

IAS is the Microsoft implementation of RADIUS. The IAS Servers were configured to require a certificate for a remote access authentication. However, within IAS, there is no way to determine the source of the certificate being presented. This certificate could be stored within the client system's software, on a smart card or any other certificate storage device. The card management team worked with the Windows Server product group to update Windows Server 2003 IAS to allow more granular control over authentication policies. This update provided the ability to define a specific OID value that would be required within any certificate used for authentication. Once a particular OID value is specified, IAS was able to limit the
Page 28
acceptance of certificates to only those issued by a Microsoft internal CA containing the specific OID. Issuance of certificates containing this OID value was then restricted to smart cards. This process allowed Microsoft IT to effectively require that all certificates used for remote access authentication resided on a corporate issued smart card.
New Remote Access Authentication Process

As of this writing, Microsoft IT manages more than 250,000 remote access connections each week. Implementing the smart card solution necessitated changes in the remote access process. New to the remote access authentication process was the requirement to use a customized Connection Manager connectoid, which was pre-configured to require the use of smart cards for authentication. When users launch the connectoid, they are automatically prompted to insert their smart card into a reader, if not already inserted. Once the card is inserted into the reader, they are prompted to enter their PIN. Only after correctly entering their PIN is the connectoid able to successfully retrieve the private key from the card, needed to authenticate the user. The Connection Manager connectoid presents the user's certificate to the remote access server for authentication. The user's credentials are provided within this certificate and the user is granted remote access connectivity according to the authentication policies defined on the IAS authentication server. The additional processing from reading the logon certificate stored in the smart card adds approximately 20-25 seconds to the initial authentication process. However, once the authentication is complete, there is no additional performance hit because the smart card is not used after that point and can be removed from the smart card reader. For more information about the specific processes employed by Microsoft IT that occur during remote access authentication, refer to the IT Showcase white paper Security Enhancements for Remote Access at Microsoft at http://www.microsoft.com/technet/itsolutions/msit/security/rasecwp.mspx.
Pilots
The card management team chose to conduct two separate pilots of the smart card for remote access project. The first pilot, consisting of approximately 75 highly technical participants from Microsoft IT staff, was run in early 2001 as a proof-of-concept test solely to determine the viability of smart card technology for securing remote access. Approximately three months later, a second, much larger, deployment and production pilot was conducted with a larger, more diverse group encompassing approximately 800 users in one building complex. The second pilot was necessary to determine how scaling up the deployment size affected technology and support issues discovered from the first pilot. Once both pilots were successfully completed, plans were developed incorporating lessons learned for the full-scale deployment of the technology company-wide.
Managing Authentication Policy Exceptions

The card management team recognized that managing exceptions to the mandatory use of smart cards would be necessary. Some would be permanent exceptions, such as with members of the Macintosh development team at Microsoft who required remote access capabilities (Macintosh computers do not support EAP-TLS). Other exceptions would be
Page 29
temporary, such as when a Microsoft employee traveled overseas to make a presentation and his smart card was damaged during the trip. Microsoft IT needed a solution to manage these exceptions. In enabling the requirement to use smart cards for remote access authentication, Active Directory security groups were created. The authentication polices on the IAS servers were then applied to these security groups, which allowed the enforcement of smart card usage for any member of these groups. Similarly, security groups were created with which to manage the needed exceptions. Separate groups were created to handle both long term and shortterm exceptions. To get users needing temporary remote access exceptions back online, the card management team worked with Helpdesk to create an intranet Web-based policy exception tool that Helpdesk technicians could use to add the user to a temporary exception group in Active Directory that superseded the normal policy restrictions of the smart card group. Placement in this temporary exception group offered users between 24-48 hours of nonsmart card access to the corporate network from either a dial-up or VPN connection. With such a small number of temporary exceptions occurring at any one time, the Microsoft IT Corporate Security Team was able to easily monitor the connections made with the credentials of employees placed in the temporary exception Active Directory group, making sure that no malicious activity took place during the time that account was connected. After the temporary access expired, the Helpdesk tool automatically removed the user from the temporary exception group, restoring the default policy restrictions for members of the smart card group.
Helpdesk
During the early days of pilot deployments, the Helpdesk remote access networking team received additional, specialized training dedicated to diagnosing and troubleshooting smart card remote access issues. There were challenges in keeping Helpdesk abreast of the most current technical information and resolution procedures for the latest recurring issues because the deployment was phased in across the company. To meet those challenges, the card management team wrote many technical support articles specifically for use by the Helpdesk remote access networking team. They developed checklists for diagnostic troubleshooting procedures and even created questionnaires with specifically-ordered heuristic questions for the Helpdesk. Coding recurring problems into the Helpdesk incident-tracking tool enabled the Helpdesk remote access networking team to develop a taxonomy for troubleshooting smart cardrelated problems. The Helpdesk team began, and continues today, to have weekly conference call meetings with all smart card Helpdesk technician teams across the globe (located in offices in Colorado Springs, Colorado, United States; Tokyo, Japan; and Dublin, Ireland) in an effort to continually streamline and improve the performance of the support offered to users. The card management team created a smart card Knowledge Base intranet Web site for Helpdesk technicians to reference. The card management team also provided Helpdesk training, including video teleconferencing, to further assist the support teams in developing their skills and problem resolution procedures.
PIN Management
Because the primary Microsoft IT goal for using smart cards was to improve network security, the security of the data stored on the smart card itself was paramount in achieving that goal.
Page 30
During the deployment, forgotten PINs emerged as a challenging issue. The card management team recognized that many users, who do not use remote access on a regular basis, would forget their PINs, and that this problem would often surface when users were attempting to gain remote access while away on travel. The card management team needed a tool and a procedure for securely accessing the smart cards Administrator PIN so that users could reset their User PINs. While users were required to apply private User PINs to their cards prior to using them for remote access for the first time, the card management team applied a unique, securityenhanced Administrator PIN on each card distributed at Microsoft to insure the security of the smart card infrastructure. The Administrator PINs are unique to each card and controlled by the Microsoft IT Security team. PINs are managed through a combination of a back-end database and a securityenhanced hardware security module (HSM), a cryptographic box used for storing private keys. Properly accessing the Administrator PIN on the card is critical. If a person fails to enter the correct Administrator PIN five times prior to entering a correct pin, the smart card operating system permanently destroys the smart card chip, rendering it useless and unsalvageable. However, failing to enter the User PIN five times in a row simply locks the card from further use. When a user blocks their PIN, the card must be unblocked. In order to unblock a smart card, client computers are equipped with custom-built smart card utilities that include a tool that can unblock a card if the correct admin response code is entered. The response code can be retrieved with the assistance of Helpdesk. Helpdesk employs a specialized tool developed by the card management team. A temporary Administrator PIN can be created by running a special algorithm that uses information such as the locked smart cards serial number, the user account name assigned to that card, the current date and time, and the private key held within the HSM to hash an Administrator PIN unique to that card. The valid Administrator PIN issued by Helpdesk remains valid for the challenge phrase generated. If the card is removed from the reader, a new challenge code is needed. The response code from a previous challenge phrase would not be valid. If the Administrator PIN was retrieved and entered correctly, a new user PIN can be created. On the occasion that the Helpdesk team is unable to resolve an ongoing smart card issue, the problem is escalated to the card management team for second- and third-tier support. The card management team recently developed an end-user, self-help PIN unblock tool and made it available to authenticated end users as a download from the Microsoft extranet Web site (which requires Microsoft employees to enter their normal network logon credentials for access). This tool helped to greatly reduce the number of Helpdesk calls related to smart cards. In the early stages of adoption, smart card issues accounted for an average of 17 to 20 percent of all Helpdesk calls. Technology adoption and education efforts have reduced the overall call volume by approximately 2 percent every six months to a standing level of approximately 10 to 12 percent of calls, although infrastructure, renewal, and other issues still cause occasional spikes of up to 20 percent.
Page 31
Access Management Security Team

After the smart card deployment process was complete, the Microsoft IT card management team (who managed remote access to the corporate network) and Corporate Securitys building access security team (who managed physical access to buildings and the RFID cardkey infrastructure) were merged to become the Access Management Security team. The Access Management Security team, managed by Corporate Security, was responsible for all aspects of smart card management and end user support after Helpdesk. They covered technical problems with the smart card portion of the card as well as problems with the RFID badge element used by employees to gain access to secured buildings.
Ongoing Maintenance and Operations

The smart card project has begun its transition in Microsoft IT from a deployment project to ongoing maintenance and operations. The Access Management Security team, once a large team bustling with deployment task activity, changed its primary role to a sustaining management focus. The Access Management Security team also was reduced in size as deployment activity ended. It operates on a 24-hour basis, five days a week.
Post-Deployment Responsibilities
After the company-wide smart card deployment was complete, the Access Management Security team began focusing its activity on reviewing open Helpdesk logs (Helpdesk logs are written up for each Helpdesk call received), taking second-tier support call escalations from Helpdesk, and supporting the DIOs when they request new smart card certificates. The post-deployment size of the Access Management Security team dwindled down to approximately nine people covering the needs of the entire company. They provided escalated Helpdesk support and managed the issuance of new smart card certificates for Redmond and for DIOs globally, as needed.
Using Existing Network Security Infrastructure

The smart card solution took advantage of technologies found in the initial Microsoft Windows 2000 Server infrastructure, including Certificate Services, Remote Access, Internet Authentication Service (IAS), and Extensible Authentication Protocol-Transport Layer Security (EAP-TLS) protocol. The Windows 2000 Server infrastructure enabled Microsoft IT to create and issue its own security certificates and manage the process internally without dependence upon an external digital certificate provider partner. The smart card solution was later enhanced when Microsoft IT upgraded its network infrastructure to Windows Server 2003 mid-way through the deployment. The product enhancements to Windows Server 2003 enabled Microsoft IT to better manage certificate auto-renewals, as well as delegate the process of creating and distributing certificates. Through the extensive use of the Certificate Services feature in its own Windows Server 2003 infrastructure, Microsoft now manages one of the largest Windows-based PKIs in the world.
Page 32
RESULTS
Because this project touched every employee and vendor staff person who had been granted remote access authorization, a number that totaled more than 61,000 people, the smart card deployment project had the largest scope of any in Microsoft IT history. The project started as a proof-of-concept experiment using immature technologies from an industry that had many competing and incompatible manufacturers products. The smart card technology itself changed dramatically over the course of the project. When the project began, 4 KB smart cards were the norm. Microsoft initially standardized on 32 KB cards when they were made available and is now in the process of migrating to 128 KB cards. The progressive developments in PKI technology, especially those found in Windows Server 2003 and Windows Server 2008, significantly increased the flexibility of the smart card solution from an administrative point of view. It took a great deal of flexibility and vision on the part of Microsoft IT to build the worlds largest smart card deployment completely from scratch. Most important, however, was the successful attainment of the initial goals Microsoft IT set out for the smart card deployment at Microsoft. These goals focused on increasing the security of the Microsoft corporate network by securing remote access connectivity and minimizing the impact of that result upon the remote access user. The one-time deployment costs at Microsoft for implementing its smart card solution were approximately $70 per user. Building a new card costs approximately $36 per card, including hardware and card issuance. Issuing a certificate costs approximately $0.40 per certificate. Ongoing operational costs include a staff of five security officers and two PKI personnel, as well as hardware to support PKI, and smart card certification authorities. This smart card infrastructure supports building access and remote access logon for approximately 120,000 personnel. It also supports smart cards for the administration of high security systems, such as domain and enterprise administration. Microsoft IT expects to continue to gain value on this investment by expanding its use of smart cards and updating its smart card infrastructure as technologies mature.
Security Gains
The introduction of smart cards and its associated two-factor authentication have augmented the existing security around remote access authentication. This additional layer of security has significantly reduced the risk of network intrusion incidents. If an employee smart card is lost or stolen, it is unlikely that the card could be used by someone else to gain access to the Microsoft corporate network. Each of the following obstacles would need to be overcome by an intruder to use a found smart card to gain unauthorized access to the Microsoft corporate network: In order to gain unauthorized access, a user would need to have physical possession of a smart card and know the smart cards PIN to be able to access the smart cards user certificate. If the unauthorized user entered the incorrect PIN multiple times, tried to forcibly access the contents of the smart cards chip to get the PIN, the smart card would immediately lock and render the contents inaccessible.
Page 33
Minimized Client Impact

The card management team worked hard to minimize the impact of using the smart card upon the remote access authentication experience. The card management team consolidated the user effort required for smart card setup and system configuration. Connection Manager was modified to greatly simplify the smart card remote access connection. Microsoft worked with reader device manufacturers and enhanced the performance of their device drivers. The card management team tested several card readers and the best performers were approved for Microsoft purchase. Additionally, after testing commercially available CSPs and finding them to be unsatisfactory, Microsoft developed its own CSP, which enhanced smart card reliability, certificate security, and greatly improved overall performance. Even with the strong emphasis on performance, adding smart card validation to remote access logons added time to the process of gaining remote access to the corporate network. However, efforts were made to minimize the amount of that added time. The total amount of time added to the entire authentication process is typically less than 25 seconds. After authentication, the smart card is no longer needed and subsequent remote network performance is unaffected. With the smart cards, there is some user inconvenience with a delay in logon of between five and 20-25 seconds; however, the benefit of asking users to wait for that extra time greatly outweighs the cost. Microsoft now has greatly enhanced security for all network assets and the data contained within thanks to the use of smart cards for remote access.
Updating the Card Infrastructure

Smart cards are a technology that is still maturing and being improved. Microsoft IT has continued to update its cards to keep up with this process. As of this writing, the older smart cards are being phased out and new cards are being issued. The changes in the newer cards are described in Table 3. Table 3. Upgraded Elements of the Upgraded Microsoft IT Smart Card Solution
Component Smart card Client software Server software Features
RFID Badge card with 128 KB of RAM in chip .NET Frameworkbased operating system New Windows XPbased CSP New smart card user management tool for managing PINs
New smart card life cycle management tools
Page 34
Figure 3 shows the memory usage in the new .NET-based 128 KB smart card that is now in use at Microsoft. The new card contains approximately 86 KB of free space that can be used for certificates, keys, applications, files, and data. Currently at Microsoft, each certificate is approximately 2.5 KB in size.
Free Space
86 KB
Card Module Interface 128 KB Card Module Code Softmask / System (.NET Framework )
1 KB 11 KB
File System Space 98 KB
Operating System Space 30 KB Figure 3. Memory usage in the new Microsoft IT smart card configuration
Page 35
LESSONS LEARNED
The Microsoft IT card management team learned many lessons as the smart card project evolved from a research project through pilot to full rollout into production.
Product Lessons
Some of the lessons the card management team learned from the smart card deployment process were pertinent to the products associated with the project, existing computer issues, and problems with some third-party technology services.
Smart Card Selection

Smart card manufacturers continue to quickly add new features to their products; including more processing power and added memory space (64 KB cards are now available). Standardizing on one model of smart card during a long-term, enterprise-wide, testing and deployment project was a challenge as the technologies continued to develop so quickly. Determining their specific needs and choosing a platform that met those needs helped the card management team successfully deploy their smart card solution.
Card Operating System Extensibility

Microsoft IT employed smart cards primarily to enhance the security of remote access to the Microsoft corporate network. However, the extensibility of the solution was an appealing factor for future internal application development. Microsoft IT recommends choosing a solution that can grow as the needs of a business using it grows.
Mobile Devices
Users of mobile Personal Digital Assistant (PDA) devices, such as Pocket PCs or Smartphones, were no longer able to gain remote access to the corporate network after their user accounts in Active Directory were converted to requiring smart cards. Current generation mobile devices do not support the required EAP-TLS protocol. In addition, getting card reader devices and their associated device drivers to connect to and work on mobile device processor platforms would have been a significant challenge as well.
Computer Operating Systems

Home users equipped with Macintosh, UNIX, and Linux computers were also no longer able to gain remote access to the Microsoft corporate network, once smart cards were required, because those systems lacked support for the required version of the EAP-TLS protocol. Employees in the Microsoft Macintosh products development group who needed remote access privileges had to be given permanent exceptions to the smart card requirement.
Home Computers
Microsoft IT recognized that it was not in a position nor did it wish to manage the personal home computer equipment of Microsoft employees. For employee home computers that could not run Windows XP, Microsoft IT offered, through its existing Microsoft Exchange Server 2003 infrastructure, the alternative of using Microsoft Office Outlook Web Access for Internet access without the need of a smart card, limited only to their corporate e-mail, tasks, contacts, and calendar functions. All that was required for Office Outlook Web Access was access to the World Wide Web and a browser that supported Hypertext Transport Protocol Secure (HTTPS). Office Outlook Web Access allowed employees basic access to their Exchange Server data without directly accessing the corporate network.
Page 36
Integrated Services Digital Network (ISDN)

The card management team discovered that there were very limited numbers of ISDN device manufacturers that supported EAP-TLS with bonded channels (the combining of two ISDN lines into one for better performance). A number of employees using ISDN devices to remotely connect to the Microsoft corporate network faced a potentially significant reduction in ISDN performance when employing the EAP-TLS and smart card remote access solution. ISDN users were encouraged to check their ISDN devices manufacturers Web site to see whether they supported EAP-TLS.
Removal of Expired Certificates from the User Store

If a user loses his or her smart card that has already been used at least once for remote network authentication, the authentication certificate will be cached on that computer in the user's personal store. When that certificate reaches expiration, Active Directory will cause the user's computer to prompt the user to insert the smart card for an auto-renewal of the certificate. Because the card has been lost, the old certificate cannot be used to sign the new certificate, so renewal is not possible. However, the user presumably has been granted a new smart card with a new authentication certificate during the interim. At this point, the user has two authentication certificates. Microsoft IT uses the customized Connection Manager script to check for and remove all older, duplicate certificates of the same type located in the user's store.
Deployment Process Lessons

The card management team also uncovered many lessons about how to effectively and efficiently roll out a smart card project to an entire enterprise.
Planning
The card management team determined at the outset the capabilities of smart cards as well as the deployment goals of the project, such as why they were being deployed, how they could benefit the business, where smart card benefits could save money and time, and how the project planners anticipated employing the technology within the coming 12-24 months. Once those capabilities and goals were defined, the card management team recognized that it was best to design the whole project around that knowledge. The card management team also benefited from having staff well trained in PKI technologies. Microsoft IT recommends that if you do not have such expertise in-house, you should work with a third-party consultant unaffiliated with the solution vendor. Choose someone who has expertise in smart cards during the planning phase to be sure you properly cover all the issues that need to be considered, especially security. Microsoft IT also recommends carefully considering network bandwidth constraints before modifying such core IT services as remote access. Networks may not have been designed with the new services in mind, so the risk of business disruption must be considered. At Microsoft, deploying smart card technology with its reliance upon new security protocols and authentication certificates, the Microsoft corporate network bandwidth was not significantly affected.
Choosing a PKI Provider

The question of who would provide PKI services was critical to the success of the card management teams smart card deployment. The card management team considered
Page 37
whether it made better business sense to self-host or contract out to a third party its PKI needs. Two key factors were consideredthe number of certificates the enterprise planned to use and the types of applications to enable with digital certificates. At Microsoft, Microsoft IT already had a robust PKI in place, based on its Windows Server 2003based network. Microsoft IT used certificates for everything from remote access to code signing and security-enhanced e-mail. Contracting third-party PKI hosting was determined to be cost prohibitive and less flexible, especially because a ready infrastructure already existed at Microsoft.
Maintaining Security
The card management team chose to use delegated distribution outside of Redmond to optimize the needs of system security and responsive local support. This allowed the creation of certificates to be tightly managed while the distribution of each smart card was delivered to all users in person, the most secure method to validate a card recipients identity.
Running Pilots
The card management team learned that it is most efficient to use the same technologies in the pilots as those that will be deployed to larger groups. The card management team resisted the temptation to migrate to more advanced smart card technologies between the pilot and full-scale to avoid unanticipated issues. Microsoft IT recommends starting with a pilot project in a small, controlled area. When the first pilot is successfully completed, if the size of the eventual rollout is expected to be quite large, conduct a second pilot to a larger, but still closely monitored, group of users. Once scaling issues have been identified and considered, then begin the rollout to the rest of the organization, as resources and time permit.
Using Trained Personnel for Physical Distribution

Having well-trained security personnel involved with the smart card distribution process helped the card management team manage new user questions and concerns. It also helped maintain the security of the entire process. Having an activation station at distribution events made it possible for users to take care of the entire smart card setup process at one time, further easing concerns on the part of new users and reducing later support calls.
Scripting Installation
The card management team was aware that not every Microsoft employee would be comfortable with getting a handful of new computer hardware and software and working through the installation and configuration process. The card management team worked hard to simplify the whole installation process. Automating the software installation process reduced employee frustration as well as Helpdesk support costs.
Communicating with Users

The card management team actively managed employee education and communications, setting expectations early and managing feedback. The card management team sent announcement e-mail messages early to users to be converted, allowing for reasonable exception planning. Reminders e-mail messages were sent as well. Special project mailbox accounts were set up in Exchange Server and staff members were dedicated to managing the feedback and user requests they received. Intranet and extranet Web sites were developed, providing software downloads and additional support information. During the
Page 38
communication process, "out-of-office" responses may indicate that a user requires special arrangements to receive their smart card.
Handling Exception Management

The card management team recognized that smart cards were not a solution that would likely cover 100 percent of its user population. There would always be exceptions to standardization rules, such as users of non-compatible hardware (such as Macintoshes or wireless mobile devices). As an adjunct to clear communications with end users, the card management team considered the exceptions that would be allowed and how it would manage those exceptions. The card management team determined that it would work for the 90+ percent solution and narrowly define allowable exceptions, which were more easily managed and monitored. Once the allowed exceptions were defined, the card management team communicated with end users about the smart card usage policy and the approved exceptions. Timeframes were defined. These were communicated to affected end users for postponed deployments with hard deadlines set for loss of remote access privileges. Maintaining strict adherence to the card management team's policies and limiting the number and circumstances for exceptions was vital for ensuring the security benefits sought by the smart card deployment project were not compromised. To minimize exceptions, Microsoft IT provided alternative network access methodologies, such as Office Outlook Web Access, Outlook Mobile Access, and Microsoft Exchange ActiveSync, all mobile access features of Exchange Server 2003, for users of hardware that does not support EAP-TLS, such as Macintosh computers and Pocket PC devices.
Page 39
OTHER
ITEMS AND
FUTURE CONSIDERATIONS
The domestic smart card industry in the United States is still maturing, with many small businesses offering systems that do not interoperate with one another. Industry experts predict that as the smart card industry matures, an industry-wide consolidation will likely take place within the next 12-24 months. Improved product standards and better standardization will be derived from this expected consolidation, not just at the programmatic (API or CSP) level, but including even better plug-and-play compatibility. This will also include continued improvements in smart card integration with the Windows platform.
New Tools
The Windows product development team at Microsoft is working on improving the interoperability issues with smart cards. Typically, when a customer goes to a smart card products and services vendor today, the smart card solution offered is highly proprietary. The vendor's card management tool set is only compatible with the specific smart card chip and their selected card operating system used in their solution. Microsoft is developing a base CSP and a smart card platform module that can be used by any smart card manufacturer. Building solutions based on this new platform will ensure that the platform will be compatible with a Windows-based server and client environment, regardless of the chip and card operating system used. In addition, Microsoft-built smart card management tools will work with all card solutions equally well, providing another step toward the goal of "best-of-breed" smart card solution functionality. A key feature of the Microsoft base CSP is that it will be the only CSP available that supports the security-enhanced recovery of encryption keys on smart cards.
Application Support
Support for applications is another ideal project for smart card use. Plans such as signing stock grants, securing financial or human resources data, signing source code, gaining access to secured source depots and corporate network assets, are all ideas currently being tested or at least under consideration for expanding the role of smart cards within Microsoft.
Elimination of Passwords
Another goal is the addition of the root certificate onto smart cards. Because these certificates have not been on smart cards in the past, bootstrap issues such as joining the domain using smart card credentials have been a challenge. With the addition of a root certificate on a smart card, this and many other problems will be resolved, and will enable Microsoft to move to an environment where all passwords (one-factor authentication) are eliminated in favor of using smart cards with PINs (two-factor authentication).
New Technologies
Newer smart cards are regularly arriving in the market place today with greater features, capacity, and power. Of specific interest to the card management team is the development of contactless smart cards, where persistent authentication is the norm. Microsoft IT is currently planning how it will leverage these product improvements, over and above their existing roles, for greater integration into the Windows-based enterprise network environment and specific applications used to drive business at Microsoft.
Page 40
Strengthening Account Management

Microsoft IT has implemented the use of smart cards to securely manage accounts with elevated privileges. Microsoft IT has implemented a policy that will lock down those accounts and their use of elevated privileges to the holder of a smart card with a mapped certificate installed. This will minimize the ability for the account to be compromised as well as improve the audit trail for use of the elevated privileges.
Providing for Other Future Uses

In contrast to other examined technologies that are typically singular in application, the smart card offers additional potential benefits for further application development. Their extensible, open platform and secured memory contents can be used for a variety of useful corporate programs. For example, smart cards could be used for:
Personal payment systems, such as debit funds for a corporate cafeteria meal card or tracking employee company store purchase allocations. Root store certificates. Multiple logon certificates. Checking in/checking out source code. Encrypting File System (EFS) certificates.
Page 41
CONCLUSION
There is a new focus on security for both corporations and governments worldwide. With the steadily increasing security threats to corporate network assets, Microsoft sought to implement a two-factor authentication security solution for remote access. Smart card technology offered several advantages over competing two-factor security technologies. It was a security solution that was not burdensome for remote users to employ. It took advantage of the existing Windows Server and PKI infrastructure. Lastly, it presented Microsoft IT with an extensible platform for future internal application development.
Page 42
FOR MORE INFORMATION

For more information about Microsoft products or services, call the Microsoft Sales Information Center at (800) 426-9400. In Canada, call the Microsoft Canada information Centre at (800) 563-9048. Outside the 50 United States and Canada, please contact your local Microsoft subsidiary. To access information through the World Wide Web, go to: http://www.microsoft.com http://www.microsoft.com/itshowcase
The information contained in this document represents the current view of Microsoft Corporation on the issues discussed as of the date of publication. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information presented after the date of publication. This White Paper is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED, OR STATUTORY, AS TO THE INFORMATION IN THIS DOCUMENT. Complying with all applicable copyright laws is the responsibility of the user. Microsoft grants you the right to reproduce this White Paper, in whole or in part, specifically and solely for the purpose of personal education. Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual property rights covering subject matter in this document. Except as expressly provided in any written license agreement from Microsoft, the furnishing of this document does not give you any license to these patents, trademarks, copyrights, or other intellectual property. Unless otherwise noted, the example companies, organizations, products, domain names, e-mail addresses, logos, people, places, and events depicted herein are fictitious, and no association with any real company, organization, product, domain name, email address, logo, person, place, or event is intended or should be inferred. 2008 Microsoft Corporation. All rights reserved. This document is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS OR IMPLIED, IN THIS SUMMARY. Microsoft, Active Directory, ActiveSync, Outlook, Windows, Windows Server, and Windows Vista are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries. The names of actual companies and products mentioned herein may be the trademarks of their respective owners.
Page 43

Smart Card Deployment TWP

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Smart Card Deployment TWP

Uploaded by

Copyright:

Available Formats

Smart Card Deployment at Microsoft

Technical White Paper

Lessons Learned .................................................................................................................38 Product Lessons 38 Deployment Process Lessons 39

Conclusion ...........................................................................................................................44 For More Information...........................................................................................................45

Products & Technologies Windows 2000 Server and

Active Directory directory

Windows-based Public Key

Smart Card Deployment at Microsoft

Smart Card Deployment at Microsoft

IMPROVING REMOTE NETWORK ACCESS SECURITY

Requiring Two-Factor Authentication

Selecting Smart Cards as the Microsoft IT Solution

Smart Card Deployment at Microsoft

Smart Card Deployment at Microsoft

Smart Card Deployment at Microsoft

SMART CARD SOLUTION

Smart Card Deployment at Microsoft

Client hardware Client software

Card and Chip

Smart Card Deployment at Microsoft

Smart Card Operating System

Ease of management Development platform

Smart Card Deployment at Microsoft

Smart Card Security

Smart Card File System and Personalization

Smart Card Deployment at Microsoft

Computer Capable of Running Windows XP

Smart Card Readers

Smart Card Deployment at Microsoft

Cryptographic Service Provider (CSP)

Smart Card Deployment at Microsoft

Smart Card Management Tools

Tools for Card Issuance, Distribution, and Management

Smart Card Deployment at Microsoft

Public Key Infrastructure (PKI)

Smart Card Deployment at Microsoft

Card Management System (CMS)

Smart Card Deployment at Microsoft

Approach and Strategy

Smart Card Deployment at Microsoft

Initial Card Distribution Process, Redmond vs. Rest of World

Card Management Team

Smart Card Deployment at Microsoft

Delegated Issuance Model

User Install and Setup

Training and Support Issues

Smart Card Deployment at Microsoft

Smart Card Deployment at Microsoft

Card Creation Process

Smart Card Deployment at Microsoft

Initial Card Distribution Process

Smart Card Deployment at Microsoft

Communication Considerations for Distribution

Smart Card Deployment at Microsoft

Delegated Issuance Model

Smart Card Deployment at Microsoft

1. User requests smart card from DIO

2. DIO submits request to SO in Redmond

Administration Tools and Issues

Smart Card Deployment at Microsoft

Enrollment Agent (EA)

Delegated Enrollment Agent

User Install and Setup