Secure Access Using Smart Cards Planning Guide

Chapter 3 - Using Smart Cards to Help Secure Administrator Accounts

Published: June 30, 2005 | Updated: May 7, 2007

Microsoft® Windows Server™ 2003 enables organizations to help secure administrative accounts through a set of specific account security features. In addition to the requirement that administrators log on with smart cards, Windows Server 2003 supports smart card authentication with the listed secondary actions:

Create a mapped drive with the net use command.

Use the Secondary Logon service by typing runas at the command prompt.

Install the Active Directory® directory service by using the Active Directory Installation Wizard (which you can access if you type dcpromo at the command prompt).

Log on through Windows Server 2003 Remote Desktop sessions

Log on through Windows Server 2003 Terminal Server sessions

Note: Although Microsoft Windows® 2000 supports smart card access for authentication, it does not support these additional features, which are available in Windows Server 2003 only.

On This Page
Approaches to Securing Administrator Accounts with Smart CardsApproaches to Securing Administrator Accounts with Smart Cards
Issues and RequirementsIssues and Requirements
Designing the SolutionDesigning the Solution

Approaches to Securing Administrator Accounts with Smart Cards

Windows Server 2003 support for smart card authentication of secondary actions enables better segregation of user and administrator accounts. For everyday actions, administrators can log on to workstations with non-administrative accounts. If they must perform an administrative task, administrators can use their smart cards to authenticate the action by use of a secondary action. This is a more secure and convenient arrangement than if the administrator is required to enter a user name and a password or required to log off and log on again with an administrator account.

Identification of Administrator Accounts and Groups

The implementation of smart cards for administrators requires that an organization identify the administrator accounts that require two-factor authentication. To perform this step correctly, you must understand the characteristics of the various administrator accounts and groups within Windows XP and Windows Server 2003.

Groups allow administrators to manage several user accounts together. Microsoft Windows NT® and later operating systems include security groups with built-in administrative rights.

These security groups can be local groups (on domain-joined computers such as workstations and member servers) or default groups (on domain controllers). Administrator accounts receive their privileges through membership of one or more of these security groups.

Local Groups

The local groups on domain-joined computers have varying levels of administrative rights. These include:

Administrators. Members of this group have complete control of the local computer. The Administrator user account is a member of this group by default. If the computer is a member of a domain, the Domain Admins group for that domain is also a member of this group.

Backup Operators (all computer types). Members of this group can bypass NTFS file system permissions to back up files and folders. Backup Operators can also shut down member servers.

Power Users. Members of this group have limited administrative rights over resources on a local workstation or member server. They can also shut down a member server.

Print Operators. Members of this group can manage print servers, printers, and print jobs. They can also shut down a member server.

For a full description of the default groups in Windows Server 2003 see the Default Local Groups topic at www.microsoft.com/resources/documentation/WindowsServ/2003/standard/proddocs/en-us/lsm_local_groups.asp.

Your organizational security policies should define which members of the Administrators, Server Operators, and Power Users groups require smart cards for logon and administration.

Default Groups

Each domain has a number of default groups that provide administrative functions on domain controllers. These groups include:

Administrators. Members of this group have complete administrative control over domain controllers. The Administrator account and the Domain Admins group are members of this group by default.

Backup Operators. Members of this group can bypass NTFS file system permissions to back up files and folders. Backup Operators can also log on locally and shut down domain controllers.

Server Operators. This group has limited administrative rights on domain controllers, similar to Power Users on workstations. Server operators can log on locally and shut down domain controllers.

Print Operators. Members of this group manage print servers, printers, and print jobs. They can also log on locally and shut down domain controllers.

Account Operators. Members of this group have limited rights to manage user accounts and groups. They can log on interactively but cannot shut down domain controllers.

For more information about default groups, see the Default groups topic at http://go.microsoft.com/fwlink/?LinkId=81737.

Your organization policies should specify that all members of these groups require smart cards for administration.

Domain and Forest Default Groups

In addition to the default groups, creation of an Active Directory forest sets up the following security groups:

Domain Admins. Members of this group have complete control over all objects in the domain. Each subsequent domain in the forest also has a Domain Admins group.

Enterprise Admins (forest root domain only). Members of this group have complete control of all objects in the forest.

