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:
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 CardsWindows 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 GroupsThe 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 GroupsThe local groups on domain-joined computers have varying levels of administrative rights. These include:
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 GroupsEach domain has a number of default groups that provide administrative functions on domain controllers. These groups include:
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 GroupsIn addition to the default groups, creation of an Active Directory forest sets up the following security groups:
All members of these groups should require smart cards for administration. Require Smart Card for Interactive LogonThere are two ways to require a smart card for interactive logon. You can configure:
In most environments, the most manageable approach is to use Group Policy. User Account PropertiesYou 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 PolicyA 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 ForestsThe 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 ServersComputers 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:
Securing Domain ControllersDomain 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 ServersA 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 ServersThe 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 ServersA 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 ServersYou 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 CardsTo plan the process for the distribution of smart cards for administrators includes the following activities:
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:
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 CardsSmart 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 CardsThe 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 ManagementYour 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 RevocationYou 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 RenewalThe 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 AutoenrollmentCertificate 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 UseAdministrators 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 RequirementsThis section describes the specific issues and requirements Woodgrove National Bank encountered during the design of their solution to secure administrator accounts with smart cards. BackgroundWoodgrove 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 IssuesWoodgrove National Bank has identified the following three business continuity and administrator accountability issues:
Technical IssuesThe Woodgrove National Bank IT department has identified the following technical issues that must be overcome to implement a smart card solution:
Security IssuesThe 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:
Solution RequirementsAfter 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:
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 SolutionAfter 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 ConceptIn 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 PrerequisitesWhen 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 TeamsA 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 TeamEnsure 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:
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 ArchitectureThe implementation of a smart card solution to help secure administrator accounts requires:
Before implementing the solution, Woodgrove National Bank carried out the following procedures:
Woodgrove National Bank IT also implemented solutions to the following challenges:
Smart Cards DistributionPrior 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 ActivationBecause 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 SupportAlthough 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 ManagementWoodgrove 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 RevocationThe 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 RenewalThe 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 SolutionWoodgrove 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 WorksThis section describes the detailed processes that occur during authentication of a smart card logon.
The following figure illustrates this process. 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:
These settings help prevent administrators from sharing smart cards or leaving a server unattended while logged on. Extending the SolutionWoodgrove 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. SummaryUsing 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. | In This Article
|