Schema Admins (forest root domain only). Members of this group can create classes and attributes in the schema, as well as manage the schema operations master.

Note: To increase security, keep membership of these three groups to a minimum.

All members of these groups should require smart cards for administration.

Require Smart Card for Interactive Logon

There are two ways to require a smart card for interactive logon. You can configure:

User account properties in Active Directory Users and Computers.

Group Policy for specific computers or for groups of specific computers.

In most environments, the most manageable approach is to use Group Policy.

User Account Properties    

You can configure any user account to require a smart card for interactive logon. To do this, in Active Directory Users and Computers, double-click the user, click the Account tab, under Account Options, select the Smart card is required for interactive logon under Account Options check box. The selection of this option changes the user's password to a random complex value and sets the property Password never expires. If you then turn off the smart card requirement, you must also reset the user's password.

Because setting the smart card requirement resets the user's password to an unknown value, the user can no longer use a user name and password combination to log on to the domain. Hence, the user cannot log on to programs such as Microsoft Outlook® Web Access for Microsoft Exchange Server 2003 with a user name and password.

You could use a script to enable this setting during enrollment. However, this method requires you to develop suitable scripts that can enable and disable the smart card requirement for selected individuals.

With the user account smart card requirement selected, the administrator must use a smart card to log on interactively to any computer in the domain, not just the protected servers. This could be inconvenient if not all computers have smart card readers.

If you enforce smart card use through the user account properties, administrators cannot remotely administer computers that run Windows 2000 Server. Windows 2000 Server Terminal Services sessions don't support smart card redirection, so the administrator must log on locally to manage any computers that run Windows 2000. This requirement could be very inconvenient if the administrator is at a different location from the server.

Group Policy

A more manageable approach is to use Group Policy settings to specify that certain computers require smart cards for interactive logon, and to control what happens when a user removes a smart card. You can create Group Policy objects (GPOs) with these settings configured and link the GPOs to the organizational unit (OU) that contains the computer for which you require smart card logon. The path to the smart cards options in Group Policy is Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options. The settings are Interactive logon: Require smart card and Interactive Logon: Smart card removal behavior.

Note: This setting requires either Windows XP with Service Pack 2 or an update for this setting. For more information, see the Update for the "interactive logon: require smart card" security setting in Windows XP Knowledge Base article at http://support.microsoft.com/?id=834875.

For greatest security, you should require smart cards for interactive logon and then set the smart card removal policy to lock the workstation or log off the user. These Group Policy settings should become part of a customized GPO that applies to administrators. GPOs can apply to the site, domain, or OU level. In most cases, GPOs that apply smart card settings apply to an OU.

Note: Microsoft recommends that you not modify the Default Domain Controllers Policy or the Default Domain Policy to include smart card settings or any other policy changes. Always create a new GPO or use a GPO that exists to set Group Policy settings for smart card logon.

The Group Policy settings for smart cards control interactive logon and do not affect access to a server across the network. Interactive logon includes logging on with Remote Desktop or Terminal Services.

Microsoft recommends that you implement smart cards for administrators with other control mechanisms such as IPsec or Group Policy settings to prevent the management of a server with remote administration tools such as Microsoft Management Console (MMC) tools.

Managing Smart Card Access in Multiple Domains and Forests

The implementation of smart cards for administrators requires that you understand the issues involved with multiple domains and forests. For example, administrators who are members of the Domain Admins group in more than one forest might need one smart card for each forest in which they have administrative rights. This requirement can result in these administrators having to carry several smart cards.

Although smart cards can contain more than one certificate, Windows Server 2003 currently can only accept one smart card logon certificate (the certificate held in slot 0 on the smart card) for each certification authority (CA) certificate root. This constraint might require some network administrators to carry multiple smart cards unless the organization has trust relationships between forests.

Securing Servers

Computers that run services, such as file and print, databases, e-mail, and directories, require higher levels of security than workstations. In particular, you should consider the use of smart card authentication for all accounts that administer computers that have the following roles:

Domain controllers

Database servers

Certificate servers

File and print servers

Securing Domain Controllers

Domain controllers are the most important computers for the use of two-factor authentication, because these computers contain and control all of the domain account information and apply security rules to each account. If an attacker compromises a domain controller, the attacker could then create a new account, escalate privileges, or access all domain controllers as an administrator.

Securing Database Servers

A database server stores information that is critical to the operation of an organization. This stored information might be subject to strict check-in and check-out processes, with audit tracking of data access requests. Examples of database servers include servers that store the source code for a software company, the secret recipes of a beverage manufacturer, or customer account information. Smart card authentication should secure access to all database servers.

An organization should identify high security servers, and work with their owners to change the type of account on which the service or scheduled task runs, or place the accounts and servers into special security groups that have greater access and user restrictions.

Securing Certificate Servers

The servers that host certification authorities and Certificate Services must have a high level of security. The compromise of the certification authority voids the integrity of the organization, rendering all issued certificates as insecure. Servers that host Certificate Services must have the highest security priority both from the network and for physical access.

Securing File and Print Servers

A file server can host important company documents and confidential information. The compromise of this information could harm future revenues or incur penalties from regulatory organizations. Smart card authentication must definitely secure print servers that print invoices or bank checks.

For more information about the security features in Windows Server 2003, see the Windows Server 2003 Security Guide at http://go.microsoft.com/fwlink/?LinkId=14845

Installing Smart Card Readers on Servers

You must attach a smart card reader to every server on which Group Policy requires smart cards for interactive logon. Most rack-mounted computers have USB ports at the back that are suitable for use with smart card readers. You can then place the smart card reader at the front of the rack for user access. It is important to label the smart card readers clearly, so that administrators know which reader belongs to which server.

If an administrator has to log on to another server, he must remove his smart card from the first reader and insert it into the reader attached to the other computer. This inconvenience makes the administration of servers with Remote Desktop significantly more attractive.

Distributing Smart Cards

To plan the process for the distribution of smart cards for administrators includes the following activities:

Create suitable groups for smart cards distribution.

Appoint security officers who can act as enrollment agents.

Select a suitable method for the transportation of the cards.

Carry out rigorous identification checks.

You should create a staging security group that contains the selected administrator accounts. You also require a security group to contain the activated accounts. Part of the enrollment process involves that the administrator accounts move from the staging group to the activated group.

The distribution process requires appointment of security officers. These security officers can then:

Deliver the smart cards to the enrollment station.

Act as enrollment agents.

Carry out identification checks.

The identification checks must be rigorous. Administrators should be personally verified by the security officer against a suitable identity document such as a passport or driver's license, and their identity confirmed by their line manager.

Organizations should also do background checks on their administrators. These checks are particularly important in the financial sectors, or for any organization that is subject to regulatory requirements. For more information about background security checks on administrators, see The Security Monitoring and Attack Detection Planning Guide at http://go.microsoft.com/fwlink/?LinkId=41309.

Activating Smart Cards

Smart card activation should take place in a secure location, such as the office used to issue passes that allow access to premises. The security officer sets up an enrollment station with two smart card readers and logs on with his smart card.

After the security officer confirms the administrator's identity, he makes a certificate request for that user account. He opens a new smart card and installs the requested certificate. The security officer then moves the administrator account from the pending group to the activated group. Finally, he writes down the serial number of the card before he hands over the card to the administrator.

The administrator then uses the PIN reset tool to reset the default PIN or uses the PIN unblock tool in conjunction with the Activation Web server to set a new PIN. The administrator's smart card is now ready for use.

Managing Smart Cards

The implementation of smart cards is not a one-time action, because the security certificates embedded on the cards require management and you must cope with situations in which administrators forget their smart cards, lose them, or have them stolen. You should establish applicable procedures and an appropriate budget for smart card management.

Exceptions Management

Your organization needs to develop a plan that focuses on how to manage situations in which administrator smart cards are forgotten, lost, or stolen. How your organization implements the plan depends on how smart card logon requirements are enforced in your organization.

If your organization has chosen to enforce a smart card logon requirement through user accounts in Active Directory, you can easily grant an exception to the affected user in such a situation. The method for granting the exception would be to remove the requirement for smart card logon for the account, and then reset the password after ensuring that the User must change password at next logon setting is enabled. You could then provide the password to the account owner, and after a reasonable period, re-enable the requirement. To apply this method, in Active Directory Users and Computers, double-click the user name, click the Account tab, and then under Account Options, clear the check box for Smart card is required for interactive logon and select the check box for User must change password at next logon. Click OK, and then from the context menu, right-click the user name and select Reset Password to set the password and enforce these requirements for the administrator.

If your organization uses Group Policy to enforce the smart card logon requirement, there is no way to create an exception for a user at this time. In this case, you will have to determine a policy appropriate for your organization that administrators can follow in the event that they forget or lose their smart cards.

In the case of forgotten smart cards, you can implement a number of responses. For example, a policy might require administrators to return home to retrieve misplaced smart cards.

If your organization outsources its smart card infrastructure, you could implement a policy that requires an administrator to maintain a few generic smart cards with certificates tied to specific user accounts on site. If a user loses a smart card, an administrator could temporarily issue one of these generic smart cards to the user with the understanding that the user is responsible for any actions taken to access resources with the generic account. In such a policy, it is recommended that the administrator who maintains the generic smart cards reset the password PIN on the smart card each time prior to issuing it to a user.

If your organization maintains its own smart card infrastructure, you could issue a new certificate with a short lifespan to a generic user account. Under this exceptions management method, the administrator would again be accountable for using the generic account to access resources.

Finally, when an administrator loses a smart card, your organization should institute a policy to issue a new smart card to the administrator, and revoke the administrator's old certificate.

Certificate Revocation

You might have to revoke a certificate under a number of circumstances, for example, on compromise of the private key, if the smart card user changes assignments, or when the user leaves the organization. When you revoke a certificate, this action publishes details about the certificate to the certificate revocation list (CRL) location. This location is typically a URL or a network UNC path.

An issued certificate includes a list of distribution points where an authentication server can verify the status of the certificate against the CRL. For more information about certificate revocation, see the Revoking certificates and publishing CRLs topic at www.microsoft.com/resources/documentation/WindowsServ/2003/standard/proddocs/en-us/sag_CS_SrvAdCRL.asp.

Certificate Renewal

The expiration date of the digital certificate on a smart card depends on the settings in the certificate template that creates the smart card certificate. Certificates for smart card use have typical lifetimes from six months to two years.

When a certificate comes towards the end of its lifetime, it requires renewal to ensure that the owner can continue to use the certificate or replace it. In certificate renewal, the renewal requester already owns a certificate. The renewal takes the information of the current certificate into account when the renewal request is submitted. You can then renew a certificate with a new key or use the current key.

Certificate Autoenrollment

Certificate autoenrollment is feature of Windows Server 2003, Enterprise Edition Certificate Services that automatically signs a renewal request using the existing certificate to obtain a new certificate. This feature helps in the management of large numbers of certificates. For more information about certificate autoenrollment, see Certificate Autoenrollment in Windows Server 2003, at http://go.microsoft.com/fwlink/?LinkId=69027.

Monitoring Smart Card Use

Administrators use smart card – enabled accounts when they perform highly privileged operations, such as server restarts, the management of user accounts, and the configuration of file permissions. Malicious or poorly trained administrators have significant potential to damage your network infrastructure. Hence, you should monitor your security logs to record when administrators log on and log off with their smart cards.

Enterprise management tools such as Microsoft Operations Manager (MOM) 2005 that can monitor and evaluate security event logs are suitable for monitoring smart card use. For more information about how to monitor security event logs, see The Security Monitoring and Attack Detection Planning Guide at http://go.microsoft.com/fwlink/?LinkId=41309.

Issues and Requirements

This section describes the specific issues and requirements Woodgrove National Bank encountered during the design of their solution to secure administrator accounts with smart cards.

Background

Woodgrove National Bank possesses a number of critical servers that require tight administrative control and secure access. Administrators currently authenticate to these critical servers by using a user name and password combination. Unauthorized users have attempted to access critical servers with stolen credentials.

Business Issues

Woodgrove National Bank has identified the following three business continuity and administrator accountability issues:

Accountability. The IT department cannot verify critical changes to servers by administrators who use user name and password authentication because administrators often share credentials.

Protection of credentials. Malicious or rogue users who steal administrators' credentials can seriously affect the reputation of the organization and generate financial costs through downtime. Smart card authentication would significantly reduce the possibility of theft of administrator credentials.

Business continuity. Because Woodgrove National Bank cannot allow changes to network configuration to disrupt business services, a carefully planned approach is essential during the implementation phase of the smart card solution.

Technical Issues

The Woodgrove National Bank IT department has identified the following technical issues that must be overcome to implement a smart card solution:

Support for smart card readers. Every server that administrators need to access with a smart card must provide hardware support for a smart card reader.

Implement operational best practices. The integrity of a smart card deployment is dependent upon effective long-term management and maintenance. Woodgrove National Bank IT should implement the operational best practices outlined by the Microsoft Operations Framework (MOF).

Scheduled tasks that run with administrator rights on a smart card-restricted server. Woodgrove National Bank runs scheduled tasks that use accounts with administrator-level privileges. Woodgrove National Bank needs to review these accounts and, where possible, use accounts that do not require administrative privileges. Woodgrove National Bank must also implement a permanent exclusion group that includes any accounts that run scheduled tasks so that these accounts are exempt from the requirement for smart card logon.

Integration with UNIX. Woodgrove National Bank operates a heterogeneous environment, so smart card integration with computers that run UNIX is a concern. Woodgrove National Bank plans to investigate products such as TrustBroker from CyberSafe Limited that provide integrated smart card authentication for both Windows and UNIX.

Security Issues

The goal of using smart cards to help secure administrator accounts is to improve security and accountability. The Woodgrove National Bank IT department has identified the following security issues that the bank must address before they can deploy the solution:

Distribution and activation. The distribution and activation of the smart cards is important to maintain the integrity of the entire solution. Because Woodgrove National Bank has sites throughout the world, Woodgrove IT cannot distribute smart cards from a single source location. Verification of smart card recipients is a key factor to maintain the integrity of the project. Woodgrove National Bank plans to deploy security teams that use Human Resources identification data to ensure that they issue each smart card to the correct person.

Least-privilege approach to administrative rights. Woodgrove National Bank should examine its current network administration model and reduce the number of user and service accounts that run with full administrative privileges. The bank should assign only those privileges that administrators require to do their jobs. The analysis and reduction in the number of administrator accounts can help in the deployment, monitoring, and continued management of the smart card solution.

Management of service accounts. Woodgrove IT reviewed program service accounts and has ensured that as few services as possible require administrator security context. Many programs are marked for either upgrades or replacement.

One smart card for each forest in a full trust relationship. Woodgrove National Bank has two forests linked by a two-way trust relationship. Although a smart card can hold multiple certificates, Windows Server 2003 only uses the certificate located in slot 0 of the smart card for interactive logon. This design requires network administrators who work across multiple unlinked forests to have multiple smart cards. However, an administrator with a smart card has access to resources in all forests with which the forest that authenticates the administrator has a full trust relationship, unless a security restriction in the trusting forest overrides this access.

PIN management. The security and integrity of the smart card solution increases if users can easily change their PINs. Hence, Woodgrove National Bank IT department acquired suitable PIN management tools from the selected smart card vendor.

Solution Requirements

After the review of the initial pilot, Woodgrove IT developed specific solution requirements. The solution employed by Woodgrove National Bank to help secure administrator accounts that have smart cards must:

Ensure that secured servers require a valid smart card for an interactive, secondary, or Remote Desktop logon.

Distribute and activate smart cards in a secure and timely manner.

Provide an audit of the access to secure servers, and collect the resultant security data in a central repository.

Enable management and monitoring of smart card use.

Ensure rapid revocation of compromised certificates, such as on lost or stolen smart cards.

Provide a structure for ongoing management.

Woodgrove National Bank has identified several key business, technical, and security issues that emerged from the initial plan. Woodgrove IT performed a review to address these issues and conducted tests of workarounds and fixes. Woodgrove National Bank has created detailed plans for the deployment phase of the solution.

Designing the Solution

After you understand the business, technical, and security issues that the smart card solution must address, you can design a solution that suits your environment. The design process identifies the essential elements and logically analyzes the requirements to plan the solution.

Woodgrove National Bank has carried out this appraisal. This section describes the issues from the initial plan that Woodgrove National Bank system architects considered, the conclusions they reached, and the design decisions that they made.

This section outlines the design choices made by Woodgrove National Bank IT to help secure administrator accounts by the use of smart cards. It details the solution concept and its prerequisites and describes the architecture that Woodgrove National Bank planned.

Solution Concept

In the proposed solution, all server administration activity requires authentication of the administrator's identity by the presentation of a certificate stored on a smart card and its corresponding PIN. The solution uses a combination of Group Policy settings, X.509 version 3 (v3) user certificates, smart cards, and smart card readers. The solution requires the installation of an X.509 v3 certificate onto the smart card.

To log on to a server, the administrator inserts the smart card into a smart card reader installed on the computer. The insertion of the card causes the operating system to display a prompt for the PIN. The administrator then enters the PIN for the smart card. If the PIN is correct, the administrator can access the server with administrative rights.

Solution Prerequisites

When you engage in a project of this nature, it is necessary to meet a number of prerequisites. These prerequisites include the recruitment of the project team, consultation with the user base, the implementation of tests or pilots, and the need to upgrade the hardware and software to meet the solution requirements.

Consulting Administrative Teams

A key consideration when a changing a user service is to consult the users and groups involved. In return, the users must understand what they can expect and not expect from the service. Mutual consultation and the management of user expectations is often the key to user acceptance. Measurable objectives must be set to judge the ultimate success of the project in a rational manner. These objectives might include the reduction of security-related incidents associated with stolen credentials.

Woodgrove National Bank operates in several countries/regions throughout the world, and uses regional support centers. The initial design team extensively canvassed administrative teams in all locations to identify candidate servers for the smart card solution. The team also identified any servers that they would not be able to upgrade to meet the solution prerequisites within an acceptable timescale.

Recruitment of the Project Team

Ensure that you have the right personnel and skills to implement a project of this nature. The project team is likely to require input from the following representative occupations:

Program manager

Information systems architect

Systems analyst or integrator

Systems engineers

Product release manager

Product testing manager

Support or help desk manager

User support specialists

Security officers

For more information about representative occupations and MOF role associations, see The Microsoft Solutions Framework Supplemental Whitepapers – IT Occupation Taxonomy at www.microsoft.com/downloads/details.aspx?FamilyID=839058c3-d998-4700-b958-3bedfee2c053

If you do not have certain skills available in-house, you must recruit additional personnel. Because the project typically does not require all personnel at all stages, you must determine individual availability throughout the duration of the project.

Solution Architecture

The implementation of a smart card solution to help secure administrator accounts requires:

Active Directory

Group Policy

Windows Server 2003, Enterprise Edition, Public Key Infrastructure (PKI)

That servers that run Windows Server 2003 have smart card readers

Enrollment stations

Personalization of smart cards

PIN management tools

Before implementing the solution, Woodgrove National Bank carried out the following procedures:

Upgraded certificate services to Windows Server 2003, Enterprise Edition or later.

Upgraded all managed servers to Windows Server 2003 to support interactive logon that uses Terminal Services. This requirement depends upon application compatibility.

Customized smart card certificate user templates and set appropriate permissions.

Created and testd Group Policy objects (GPOs) for smart card enforcement, temporary exclusions, and permanent exclusions.

Woodgrove National Bank IT also implemented solutions to the following challenges:

Distribution of smart cards

Activation of smart cards

Management and support of smart cards

Management of exceptions

Smart Cards Distribution

Prior to smart card distribution, Woodgrove National Bank IT department placed its administrators in an Active Directory staging security group. A team of security officers was required to verify the identities of the administrators and to distribute the smart cards. After an administrator received his card, the IT department moved that person from the staging group to the smart card user group. The administrator then has access to the activation Web server to activate his smart card and change the PIN.

Smart Cards Activation

Because administrators received their smart cards in a pending state, the cards require activation prior to use. The administrator activates his smart card when he inserts the card into a smart card reader, enters a challenge, and then changes the PIN.

Smart Cards Management and Support

Although the administrators at Woodgrove National Bank are a technically astute group, the smart card deployment team needed to work closely with help desk. Help desk personnel required suitable instruction so that they could handle any queries that arose.

Exception Management

Woodgrove National Bank instituted a corporate policy to cope with lost, stolen, or forgotten cards. For lost or stolen cards, the IT department revokes all assigned certificates and issues new cards within 24 hours. The IT department deals with administrators who forget to bring their smart cards to work by issuing them temporary smart cards. Although a certificate might be revoked, it does not mean the smart card is deactivated during that same time. Woodgrove must review the CRL policies to match the security policies.

Certificate Revocation

The smart card logon certificates for Woodgrove National Bank administrators use intranet URLs to locate the CRL and check for revoked certificates. The IT department implemented Windows Network Load Balancing (NLB) to ensure high availability for the Web site that hosts the CRL.

Certificate Renewal

The Woodgrove National Bank IT department developed a certificate renewal process that requires the administrator's manager to approve the smart card renewal request. After the manager approves a request, the current certificate signs the certificate request and the smart card certificate is renewed.

Monitoring the Solution

Woodgrove National Bank uses Microsoft Operations Manager (MOM) 2005 to collect and analyze security event logs and to monitor the solution availability and performance. The smart card solution integrates with MOM, monitors security event logs, and provides alerts and produces usage reports. Woodgrove National Bank plans to review the service on a quarterly basis and to generate reports from the MOM data.

How the Solution Works

This section describes the detailed processes that occur during authentication of a smart card logon.

1.

An administrator inserts a smart card into the smart card reader attached to a computer and the Microsoft Graphical Identification and Authentication DLL (MSGINA) and the computer prompts the user to enter a PIN.

2.

MSGINA passes the PIN to the Local Security Authority (LSA) and the computer uses the PIN to access the smart card.

3.

The client-side Kerberos package reads the X.509 v3 certificate and private key from the administrator's smart card.

4.

The Kerberos package sends an authentication service request to the Key Distribution Center (KDC) service that runs on a domain controller, to request authentication and a Ticket Granting Ticket (TGT). The authentication service request consists of a Privilege Attribute Certificate (PAC), which lists the user's security identifier (SID), the SIDs of any group of which the user is a member, and a request for the Ticket Granting Service (TGS) together with pre-authentication data.

5.

The KDC verifies the certification path of the user’s certificate to ensure that the certificate is from a trusted source. The KDC uses CryptoAPI to build a certification path from the administrator's certificate to a root CA certificate that resides in the root store on the domain controller. The KDC then uses CryptoAPI to verify the digital signature on the authenticator that was included as signed data in the pre-authentication data fields. The domain controller verifies the signature and uses the public key from the administrator's certificate to prove that the request originated from the owner of the public key. The KDC also verifies that the issuer is trusted and appears in the NTAUTH certificate store.

6.

The KDC service retrieves user account information from Active Directory based on the user principal name (UPN) specified in the Subject Alternative Name field in the administrator's certificate. The KDC constructs a TGT from the user account information that it retrieves from Active Directory. The TGT includes the administrator's security identifier (SID), the SIDs for any domain groups to which the administrator belongs, and (in a multidomain environment), the SIDs for any universal groups of which the user is a member. The TGT’s authorization data fields include the list of SIDs.

Note: A SID is a security identifier that is created for each user or group, at the time a user account or a group account is created within either the local security accounts database on Windows NT or higher computers, or within Active Directory. The SID never alters even if the user or group account is renamed

7.

The domain controller returns the TGT to the client. Either the client or the card decrypts the TGT and uses its private key to obtain the KDC secret key. This depends on the type of card or certificate used.

8.

The client validates the reply from the KDC. It first verifies the KDC’s signature by the construction of a certification path from the KDC’s certificate to a trusted root CA and then uses the KDC’s public key to verify the reply signature.

The following figure illustrates this process.

Figure 3.1 Smart card logon authentication process

Figure 3.1 Smart card logon authentication process
See full-sized image

Woodgrove National Bank IT linked a GPO to the organizational units that contain the servers that require smart card authentication. This GPO applies the changes to the following computer configuration settings:

Interactive logon requires a smart card

Removal of the smart card forces the account to log off

These settings help prevent administrators from sharing smart cards or leaving a server unattended while logged on.

Extending the Solution

Woodgrove National Bank envisions integration of the smart card solution into the server and application change management process. The plan is to authenticate each stage of the change management process, and integrate this process into the workflow. For example, changes to the Woodgrove Web server would require verification from two or more Web administrators.

Summary

Using smart cards to authenticate administrator user accounts reduces fraudulent access to critical computers and increases the integrity and accountability of server administration. The implementation of smart cards for administrators will benefit your organization by the reduction of security incidents and the increased quality of administrative procedures.


**
**