Windows XP Pro SP2 User's Guide 3.0

Windows XP Professional with SP2 Evaluated Configuration Users Guide
Version 3.0 July 11, 2007
Prepared For:
Microsoft Corporation Corporate Headquarters One Microsoft Way Redmond, WA 98052-6399
Prepared By: Science Applications International Corporation Common Criteria Testing Laboratory 7125 Columbia Gateway Drive, Suite 300 Columbia, MD 21046
Windows XP Professional SP2 Evaluated Configuration Users Guide
Version 3.0, 07/11/2007
This is a preliminary document and may be changed substantially prior to final commercial release of the software described herein. 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 document is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS OR IMPLIED, AS TO THE INFORMATION IN THIS DOCUMENT. Complying with all applicable copyright laws is the responsibility of the user. This work is licensed under the Creative Commons AttributionNoDerivs-NonCommercial License (which allows redistribution of the work). To view a copy of this license, visit http://creativecommons.org/licenses/by-nd-nc/1.0/ or send a letter to Creative Commons, 559 Nathan Abbott Way, Stanford, California 94305, USA. 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. The example companies, organizations, products, people and events depicted herein are fictitious. No association with any real company, organization, product, person or event is intended or should be inferred. Copyright 2008 Microsoft Corporation. All rights reserved. Microsoft, Active Directory, Visual Basic, Visual Studio, Windows, the Windows logo, Windows NT, and Windows Server 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.
Version 3.0, 07/11/2007
Windows XP Professional with SP2 Evaluated Configuration Users Guide

Version 3.0, 07/11/2007 1. INTRODUCTION ......................................................................................................................... 1 AUDIENCE ASSUMPTIONS ............................................................................................................... 1 DOCUMENT OVERVIEW ................................................................................................................... 1 CONVENTIONS................................................................................................................................ 1 2. WINDOWS XP PROFESSIONAL EVALUATED CONFIGURATION ........................................ 2 SYSTEM REQUIREMENTS ................................................................................................................ 2 Hardware .................................................................................................................................. 2 Software ................................................................................................................................... 3 3. USING WINDOWS XP PROFESSIONAL IN A SECURE MANNER ......................................... 4 OPERATING ENVIRONMENT ............................................................................................................. 4 Organizational Security Policies ............................................................................................... 4 Secure Usage Assumptions ..................................................................................................... 5 Connectivity Assumptions ........................................................................................................ 5 Personnel Assumptions ............................................................................................................ 6 Physical Assumptions .............................................................................................................. 7 SECURITY OVERVIEW ...................................................................................................................... 7 USER AND GROUP ACCOUNTS ........................................................................................................ 8 SECURITY FUNCTIONS .................................................................................................................. 11 Passwords .............................................................................................................................. 11 Creating Strong Passwords ................................................................................................ 12 Changing a Password ......................................................................................................... 12 Mandatory Password Changes........................................................................................... 13 Password Reset .................................................................................................................. 14 User Initiated Password Change ........................................................................................ 15 Computer Access ................................................................................................................... 16 Logging on with a User Account Name and Password ...................................................... 16 User Account Locked due to Invalid Password Attempts ................................................... 17 Logging on to a Computer with a Smart Card .................................................................... 17 Changing the Smart Card PIN ............................................................................................ 19 Logging Off ......................................................................................................................... 21 Shutdown Computer ........................................................................................................... 21 Restart Computer ............................................................................................................... 22
Copyright 2008 Microsoft Corporation. All Rights Reserved. i
Version 3.0, 07/11/2007
Disk Quotas ............................................................................................................................ 22 Exceeding Disk Quota Limits .............................................................................................. 23 Data Protection ....................................................................................................................... 24 Password Protected Screen Locks ..................................................................................... 24 Implementing a Password Protected Screen Saver ........................................................... 24 Initiating a Screen Lock ...................................................................................................... 25 Unlocking the Computer Screen ......................................................................................... 26 Setting Access Controls on Files, Folders, and Other System Objects ............................. 26 Copying vs. Moving ............................................................................................................ 27 File Permissions ................................................................................................................. 28 Folder Permissions ............................................................................................................. 28 Selecting Where to Apply Permissions ............................................................................... 29 Setting or Modifying Permissions ....................................................................................... 31 How Inheritance affects File and Folder Permissions ........................................................ 34 Shared Folder Permissions ................................................................................................ 36 Default Share Permissions ................................................................................................. 37 How Shared Folder Permissions are Applied ..................................................................... 38 Sharing Folders .................................................................................................................. 39 Mapping a Network Share .................................................................................................. 39 Encrypting File System in Windows XP Professional ............................................................ 40 EFS Enhancements in Windows XP Professional ............................................................. 40 Components of EFS ........................................................................................................... 41 Maintaining File Confidentiality ........................................................................................... 42 Encrypting a File or Folder.................................................................................................. 42 Obtaining EFS Certificates ................................................................................................. 43 Import EFS Certificates ....................................................................................................... 44 Request an EFS Certificate from a CA within a Domain .................................................... 46 Granting Local Users Authorization to Open Encrypted Files ............................................ 48 Granting Domain Users Authorization to Open Encrypted Files ........................................ 50 Revocation Checking .......................................................................................................... 54 Removing a Users Authorization to Open an Encrypted File ............................................ 55 Decrypting Files and Folders .............................................................................................. 56 Copying an Encrypted Folder or File .................................................................................. 57 Moving or Renaming an Encrypted Folder or File .............................................................. 58 Deleting an Encrypted Folder or File .................................................................................. 58 System Folders and Files ................................................................................................... 58 Encryption and Local Password Resets on Windows XP .................................................. 58
Copyright 2008 Microsoft Corporation. All Rights Reserved. ii
Version 3.0, 07/11/2007
Restoring Files to a Different Computer ............................................................................. 59 Folder and File Encryption on a Remote Server ................................................................ 64 Web Distributed Authoring and Versioning (WebDAV) ...................................................... 64 WebDAV Clients ................................................................................................................. 64 Connecting to a WebDAV Directory ................................................................................... 65 Remote EFS Operations on File Shares and Web Folders (WebDAV folders) ................. 69 Remote EFS Operations in a Web Folder Environment ..................................................... 69 Remote Encryption of Files on Web Folders ...................................................................... 70 Remote Decryption of Files on Web Folders ...................................................................... 70 File Copy from a Web Folder .............................................................................................. 70 Certificates and Certification Authorities ................................................................................ 70 Certificate Uses .................................................................................................................. 72 Certificate Stores ................................................................................................................ 73 CA Trust .............................................................................................................................. 75 Requesting Certificates from a Windows Server 2003 Certificate Server ............................. 77 Requesting Certificates ....................................................................................................... 77 Processing of Certificate Requests .................................................................................... 78 ADFS Enabled Web Applications ........................................................................................... 97 Configuring the Web Browser for Accessing ADFS-enabled Web Applications .................... 97 Using Federated Web Applications ........................................................................................ 98 Configuring the Web Browser for Accessing ADFS-enabled Web Applications .................... 99 Using Federated Web Applications ........................................................................................ 99 Types of ADFS-aware Web applications ............................................................................. 100 Accessing ADFS-enabled Sample Web Applications from the Account Realm: Federated Web SSO Scenario ........................................................................................................... 100 Accessing ADFS-enabled Web Applications from within the Resource Realm: Federated Web SSO Scenario ........................................................................................................... 103 Accessing ADFS-enabled Web Applications: Web SSO Scenario .................................. 104 Troubleshooting ADFS-enabled Application Failures .......................................................... 105 4. ACRONYMS ............................................................................................................................ 106 5. REFERENCES ........................................................................................................................ 108
Copyright 2008 Microsoft Corporation. All Rights Reserved. iii
Version 3.0, 07/11/2007
1. Introduction
Welcome to the Windows XP Professional with SP2 Evaluated Configuration Users Guide, Version 3.0. The Microsoft Windows 2003, XP Professional and XP Embedded Security Target, defines the requirements for the Windows Server 2003 and XP Professional Common Criteria Evaluation (Version 3.0) and is henceforth referred to in this document as the Windows 2003/XP V3 ST. Windows XP Professional was evaluated against the Windows 2003/XP V3 ST and found to satisfy the ST requirements. This document provides sufficient guidance for Windows XP Professional users to securely use the product in accordance with the requirements stated in the Windows 2003/XP V3 ST. This document is specifically targeted at the non-administrative (e.g. non-privileged) user of Windows XP Professional.
Audience Assumptions
This document assumes the audience is generally familiar with Windows XP Professional with Service Pack 2.
Document Overview
This document has the following chapters: Chapter 1, Introduction, introduces the purpose and structure of the document and the as sumptions of the audience. Chapter 2, Windows XP Professional Evaluation Configuration, describes the evaluated configuration. Chapter 3, Using Windows XP Professional in a Secure Manner, describes the environment of the evaluation configuration, an overview of the security functions, an overview of user and group accounts, and a description of how to use the security functions of Windows XP Professional. It also provides users with a brief description of digital certificate and provides procedures for making certificate requests and verifying the certificates. Chapter 4, Acronyms Chapter 5, References
Conventions
Throughout the document, the following conventions are followed: Warnings: Actions that have critical security ramifications. Warnings are identified with the bolded word Warning (e.g. Warning). Evaluation Note: Conditions that are specific to the Evaluated Configuration that the user should be aware of. Evaluation Notes are identified with the bolded words Evaluation Note (e.g. Evaluation Note). Note: Text that is important for the user to take notice of is identified with the bolded word Note (e.g. Note).
Copyright 2008 Microsoft Corporation. All Rights Reserved. 1
Version 3.0, 07/11/2007
2. Windows XP Professional Evaluated Configuration

The primary focus of this section is to describe the concept of an Evaluated Configuration. This section does NOT give instruction of how to install and configure the Windows XP Professional to be in the evaluated configuration. Such instruction is provided in the Windows XP Professional Security Configuration Guide. This section introduces the notion of an Evaluated Configuration so the administrator is aware of potential consequences if the system is not in the proper configuration, and specifies the hardware and software requirements. The Target of Evaluation (TOE) includes a homogenous set of Windows XP Professional systems that can be connected via their network interfaces and may be organized as domain or workgroup members. Within the TOE, a domain is a logical collection of Windows XP Professional and Windows Server 2003 systems that allows the administration and application of a common security policy and the use of a common accounts database. Domains use established trust relationships to share account information and validate the rights and permissions of users. A user with one account in one domain can be granted access to resources on any server or workstation on the network. Each domain must include at least one designated server known as a Domain Controller (DC) to manage the domain. A workgroup is a logical grouping of networked computers that share resources, such as files and printers. A workgroup is sometimes referred to as a peer-to-peer network because all computers in the workgroup can share resources as equals, without a dedicated server. Each Windows XP Professional computer in a workgroup maintains its own local security database, which contains a list of user accounts and resource security information specific to that computer. Each Windows XP Professional system, whether it is a domain member, workgroup member, or a standalone computer, is part of the TOE and provides a subset of the TOE Security Functions (TSFs). The TSF for Windows XP Professional can consist of the security functions from a single system (in the case of a stand-alone system) or the collection of security functions from an entire network of systems (in the case of domain or workgroup configurations).
System Requirements
This section describes the minimum system requirements for the evaluated configuration.
Hardware
Physically, each Windows XP Professional system in the Evaluated Configuration consists of a computer with a 32-bit (x86) or 64-bit (x64) processor (including Intel Pentium and Xeon, as well as AMD Opteron families). A set of devices may be attached and they are listed as follows: Display Monitor, Keyboard, Mouse, Floppy Disk Drive, Compact DiskRead Only Memory (CD-ROM) Drive, Fixed Disk Drives, Printer, USB Smart Card Reader,
Version 3.0, 07/11/2007
Audio Adaptor, and Network Adaptor.
The TOE does not include any physical network components between network adaptors of a connection. The ST assumes that any network connections, equipment, and cables are appropriately protected in the TOE security environment.
Software
Windows XP Professional is a workstation operating system. Windows XP Professional is suited for business desktops and notebook computers. The security features addressed by the ST are those provided by Windows XP Professional as an operating system.
Version 3.0, 07/11/2007
3. Using Windows XP Professional in a Secure Manner

This section describes the security environment of Windows XP Professional in the evaluated configuration and how to use the Windows XP Professional security functions. Evaluation Note: Users should ensure that they each uphold the Secure Usage Assumptions related to users.
Operating Environment
The security environment of the Evaluated Configuration of Windows XP Professional is described in the Windows 2003/XP V3 ST and identifies the threats to be countered by Windows XP Professional, the organizational security policies, and the usage assumptions as they relate to Windows XP Professional. The assumptions and policies are primarily derived from the Controlled Access Protection Profile (CAPP); while the threats were introduced in the Windows 2003/XP V3 ST have been introduced to better represent specific threats addressed by Windows XP Professional. The administrator should ensure that the environment meets the organizational policies and assumptions. They are repeated below from the ST.
Organizational Security Policies

Table 3-1 describes organizational security policies that are addressed by Windows XP Professional.
Version 3.0, 07/11/2007
Table 3-1 Organizational Security Policies

Security Policy P.ACCOUNTABILITY P.AUTHORIZED_USERS Description The users of the system shall be held accountable for their actions within the system. Only those users who have been authorized access to information within the system may access the system. The system must limit the access to, modification of, and destruction of the information in protected resources to those authorized users which have a "need to know" for that information. The system must have the ability to limit the extent of each user's authorizations. The system must have the ability to protect system data in transmission between distributed parts of the protected system The system must have the ability to warn users regarding the unauthorized use of the system. PP Source CAPP CAPP
P.NEED_TO_KNOW
CAPP
P.AUTHORIZATION P-ADD-IPSEC
P.WARN
Secure Usage Assumptions

This section describes the security aspects of the environment in which Windows XP Professional is intended to be used. This includes assumptions about the connectivity, personnel, and physical aspects of the environment. Windows XP Professional is assured to provide effective security measures in the defined environment only if it is installed, managed, and used correctly. The operational environment must be managed in accordance with the user and administrator guidance.
Connectivity Assumptions
Windows XP Professional is a distributed system connected via network media. It is assumed that the following connectivity conditions will exist.
Version 3.0, 07/11/2007
Table 3-2 Connectivity Assumptions

Assumption A.CONNECT Description All connections to peripheral devices reside within the controlled access facilities. The TOE only addresses security concerns related to the manipulation of the TOE through its authorized access points. Internal communication paths to access points such as terminals are assumed to be adequately protected. Any other systems with which the TOE communicates are assumed to be under the same management control and operate under the same security policy constraints. The TOE is applicable to networked or distributed environments only if the entire network operates under the same constraints and resides within a single management domain. There are no security requirements that address the need to trust external systems or the communications links to such systems. PP Source CAPP
A.PEER
CAPP
Personnel Assumptions
It is assumed that the following personnel conditions will exist. Table 3-3 Personnel Assumptions
Assumption A.COOP Description Authorized users possess the necessary authorization to access at least some of the information management by the TOE and are expected to act in a cooperating manner in a benign environment. There will be one or more competent individuals assigned to manage the TOE and the security of the information it contains. The system administrative personnel are not careless, willfully negligent, or hostile, and will follow and abide by the instructions provided by the administrator documentation. PP Source CAPP
A.MANAGE
CAPP
A.NO_EVIL_ADM
CAPP
Evaluation Note: The user must adhere to A.COOP as described in the above table.
Version 3.0, 07/11/2007
Physical Assumptions
Windows XP Professional is intended for application in user areas that have physical control and monitoring. It is assumed that the following physical conditions will exist. Table 3-4 Physical Assumptions
Assumption A.LOCATE Description The processing resources of the TOE will be located within controlled access facilities that will prevent unauthorized physical access. The TOE hardware and software critical to security policy enforcement will be protected from unauthorized physical modification. PP Source CAPP
A.PROTECT
CAPP
Security overview
It is important to keep a computer system secure, not only to protect data on the computer itself, but on the network as well. A good security system confirms the identity of the people who are attempting to access the resources on a computer, protects specific resources from inappropriate access by users, and provides a simple, efficient way to set up and maintain security on the computer. To help accomplish these goals, Windows XP Professional offers these security features: User Accounts: To use a computer that is running Windows XP Professional, users must have a valid account, established by an authorized administrator, which consists of a unique user name and a password. Windows XP Professional verifies the user name and password when the user presses CTRL+ALT+DEL and then types his/her user name and password. If the user account has been disabled or deleted, Windows XP Professional prevents the user from accessing the computer, ensuring that only valid users have access to the computer. Group Accounts: Users must have certain user rights and permissions to perform tasks on a computer running Windows XP Professional. Group accounts help to efficiently assign those user rights and permissions to users. Windows XP Professional comes with many built-in groups based on the tasks users commonly perform, such as the Administrators, Backup Operators, or Users groups. Assigning users to one or more of the built-in groups gives most users all of the user rights and permissions they need to perform their jobs. Only authorized domain administrators can add members to Domain groups. Only members of the local Administrators group can add and modify group membership on the local workstation. Members of the Power Users group can create users and groups, but can only modify accounts that were created by the specific member of the Power Users group. Encryption (New Technology File System (NTFS) drives only): Encrypting files and folders makes them unreadable to unauthorized users. If a user attempting to access an encrypted file has the private key to that file (that is, if the user either encrypted the file personally, has been granted access to the file by the owner, or is a registered recovery agent), the user will be able to open the file and work with it transparently as a normal document. A user without the private key to the file is denied access. Encryption is available only on NTFS formatted drives. File and Folder Permissions (NTFS drives only): When permissions are set on a file or folder, the owner specifies the groups and users whose access is to be restricted or allowed, and then selects the type of access. It is more efficient to specify group accounts when assigning permissions to objects, so that users can simply be added to the appropriate group to allow or restrict access for those users. For example, managers can be given Full Control of a folder that contains electronic timesheets, and employees can be given Write access so that they can copy timesheets to that folder, but not read the contents of the folder. File and folder permissions can be set only on NTFS drives.
Version 3.0, 07/11/2007
Share Folder Permissions: Members of the Administrators or Power Users group can share folders on a local computer so that users on other computers can access those folders. By assigning shared folder permissions to any NTFS, File Allocation Table (FAT), or FAT32 shared folder, authorized administrators can restrict or allow access to those folders over the network. In addition to share permissions, NTFS folder permissions can be used if the shared folder is located on an NTFS drive. NTFS permissions are effective on the local computer and over the network. Printer Permissions: Because shared printers are available to all users on the network, administrators might want to limit access for some users by assigning printer permissions. For example, all non-administrative users in a department could be given Print permission and all managers the Print and Manage Documents permissions. By doing this, all users and managers can print documents, but managers can change the status of any print job submitted by any user. Auditing: Authorized administrators can use auditing to track which user account was used to access files or other objects, as well as logon attempts, system shutdowns or restarts, and similar events. Before any auditing takes place, the administrator must use Group Policy to specify the types of events that are to be audited. For example, to audit a folder, Audit Object Access must first be enabled in the Auditing policy in Group Policy. Next, the administrator sets up auditing in the same fashion as permissions for files and folders. User Rights: User rights are rules that determine the actions a user can perform on a computer. In addition, user rights control whether a user can log on to a computer directly (locally) or over the network, add users to local groups, delete users, and so on. Built-in groups have sets of user rights already assigned. Authorized administrators usually assign user rights by adding a user account to one of the built-in groups or by creating a new group and assigning specific user rights to that group. Users who are subsequently added to a group are automatically granted all user rights assigned to the group account. User rights are managed using a Group Policy. Group Policy: Group Policies are used to set a variety of software, computer, and user policies. For example, an authorized administrator can define the various components of the user's desktop environment, such as the programs that are available to users, the icons that appear on the user's desktop, the Start menu options, which users can modify their desktops and which cannot, and so on. Group Policy is also used to set user rights. A subcomponent of Group Policy in Windows XP Professional is Security Settings, which provides options for configuring system security and is also directly accessible via the Local Security Policy interface.
User and Group Accounts

The default security settings for Windows XP Professional can be described by summarizing the permissions granted to default user and group accounts as well as special groups. Administrator: The default Administrator account has full control over the computer's software, contents, and settings. Only authorized administrators should log on as Administrator. The account can be used to perform tasks such as creating user accounts, installing software, or making any changes that need to be available to all users. Note: As a best security practice, the default Administrator account should not be used for day-to-day administration and should only be used in the event of an emergency. Instead, authorized administrators should log on with a user account that has been added to the Administrators group. The use of individual user accounts by administrators supports requirements for accountability. Guest: Default user account available to allow anonymous access to the computer and resources. It is disabled by default.
Version 3.0, 07/11/2007
Evaluation Note: The Windows XP Professional with SP2 Security Configuration Guide, Version 3.0 (Appendix D: User and Group Accounts) instructs the administrator to disable the guest account in the Evaluated Configuration. Help Assistant (identified as HelpAssistant): Account used by remote help desk personnel to logon to a computer during the Remote Assistance session. It is disabled by default. Evaluation Note: The Windows XP Professional with SP2 Security Configuration Guide, Version 3.0 (Appendix D: User and Group Accounts) instructs the administrator to keep the Help Assistant account disabled in the Evaluated Configuration. SUPPORT_388945a0: Account used to control access to signed scripts that are accessible from within Help and Support Services. Administrators can use this account to delegate the ability for an ordinary user who does not have administrative access over a computer, and to run signed scripts from links embedded within Help and Support Services. It is disabled by default. Evaluation Note: The Windows XP Professional with SP2 Security Configuration Guide, Version 3.0 (Appendix D: User and Group Accounts) instructs the administrator to keep the SUPPORT_388945a0 account disabled in the Evaluated Configuration. Administrators: Members of the Administrators group can perform all functions supported by the operating system. Administrators are able to grant themselves any rights that they do not have by default. Ideally, administrative access should only be used to: Install the operating system and components (such as hardware drivers, system services, and so on). Install Service Packs and Patches. Upgrade the operating system. Repair the operating system. Configure critical operating system parameters (such as password policy, access control, audit policy, kernel mode driver configuration, and so on). Take ownership of files that have become inaccessible. Manage the security and auditing logs. Back up and restore the system. Manage user and group accounts. Backup Operators: Members of the Backup Operators group can back up and restore files on the computer, regardless of any permission that protect those files. They can also log on to the computer and shut it down, but they cannot change security settings. Evaluation Note: The Windows XP Professional with SP2 Security Configuration Guide, Version 3.0 (Appendix D: User and Group Accounts) instructs the administrator to not add non-administrative accounts to the Backup Operators group. Guests: The Guests group offers limited access to resources on the system. By default, members of the Guests group are denied access to the application and system event logs. They also cannot make permanent changes to their desktop environment. Otherwise, members of the Guests group have the same access rights as members of the Users group. This allows occasional or one-time users to log on to a workstation's built-in Guest account and be granted limited abilities. The Guest user account is disabled by default.
Version 3.0, 07/11/2007
Evaluation Note: The Windows XP Professional with SP2 Security Configuration Guide, Version 3.0 (Appendix D: User and Group Accounts) instructs the administrator to not add any accounts to the Guests group. Help Services Group (identified as HelpServicesGroup): Members of this group can use helper applications to diagnose system problems. This group, in conjunction with the SUPPORT_388945a0 and Help Assistant accounts, can be used by members of Microsoft Help and Support Center to access the computer from the network and to log on locally. Evaluation Note: The Windows XP Professional with SP2 Security Configuration Guide, Version 3.0 (Appendix D: User and Group Accounts) instructs the administrator to not add any accounts to Help Services Group. Network Configuration Operators: Members of this group have limited administrative privileges that allow them to configure networking features, such as Internet Protocol (IP) address assignment. Evaluation Note: The Windows XP Professional with SP2 Security Configuration Guide, Version 3.0 (Appendix D: User and Group Accounts) instructs the administrator to not add non-administrative accounts to the Network Configuration Operators group. Power Users: Members of the Power Users group have more permissions than members of the Users group and fewer than members of the Administrators group. Power Users can perform any operating system task except tasks reserved for the Administrators group. Power Users can: Run legacy applications in addition to Windows XP Professional certified applications. Install programs that do not modify operating system files or install system services. Customize system-wide resources including Printers, Date/Time, Power Options, and other Control Panel resources. Create and manage local user accounts and groups. Stop and start system services that are not started by default.
Power Users do not have permission to add themselves to the Administrators group. Power Users do not have access to the data of other users on an NTFS volume, unless those users grant them permission. Evaluation Note: The Windows XP Professional with SP2 Security Configuration Guide, Version 3.0 (Appendix D: User and Group Accounts) instructs the administrator to not add non-administrative accounts to the Power Users group. Remote Desktop Users: Members of this group have the right to log on remotely. Evaluation Note: The Windows XP Professional with SP2 Security Configuration Guide, Version 3.0 (Appendix D: User and Group Accounts) instructs the administrator to not add any accounts to the Remote Desktop Users group. Replicator: Members can support file replication services in a domain. The replicator service is used to automatically copy files, such as user logon scripts. Evaluation Note: The Windows XP Professional with SP2 Security Configuration Guide, Version 3.0 (Appendix D: User and Group Accounts) instructs the administrator to not add non-administrative accounts to the Replicator group. Users: The Users group provides the most secure environment in which to run programs. On a volume formatted with NTFS, the default security settings on a newly installed system (but not on an upgraded system) are designed to prevent members of this group from compromising the integrity of
Version 3.0, 07/11/2007
the operating system and installed programs. Users cannot modify system-wide registry settings, operating system files, or program files. Users can shut down workstations, but not servers. They can run certified Windows XP Professional programs that have been installed or deployed by administrators. Users have full control over all of their own data files. Users cannot install programs that can be run by other Users (this prevents introduction of Trojan horse programs). They also cannot access other Users' private data or desktop settings. Special Groups: Several additional groups are automatically created by Windows XP Professional: Interactive This group contains the user who is currently logged on to the computer. Network This group contains all users who are currently accessing the system over the network. Terminal Server User When Terminal Servers are installed in application serving mode, this group contains any users who are currently logged on to the system using Terminal Server.
Evaluation Note: The Windows XP Professional with SP2 Security Configuration Guide, Version 3.0 instructs the administrator to not grant resource permissions or user rights to this account.
Security Functions
This section describes how to use the security functions of Windows XP Professional.
Passwords
The security provided by a password system depends on the passwords being kept secret at all times. Thus, a password is vulnerable to compromise whenever it is used, stored, or even known. To ensure security, passwords must be used carefully. These recommendations will help protect passwords: Never write down passwords. Never share passwords with anyone. Never use a network logon password for another purpose. Use different passwords for network logon and the Administrator account on a computer. Change the network password every 60 to 90 days or as dictated by local security policies. Administrators may force periodic password changes through group/domain policies. Change the password immediately if it is believed to have been compromised. Note: Windows XP Professional includes a Forgotten Password Wizard that may be used to create a Password Reset Disk. The evaluated configuration currently does not include the use of the Forgotten Password Wizard and the Password Reset Disk. Be careful about where a password is saved on the computer. Some dialog boxes, such as those for remote access and other telephone connections, present an option to save or remember passwords. Do not select that option.
Version 3.0, 07/11/2007
Creating Strong Passwords Good computer security includes the use of strong passwords for network or local logons. For a password to be strong and hard to break, it should: Be at least eight characters long, Contain characters from each of the following three groups,
Examples A, B, C,...; a, b, c,... 0, 1, 2, 3, 4, 5, 6, 7, 8, 9 `~!@#$%^&*()_+-={}|[]\:";'<>?,./
Description Letters (uppercase and lowercase) Numerals Symbols (all characters not defined as letters or numerals)
Have at least one symbol character in the second through sixth positions, Be significantly different from prior passwords, Not contain the users actual name or user account name, and Not be a common word or name.
Passwords can be the weakest link in a computer security scheme. Strong passwords are important because password-cracking tools continue to improve and the computers used to crack passwords are more powerful. Network passwords that once took weeks to break can now be broken in hours. Password cracking software uses one of three approaches: intelligent guessing, dictionary attacks, and automation that try every possible combination of characters. Given enough time, the automated method can crack any password. However, it still can take months to crack a strong password. Evaluation Note: The Windows XP Professional Evaluated Configuration Administrators Guide document and Windows XP Professional with SP2 Security Configuration Guide, Version 3.0 both instruct the administrator to set the minimum password length to be at least eight (8) characters in the evaluation configuration.
Changing a Password Several methods can be used to initiate password changes: Policies may dictate periodic mandatory password changes, Account passwords may need to be reset by an authorized administrator, and Users may choose to initiate a password change.
Version 3.0, 07/11/2007
Mandatory Password Changes The Windows domain password policy, or the Local Security Policy on a standalone computer, may dictate a maximum password age. A maximum password age determines how long users can keep a password before they have to change it. The aim is to periodically force users to change their passwords. Once a password has expired due to this policy, the user will receive the following message after initiating a login attempt:
The password will need to be changed as follows: 1. Click the OK. 2. The Change Password interface will appear with the old password already filled in.
3. Enter a new password and confirm it by entering it a second time. If the new password does not match the one entered in the Confirm New Password block, a warning message will appear stating that the passwords typed do not match. If the domain policy or Local Security Policy requires the use of strong passwords and has defined password policies addressing issues such as length and history, and a non-conforming password is entered, the following warning message will appear:
Version 3.0, 07/11/2007
For either of the two cases above, reenter and confirm the new password in the proper format needed to conform to policy requirements.
4. A successful password change is verified with the following message:
Password Reset Occasionally, a user may forget a password. If the user is locked out of the computer due to not remembering a password, the only way to recover is to have an authorized administrator reset the user account password. The typical practice when resetting an account password is immediately expire the new password that is provided by the administrator, and require users to enter a new password upon their first logon attempt. This practice helps maintain the secrecy of the user account password by forcing users to create a password that is not known by the administrator. The procedures that must be followed by the user to enter a new password are identical to those described above for mandatory password changes. The message users receive when required to change their passwords at fist logon is shown below.
Version 3.0, 07/11/2007
User Initiated Password Change To initiate a password change: 1. Press CTRL+ALT+DELETE to access the Windows Security interface.
2. Click Change Password. A Change Password interface will appear (old password dialog box is blank). 3. Enter the old password, then enter a new password and confirm it by entering it a second time.
4. A successful password change is verified with the following message:

Version 3.0, 07/11/2007
Computer Access
Logging on with a User Account Name and Password To Log on to the computer: 1. Initiate a trusted path for login by pressing CTRL+ALT+DELETE. 2. If the administrator has implemented a log on banner, a message banner will appear on the screen. Read the message and click OK, or hit <Enter> to continue with the logon process. 3. At the Log On to Windows interface, enter a user name and password. 4. Click on the Options >> button. In the Log on to: drop down box select to either log on to a network Domain Controller or directly to the local computer.
5. Click OK.
Version 3.0, 07/11/2007
User Account Locked due to Invalid Password Attempts If the domain policy or Local Security Policy includes an account lockout threshold, user accounts will be locked immediately after executing the specified number of invalid login attempts. Initial invalid login attempts will be presented to the user in a Logon Message as shown below. By design, the message does not specifically indicate whether it is the password or the user login Identification (ID) that is incorrect.
The final invalid login attempt will inform the user that the account has been locked by presenting the Logon Message shown below. By design, the message does not state whether the account is disabled due to a bad password or a bad login ID.
Account lockouts may be set by policy to remain locked for a set period of time or may be locked indefinitely until an authorized administrator unlocks the account. An authorized administrator must be contacted to unlock user accounts that have been locked indefinitely or that require immediate access.
Logging on to a Computer with a Smart Card To log on to a computer with a smart card, users do not need to type CTRL+ALT+DEL. They simply insert the smart card into the smart card reader and the computer prompts them for their Personal Identification Number (PIN) instead of their user name and password.
Version 3.0, 07/11/2007
Note: Users will need to obtain a smart card from an authorized Smart Card Enrollment Agent, who is responsible for adding user certificates to smart cards on behalf of the users. 1. If the computer is configured to use a smart card, the Welcome to Windows logon interface will show a smart card icon. Insert the smart card into the smart card reader.
2. Type the PIN for the smart card when prompted by the computer. Click OK. Note: The Smart Card Enrollment Agent will provide users with a PIN that can be used for the initial logon. Users should change their PINs immediately after their initial logon with the smart card.
Version 3.0, 07/11/2007
Notes: The Smart Card must be prepared by creating the appropriate credentials before using it to log on to the computer. If the PIN entered is recognized as legitimate, this logs the user on to the computer and to the Windows Server 2003 family domain, based on the permissions assigned to the user account by the domain administrator. If the incorrect PIN is entered for a Smart Card several times in a row, the user will be unable to log on to the computer using that Smart Card. The number of allowable invalid logon attempts before lockout occurs varies according to the Smart card Manufacturer. By default, the Infineon Sicrypt Smart Cards become locked if an incorrect PIN is entered three times in a row. A locked card can only be unlocked by an authorized administrator using the Infineon Sicrypt Cryptographic Service Provider (CSP) Tools and an administrator PIN. If the Smart Card is inserted backwards or upside down, the Smart Card will not work; however, the user may be prompted for a PIN which will not work. Smart Card logons only work for computers that are joined to a domain. If a Domain Controller is not available, the Smart Card logon fails even if the user has previously logged onto the computer using the Smart Card. If the Domain Controller is available but does not have a valid Certificate Revocation List (CRL) for the issuing Certification Authority (CA), then the logon fails.
Changing the Smart Card PIN All users must be required by policy to change the default Smart Card PIN as soon as they receive their Smart Card. Procedures for changing the Smart Card PIN are dependent on Smart Card vendor applications which are outside the TOE. For the Evaluated Configuration, the Sicrypt Smart Card from Infineon Technologies is used. To allow users the capability to change their Smart Card PINs, the Infineon Sicrypt CSP Tools must first be installed on the users computer by an authorized administrator. To change a Smart Card PIN: 1. The Smart Card user logs on to the computer using a regular domain account and password (alternatively, the user may log on using the issued Smart Card with the default PIN). 2. Click Start, point to Infineon SICRYPT CSP Tools, and select SICRYPT Smart Card Admin Tool. 3. The SICRYPT Smart Card Admin Tool interface will appear. Insert the Smart Card into the smart card reader.
Version 3.0, 07/11/2007
4. Click the PIN button. Enter the current PIN number in the PIN entry box, then enter the new PIN in the new PIN box and confirm it by entering it again in the Confirm PIN box. Guidelines for selecting a PIN are as follow: The SICRYPT Smart Card Admin Tool allows the PIN to be set to a minimum of four (4) characters and a maximum of eight (8). For the Evaluated Configuration, PINs must be comprised of eight (8) characters. For strong security, create the PIN by using a mixture of alphabet characters, numbers, and other special characters such as #, @, or $.
5. Click the Change PIN button. A message will appear indicating that the PIN of the signature card has been changed successfully. Click OK.
Version 3.0, 07/11/2007
6. Close the SICRYPT Smart Card Admin Tool interface.
Logging Off To log off from the computer so that someone else can use it: 1. Click Start, and then click Log Off. 2. In the Log Off Windows interface, click the Log off button. This closes all programs, disconnects the computer from the network, and prepares the computer to be used by someone else.
3. Alternatively, users can log off by pressing CTRL+ALT+DELETE, and then clicking the Log Off button on the Windows Security interface.
Shutdown Computer To shut down the computer: 1. Click Start, and then click Shut Down. 2. In the Shut Down Windows interface, select Shut down from the drop-down menu and click OK.
Version 3.0, 07/11/2007
3. After the data is saved, Windows XP Professional notifies the user that it is okay to turn off the computer. Some computers have configurable Basic Input-Output System (BIOS) settings that allow the computer hardware to turn itself off automatically once the operating system shutdown process is completed. 4. The computer can also be shut down by pressing CTRL+ALT+DELETE and clicking the Shut Down button on the Windows Security interface and then selecting Shut down from the drop-down menu of the Shut Down Windows interface.
Restart Computer To restart the computer 1. Click Start, and then click Shut Down. 2. In the Shut Down Windows interface, select Restart from the drop-down menu and click OK.
3. The computer can also be restarted by pressing CTRL+ALT+DELETE, clicking the Shut Down button on the Windows Security interface and then selecting Restart from the drop-down menu of the Shut Down Windows interface.
Disk Quotas
Windows XP Professional disk quotas track and control disk storage usage on a per-user, per-volume basis. Windows XP Professional tracks disk quotas for each volume, even if the volumes are on the same hard disk. Because quotas are tracked on a per-user basis, every users disk space is tracked regardless of the folders in which the user stores files. The following list describes several important characteristics of Windows XP Professional disk quotas.
Version 3.0, 07/11/2007
Windows XP Professional calculates disk space usage for users based on the files and folders they own. When a user copies or saves a file to an NTFS volume or takes ownership of a file on an NTFS volume, Windows XP Professional charges the disk space for the file against the users quota limit. Windows XP Professional ignores compression when it calculates hard disk space usage. Users are charged for each uncompressed byte, regardless of how much hard disk space is actually used. In part, this charge is made because file compression produces different degrees of compression for different types of files. Different file types that are the same size when uncompressed might end up to be very different sizes when they are compressed. When disk quotas is enabled, the free disk space Windows XP Professional reports to applications for the volume is the amount of space remaining within the users disk quota limit. For example, a user whose files occupy 50 MegaBytes (MB) of an assigned disk quota limit of 100MB will show 50MB of free space even if the volume contains several gigabytes of free space.
Authorized administrators can use disk quotas to monitor and control hard disk space usage. Administrators can perform the following tasks: Set a disk quota limit to specify the amount of disk space for each user. Set a disk quota warning to specify when Windows XP Professional should log an event, indicating that the user is nearing his or her limit. Enforce disk quota limits and either deny users access if they exceed their limit or allow them to continue access. Log an event when a user exceeds a specific disk space threshold. For example, a threshold might be when users exceed their quota limit or when they exceed their warning level.
Once disk quotas are enabled for a volume, Windows XP Professional collects disk usage data for all users who own files and folders on the volume. This allows the monitoring of volume usage on a per-user basis. By default, only members of the Administrators group can view and change the quota settings. However, an authorized administrator can allow users to view quota settings.
Exceeding Disk Quota Limits When the administrator selects the Deny disk space to users exceeding quota limit option, users who exceed their quota limit receive an "insufficient disk space" error from Windows XP Professional and cannot write additional data to the volume without first deleting or moving some existing files from it. Individual programs determine their own error handling for this condition. To the program, it appears that the volume is full. Enabling quotas and not limiting disk space use are useful when administrators do not want to deny users access to a volume, but want to track disk space use on a per-user basis. The administrator can also specify whether or not to log an event when users exceed either their quota warning level or their quota limit. When the administrator selects the Log event when a user exceeds their quota limit option, an event is written to the Windows system log on the computer running disk quotas whenever users exceed their quota limit. Administrators can view these events with Event Viewer, filtering for disk event types. When the administrator selects the Log event when a user exceeds their warning level option, an event is written to the Windows system log on the computer running disk quotas whenever users exceed their quota warning level. Administrators can view these events with Event Viewer, filtering for disk event types. Unless a trigger is set to do so, users are not warned of this event. Users who receive indications that they may have exceeded their disk quota should try removing any unnecessary files. Otherwise they should contact the system administrator for assistance.
Version 3.0, 07/11/2007
Data Protection
Information security strategies protect data on servers and client computers, and also conceal and protect packets traversing insecure networks. The organizations distributed security plan needs to identify which information must be protected in the event computer equipment is lost or stolen. Also, types of network traffic that are sensitive or private and need to be protected from network sniffers must be included in the plan. In terms of users on your enterprise network, access control is the primary mechanism to protect sensitive files from unauthorized access. However, the computers themselves might be portable and subject to physical theft. Therefore, access control is not sufficient to protect the data stored on these computers. This is a special problem with laptop computers that can be easily stolen while traveling. Windows XP Professional provides the Encrypting File System (EFS) to address this problem. To protect data on their computers, users should secure individual files and folders and take steps to secure the physical computer itself. If the computer contains sensitive information, it should be kept in a safe location.
Password Protected Screen Locks Users can secure their computers by locking them whenever they are away from their desk and setting up a password-protected screen saver. By pressing CTRL+ALT+DEL and clicking Lock Computer, users can prevent unauthorized access to their computers. Once the computer screen is locked, only the user and members of the Administrators group on the computer can unlock it (it is unlocked by pressing CTRL+ALT+DEL, typing the user password, and then clicking OK). Users can also set up a screen saver so that whenever the computer is idle for more than a specified length of time, the screen saver starts and the computer automatically locks.
Implementing a Password Protected Screen Saver Users may set an automatic screen lock on a workstation by setting screensaver based screen lock as follows: 1. Right-click on the user desktop and select Properties. The Display Properties window will appear. 2. Click on the Screen Saver tab. 3. Select a screen saver from the Screen Saver drop down menu. 4. Enter the number of minutes of inactivity that the system must wait before initiating the screen saver in the Wait: dialog box. The default setting is ten (10) minutes. 5. Select the Password Protected box.
Version 3.0, 07/11/2007
6. Click OK to set the password protected screen saver. Warning: Users must ensure there is no un-intentional pressure (e.g. a book pressing on a key) on the keyboard to allow the screen lock function to work properly. Any pressure on the keyboard will prevent the screen lock from being invoked.
Initiating a Screen Lock A user may manually initiate a screen lock as follows: 1. Simultaneously press the Ctrl-Alt-Del buttons. This will invoke the trusted path function and present the Windows Security interface. 2. Click on the Lock Computer button.
3. This will lock the users desktop, as indicated by the Computer Locked interface.
Version 3.0, 07/11/2007
Unlocking the Computer Screen A user can unlock the screen as follows: 1. Simultaneously press the Ctrl-Alt-Del buttons. This will invoke the trusted path function and present a login interface to unlock the computer.
2. Enter the account name of the currently logged on user and the associated password. 3. Click OK to unlock the computer screen. In the event emergency access is required to a user desktop that has been locked by either a screensaver based password lock or through a user-initiated action, an authorized administrator may unlock the computer.
Setting Access Controls on Files, Folders, and Other System Objects Access control is the process of authorizing users and groups to access objects on the network. Key concepts that make up access control are described below. Least Privilege Principle: A key component of authorization is the least privilege principle, which states that all users should have the least possible amount of systems access or system authorization that still allows them to perform their job functions. Thus, if a user only needs to be able to view a particular file, that user should have read-only access to the file; the user should not be able to write to that file. Ownership of Objects: Windows XP Professional assigns an owner to an object when the object is created. By default, the owner is the creator of the object. Permissions Attached to Objects: The primary means for access control is permissions, or access rights. In Windows systems, permissions can be set on files, folders, and other objects within the system. Permissions allow or deny users and groups particular actions on folder, file, or other system
26
Copyright 2008 Microsoft Corporation. All Rights Reserved.
Version 3.0, 07/11/2007
objects. Permissions are implemented primarily by way of security descriptors, which also define auditing and ownership. Inheritance of Permissions: Windows XP Professional provides a feature for administrators to easily assign and propagate permissions. Known as inheritance, this feature automatically causes objects within a container to inherit the permissions of that container. For example, the files within a folder, when created, inherit the permissions of the folder. Object Managers: If a user needs to change the permissions on an individual object, the user can simply start the appropriate tool and change the properties for that object. For example, to change the permissions on a file, users can start Windows Explorer, browse to find the desired object, rightclick on the file name, and click Properties. The through the Security tab of the Properties interface, the object owner change permissions as needed. Object Auditing: Windows XP Professional allows authorized administrators to audit users access to objects. Authorized administrators can then view these security-related events in the Security log with the Event Viewer.
Copying vs. Moving When using NTFS permissions to secure access to specific files or folders, it is very important to pay close attention to what happens to those permissions whenever the object is moved or copied to another location on the system. When an object is copied into another folder it inherits the access permissions in place at the destination folder. When a file or folder object is moved from one folder to another folder the NTFS permissions that have been applied to the object move with it.
Version 3.0, 07/11/2007
File Permissions File permissions include Full Control, Modify, Read & Execute, Read, and Write. Each of these permissions consists of a logical group of special permissions. The following table lists NTFS file permissions and specifies which special permissions are associated with that permission.
NTFS File Permissions Special Permissions Traverse Folder/Execute File List Folder/Read Data Read Attributes Read Extended Attributes Create Files/Write Data Create Folders/Append Data Write Attributes Write Extended Attributes Delete Read Permissions Change Permissions Take Ownership Full Control Modify Read & Execute Read Write
Warning: Groups or users granted Full Control on a folder can delete any files in that folder regardless of the permissions protecting the file.
Folder Permissions Folder permissions include Full Control, Modify, Read & Execute, List Folder Contents, Read, and Write. Each of these permissions consists of a logical group of special permissions. The following table lists NTFS folder permission and specifies which special permissions are associated with that permission.
Version 3.0, 07/11/2007
Folder Permissions Special Permissions Traverse Folder/Execute File List Folder/Read Data Read Attributes Read Extended Attributes Create Files/Write Data Create Folders/Append Data Write Attributes Write Extended Attributes Delete Subfolders and Files Delete Read Permissions Change Permissions Take Ownership Full Control Modify Read & Execute List Folder Read Contents Write
Although List Folder Contents and Read & Execute appear to have the same special permissions, these permissions are inherited differently. List Folder Contents is inherited by folders but not files, and it should only appear when viewing folder permissions. Read & Execute is inherited by both files and folders and is always present when viewing file or folder permissions.
Selecting Where to Apply Permissions The Permission Entry dialog box appears when setting permissions on files and folders through the Advanced Security Settings interface. In this dialog box, Apply onto lists the locations where permissions can be applied. How these permissions are applied depends on whether the Apply these permissions to objects and/or containers within this container only check box is selected. By default, this check box is clear.
Version 3.0, 07/11/2007
When the Apply these permissions... check box is clear, permissions are applied as shown below:
Applies permissions to current folder Applies permissions to subfolders in current folder Applies permissions to files in current folder Applies permissions to all subsequent subfolders Applies permissions to files in all subsequent subfolders
Apply onto
This folder only The folder, subfolders and files This folder and subfolders This folder and files Subfolders and files only Subfolders only Files only
Version 3.0, 07/11/2007
When the Apply these permissions... check box is selected, permissions are applied as shown below:
Applies permissions to current folder Applies permissions to subfolders in current folder Applies permissions to files in current folder Applies permissions to all subsequent subfolders Applies permissions to files in all subsequent subfolders
Apply onto
This folder only The folder, subfolders and files This folder and subfolders This folder and files Subfolders and files only Subfolders only Files only
Setting or Modifying Permissions To set, view, change, or remove special permissions for files and folders: 1. Open Windows Explorer; click Start, point to All Programs, point to Accessories, and then select Windows Explorer. 2. Navigate Windows Explorer and locate the file or folder for which special permissions are to be set. 3. Right-click the file or folder, click Properties, and then click the Security tab. 4. Click Advanced.
Perform any of the following:
Version 3.0, 07/11/2007
To set special permissions for a new group or user, click Add to open the Select User, Computer, or Group interface. Enter the name of the user or group using the format domainname\name or click the Advanced button, then the Find Now button to select an account name from a list. To access account names from a domain, click the Locations button. There should now be a list that shows the current machine, the local domain, trusted domains, and other resources that can be accessed. Select the local domain to view all the account names in the domain.
Select an account and click OK on the Select User, Computer, or Group interface. If the Advanced feature was used, click OK again in the next Select User, Computer, or Group interface. The Permission Entry dialog box for the selected account will appear.
Set permissions by checking the desired permission check boxes under the Allow column. To explicitly deny an access permission to the account, check the appropriate check box under the Deny column.
Version 3.0, 07/11/2007
Note: Permissions that are explicitly denied will take precedence over all others. Therefore, if the account is a member of a group that is allowed the permission as well as another group that denied the permission on the same object, the effective setting will be to Deny the permission.
To view or change special permissions for an existing group or user, select the name of the account and then click Edit. If the permission settings are not selectable (grayed out), it is because the permissions are inherited from a parent folder. See How inheritance affects file and folder permissions for details. To remove a group or user and its special permissions, select the name of the account and then click Remove. If the Remove button is unavailable, it is because the permissions are inherited from a parent folder. See How inheritance affects file and folder permissions for details on how to make changes to inherited permissions. In the Permission Entry for <account name> dialog box, select where the permissions are to be applied, if necessary, by using the Apply onto drop-down menu. Apply onto is available only for folders. To prevent subfolders and files within the tree from inheriting these permissions, click to select the Apply these permissions to objects and/or containers within this container only check box.
Note: To change permissions, a user must be the owner or have been granted permission to do so by the owner.
Version 3.0, 07/11/2007
Warning: Groups or users granted Full Control for a folder can delete files and subfolders within that folder regardless of the permissions protecting the files and subfolders.
How Inheritance affects File and Folder Permissions After setting permissions on a parent folder, new files and subfolders created in the folder inherit these permissions. If propagation of inherited permissions is not desired, select This folder only in Apply onto when special permissions are set for the parent folder. To prevent only certain files or subfolders from inheriting permissions from a parent folder: 1. Right-click the file or subfolder, click Properties, click the Security tab. If the permission check boxes for an account appear shaded, the file or folder has inherited permissions from the parent folder.
2. There are three ways to make changes to inherited permissions: Make the changes to the parent folder, and then the file or folder will inherit these permissions. Select the opposite permission (Deny) to override the inherited permission. Clear the Inherit from parent the permission entries that apply to child objects. Include these with entries explicitly defined here check box. This will allow changes to the permissions or removal of the user or group from the permissions list. However, the file or folder will no longer inherit permissions from the parent folder.
3. To clear the inheritance of permissions from a parent folder, click the Advanced tab on the account Properties interface and uncheck the Inherit from parent the permission entries that apply to child objects check box.
Version 3.0, 07/11/2007
4. A Security window, shown below, will appear asking whether to copy inherited permissions or remove them. If the Copy button is clicked, inheritance is removed and the permissions previously inherited are copied to the object. The copied permissions can then be modified. If the Remove button is clicked, all inherited permissions are removed and new permissions must be added. Click on the Remove button.
5. All permissions previously inherited are removed from the file or subfolder.
Version 3.0, 07/11/2007
6. Click the add button to add and modify permissions as previously described above in Setting or modifying permissions.
Shared Folder Permissions Shared folders are used to provide network users with access to files and application resources on the network. When a folder is shared, users can connect to the folder over the network and gain access to the files that it contains. However, to gain access to the files, users must have permissions to access the shared folder. A shared folder can contain applications, data, or a user's personal data, called a home folder. Each type of data requires different shared folder permissions. The following are characteristics of shared folder permissions: Shared folder permissions apply to folders, not individual files. Since shared folder permissions can be applied only to the entire shared folder, and not to individual files or subfolders in the shared folder, shared folder permissions provide less detailed security than NTFS permissions. Shared folder permissions do not restrict access to users who gain access to the folder at the computer where the folder is stored. They apply only to users who connect to the folder over the network. Shared folder permissions are the only way to secure network resources on a FAT volume. NTFS permissions are not available on FAT volumes. On an NTFS volume, share permissions control access to the location of resource objects and NTFS permissions provide additional access restrictions to the objects within the share.
A shared folder appears in Windows Explorer as an icon of a hand holding the shared folder as shown below.
To control how users gain access to a shared folder, assign shared folder permissions. The following table shows shared folder permissions and the actions on shared folders allowed to users by the share permission.
Version 3.0, 07/11/2007
Shared Folder Permission Actions Allowed by Share Permissions Viewing file names and subfolder names Traversing to subfolders Viewing data in files and running programs Adding files and subfolders to the shared folder Changing data in files Deleting subfolders and files Changing permissions (NTFS only) Taking ownership (NTFS only) Full Control Change Read
Shared folder permissions can be set to allow or deny. Generally, it is best to allow permissions and to assign those permissions to a group rather than to individual users. Deny permissions should only be used when it is necessary to override permissions that are otherwise applied. In most cases, deny permissions should only be applied when it is necessary to deny permission to a specific user who belongs to a group to which has been given the permission. If a shared folder is set with deny permission to a user, the user will not have that permission. For example, to deny all access to a shared folder, deny the Full Control permission.
Default Share Permissions Prior to the introduction of Service Pack (SP) one (1) for Windows XP, all newly created share folders were automatically assigned the Full Control permissions for the group Everyone by default. This permission setting allowed Full Control share access to anyone that could reach the share on the network. To provide stronger security of shared resources and ensure that administrators take the time to implement proper share permissions, the addition of SP1 or higher changes the default share permissions to grant only the Read permission to the Everyone group.
Version 3.0, 07/11/2007
The default permissions must be modified to Full Control or to add the Change permission if users will be required to add, delete, or modify objects in the share. Additionally, it is best to remove share permissions for the group Everyone and set permissions for explicit user or group accounts instead.
How Shared Folder Permissions are Applied Applying shared permissions to user accounts and groups affects access to a shared folder. Denying permission takes precedence over the permissions that are allowed. The following list describes the effects of applying permissions. Multiple Permissions Combine: A user can be a member of multiple groups, each with different permissions that provide different levels of access to a shared folder. When permission is assigned to a user for a shared folder, and that user is a member of a group that is assigned a different permission, the user's effective permissions are the combination of the user and group permissions. For example, if a user has Read permission and is a member of a group with Change permission, the user's effective permission is Change, which includes Read. Denying Permissions Overrides other Permissions: Denied permissions take precedence over any permissions that are otherwise allowed for user accounts and groups. If a user is denied permission to a shared folder, the user will not have that permission, even if allowed the permission for a group of which the user is a member. NTFS Permissions are Required on NTFS Volumes: Shared folder permissions are sufficient to gain access to files and folders on a FAT volume but not on an NTFS volume. On a FAT volume, users can gain access to a shared folder for which they have permissions, as well as all of the folders contents. When users gain access to a shared folder on an NTFS volume, they need the shared folder permission and also the appropriate NTFS permissions for each file and folder to which they gain access. Copied or Moved Shared Folders are No Longer Shared: When a shared folder is copied, the original shared folder is still shared, but the copy is not shared. When a shared folder is moved, it is no longer shared.
Version 3.0, 07/11/2007
Sharing Folders To share a folder, a user must be a member of one of several groups, depending on the role of the computer where the shared folder resides. When a folder is shared, access to the folder can be controlled by limiting the number of users who can simultaneously gain access to it, and by assigning permissions for selected users and groups. Note: In the Windows XP Professional Evaluated Configuration, only authorized administrators are allowed to establish network shares. Which groups can share folders, and on which machines they can share them, depends on whether the computer is in a workgroup or a domain: In a Windows Server 2003 domain, the Administrators and Server Operators groups can share folders residing on any machines in the domain. The Power Users group is a local group and can share folders residing only on the stand-alone computer running Windows XP Professional where the group is located. In a Windows XP Professional workgroup, the Administrators and Power Users groups can share folders on the computer running Windows XP Professional on which the group exists.
If the folder to be shared resides on an NTFS volume, users must also have at least the Read permission for that folder to be able to share it. For procedures on sharing folders and setting share permissions, see the Windows XP Professional Evaluated Configuration Administrators Guide.
Mapping a Network Share To map a drive letter to a network computer or folder: 1. Open Windows Explorer, click Start, point to All Programs, point to Accessories, and then select Windows Explorer. 2. On the Tools menu, select Map Network Drive. 3. In Drive, select a local drive letter to map to the shared resource. 4. In Folder, type the server and share name of the resource, in the form of \\servername\sharename. Or click Browse to locate the resource. 5. To reconnect to the mapped drive after every log on, select the Reconnect at logon check box. Click Finish to map the share.
6. The mapped share will be accessible as another drive through Windows Explorer.
Version 3.0, 07/11/2007
7. Mapped drives are available only when the host computer is also available. 8. A different letter can be assigned to a mapped drive by disconnecting from the drive and then remapping it to a new drive letter.
Encrypting File System in Windows XP Professional

EFS is the file encryption technology used for NTFS volumes. It runs as a service and takes advantage of the Cryptography Application Programming Interface (CryptoAPI) architecture in Windows XP Professional. The default configuration of EFS requires no administrative effort; users are allowed to encrypt files by default. The first time EFS is used, it automatically generates an encryption key pair and a certificate for the user if one does not exist already. EFS can use either the Advanced Encryption Standard (AES) or Triple-Data Encryption Standard (3DES) as the encryption algorithm. The default algorithm for Windows XP SP1 and higher, and Windows Server 2003, is AES using a 256-bit key. For users requiring greater symmetric key strength with a Federal Information Processing Standard (FIPS) 140-1 compliant algorithm, the 3DES algorithm can be enabled.
EFS Enhancements in Windows XP Professional Microsoft Windows 2000 introduced the capability for data protection and protected data recovery with the implementation of EFS, and this capability has been enhanced in Windows XP Professional. The new EFS enhancements include: Full support for revocation checking on certificates used when sharing encrypted files, Support for encrypted offline folders in Windows XP, Multi-user support for encrypted files in the shell User Interface (UI), Support for Microsoft Enhanced and Strong CSPs, Additional support for enhanced algorithm options and strengths, End-to-end encryption using EFS over Web Distributed Authoring and Versioning (WebDAV), Enhanced recovery policy flexibility, Performance and reliability enhancements, and Additional security features for protecting EFS data.
Version 3.0, 07/11/2007
Components of EFS EFS consists primarily of the following operating system components: the EFS service, and EFS RunTime Library. The EFS Run-Time Library is an internal library of NTFS.SYS driver providing NTFS the EFS functionalities, and an Application Programming Interface (API). Like many other security services, EFS uses the Microsoft Cryptographic Application Programming Interface to obtain services from a cryptographic service provider such as the Rivest, Shamir, and Adleman (RSA) Base Provider that is included with Windows XP Professional. EFS Service The EFS service is part of the security subsystem. It uses the existing Local Procedure Call (LPC) communication port between the Local Security Authority (LSA) and the kernel-mode security reference monitor to communicate with the EFS Run-Time Library. In user mode, it interfaces with CryptoAPI to obtain file encryption keys and to generate Data Decryption Fields (DDFs) and Data Recovery Fields (DRFs). The EFS service also provides support for Win32 APIs. The EFS service calls CryptoAPI to acquire the File Encryption Key (FEK) for a data file and then to encode the FEK, thus producing the DDF. The EFS service also returns the FEK, DRF, and DDF by way of the File System RunTime Library (FSRTL) to the EFS driver. CryptoAPI EFS uses CryptoAPI for all of its cryptographic operations. CryptoAPI provides services that enable application developers to add cryptography to their Win32 applications. CryptoAPI consists of a set of functions that allow applications to encrypt or digitally sign data in a flexible manner, while providing protection for private key data. Applications can use the functions in CryptoAPI without knowing anything about the underlying implementation. CryptoAPI provides the underlying security services for secure channels and code signing. CryptoAPI supports public key and symmetric-key operations such as key generation, key management and secure storage, key exchange, encryption, decryption, hashing, digital signatures, and verification of signatures. Developers can use certificates with these public key operations and perform the necessary encapsulations and encoding to apply certificates within their applications. CSP By default, EFS uses the AES algorithm with a 256-bit key in the Windows XP Professional with SP1 and higher for encrypting file data. The public-private key pairs for EFS users and recovery agent accounts are obtained from the Microsoft base CSP, also called the RSA base provider. This CSP is included with Windows XP Professional and is approved for general export worldwide. The Microsoft enhanced CSP can also be used for EFS. Windows XP Professional can be configured to use the 3DES algorithm instead of AES. 3DES is compliant with FIPS 140-1 Level 1 and provides encryption using a 168-bit key. Note: The FIPS 140-1 is a security implementation designed for certifying cryptographic software. FIPS 140-1 validated software is required by the U.S. Government and requested by other prominent institutions. Data Protection API. The Data Protection API (DPAPI) is a set of function calls that provide data protection services to user and system processes. Applications either pass plaintext data to DPAPI and receive protected data back, or pass the protected data to DPAPI and receive plaintext data back. For example, after a CSP generates keys for certificates, it calls CryptProtectData(), one of the primary functions of DPAPI, to protect those keys. When the keys are needed, DPAPI decrypts them. Win32 API EFS provides an API set to expose its features. This API provides a programming interface for operations such as encrypting plaintext files, decrypting or recovering ciphertext files, and importing and exporting encrypted files (without decrypting them first). The API is used to support remote encryption, decryption, backup, and restore operations. The API is supported in a standard system Dynamic Link Library (DLL), Advapi32.dll.
Version 3.0, 07/11/2007
Maintaining File Confidentiality Only authorized users and designated Data Recovery Agents (DRAs) can decrypt encrypted files. Other system accounts that may have NTFS permissions for a file, including the Take ownership of files or other objects privilege, cannot open the file without authorization. Even the administrator account cannot open the file if that account is not designated as a data recovery agent. If an unauthorized user tries to open an encrypted file, access will be denied. Authorization to open an encrypted file can be granted to a user by the file owner by adding the users certificate to the encrypted file.
Encrypting a File or Folder If a folder is encrypted, all files and subfolders created in, or added to, the encrypted folder are automatically encrypted. It is recommended that encryption be done at the folder level to prevent plaintext temporary files from being created on the hard disk during file conversion. Encrypt a file or folder on an NFTS volume as follows: 1. Select the file or folder to encrypt. 2. Right-click on the file or folder and click Properties. 3. On the General tab, click Advanced.
4. On the Advanced Attributes dialog box, select the Encrypt contents to secure data check box and click OK. Notice that the Details button is grayed out.
Version 3.0, 07/11/2007
Note: A file cannot be both compressed and encrypted at the same time. 5. Click OK in the Properties dialog box. 6. A Confirm Attributes Changes dialog will ask to choose between encrypting the folder and all its contents or just the folder itself. If the folder is empty, choose to encrypt the folder only; otherwise, choose the folder and its contents, and click OK.
7. A dialog box shows the progress status of encrypting the folder or file. Click OK again to make this change, and close the Properties interface. Note: When an encrypted file is moved to another folder that is not encrypted, the file remains encrypted. However, if the owner of the file moves the file to a FAT partition or volume, such as a floppy disk, the file is automatically decrypted. 8. The display name for all encrypted files and folders will be presented in green text. This allows users to easily identify encrypted files and folders.
Obtaining EFS Certificates Windows XP Professional allows the owner of an encrypted file the ability to grant other specific users access to decrypt and view the file. Before a user can be granted access to an encrypted file, that user must have and valid EFS Certificate. In Windows XP, EFS is enabled by default and all users are allowed to encrypt files. When a user encrypts a file for the first time, as described above in Encrypting a file or folder, EFS generates a unique EFS certificate and key pair for the user. Alternate methods of obtaining an EFS Certificate include importing a certificate into the users Certificate store, requesting an certificate by using the Advanced Certificate page Web form, or directly requesting an EFS certificate from a CA within the Domain. The procedures below explain how to import an EFS certificate to a standalone workstation and how to make a certificate request within a Domain.
Version 3.0, 07/11/2007
Import EFS Certificates Users can import EFS Certificates as follows: 1. Obtain an EFS Certificate from a CA, or from a backup, as necessary. 2. Copy the file to a disk location on the computer where the encryption certificate will be imported. 3. Click Start, click Run, type mmc in the Open box, and click OK. 4. From the File menu, select Add/Remove snap-ins, and click Add. 5. Locate the Certificates snap-in, and click Add.
6. Select My user account and then click Finish. Click Close. Click OK.
7. Expand the Certificates Current User node under Console Root. Right-click Personal store, point to All Tasks, and select Import to import the certificate.
Version 3.0, 07/11/2007
8. This starts the Certificate Import Wizard. Follow the wizard steps to successfully import the certificate and private key.
9. Provide the path to the Certificate.
10. Click the Place all certificates in the following store radio button, and accept the Personal certificate store. Click Next.
Version 3.0, 07/11/2007
11. Click Finish, and then click OK to start the import operation. When the import is complete, click OK to close the wizard.
Request an EFS Certificate from a CA within a Domain Users can request an EFS Certificate from a local CA within a Domain as follows: 1. Click Start, click Run, type mmc in the Open box, and click OK. 2. From the File menu, select Add/Remove snap-ins, and click Add. 3. Locate the Certificates snap-in, and click Add. 4. Select My user account and then click Finish. Click Close. Click OK. 5. Right-click Personal store, click All Tasks, and select Request New Certificate.
Version 3.0, 07/11/2007
6. This starts the Certificate Request Wizard. Click Next.
7. In Certificate Types, select Basic EFS. Click Next.
8. Enter a name for the certificate in the Friendly name text box. A description may be entered if desired. Click Next.
Version 3.0, 07/11/2007
9. Review the request information and click Finish.
10. A message will be displayed indicating that the request was received by the CA and is pending action by the Certificate Manager.
11. Once the Certificate Manager approves and issues the certificate the user will be able to use to encrypt files locally and on resources, such as share folders, within the Domain.
Granting Local Users Authorization to Open Encrypted Files The owner of an encrypted file on a standalone workstation or domain member where there is no CA may grant other users the ability to open the encrypted file as follows: 1. Right-click on the one the encrypted file that is to be shared with other users and click Properties. 2. On the General tab, click Advanced. 3. On the Advanced Attributes dialog window, click the Details button. The Encryption Details for <filename> dialog window will appear. Click Add.
Version 3.0, 07/11/2007
4. The Select User dialog window will appear. It will display only users that currently have encryption certificates. Select the users to be added and click OK.
5. The Encryption Details for <filename> dialog window will display the accounts of all users that are allowed to access the encrypted file. Click OK on the Encryption Details for <filename> dialog window, the Advanced Attributes dialog window, and the Properties window to close and accept the changes.
Version 3.0, 07/11/2007
Granting Domain Users Authorization to Open Encrypted Files Within a domain that includes a CA, the owner of an encrypted file may grant other users the ability to open the encrypted file as follows: 1. Right-click on the one the encrypted file that is to be shared with other users and click Properties. 2. On the General tab, click Advanced. 3. On the Advanced Attributes dialog window, click the Details button. The Encryption Details for <filename> dialog window will appear. Click Add.
4. On a computer that is a member of a Windows domain, the Find User button on the Select User dialog widow will be enabled. Click the Find User button to search for user accounts on Active Directory.
5. Click the Advanced button on the next Select User dialog widow to open a search window. Click Find Now button to display a list of accounts. If necessary, use the Locations button to specify a different location from which to select accounts. Select the desired account from the list and click OK.
Version 3.0, 07/11/2007
6. Click OK again on the Select User dialog window, which shows the selected account.
Note: If the user that is selected does not have a valid certificate, a notification will appear stating that No appropriate certificates correspond to the selected user. Make sure user follows the required procedures, as described in Obtaining EFS Certificates to obtain a valid certificate. Otherwise, the owner of the encrypted file will not be able to grant access to the user.
7. The account will now appear in the list of certificate holder accounts.
Version 3.0, 07/11/2007
8. If necessary, validate the certificate by selecting the account and clicking the View Certificate button. Otherwise, go to step 12.
9. The users certificate will be displayed.
10. To verify the CA for the certificate, click the Certification Path tab, highlight the root certificate in the path, and click the View Certificate button.
Version 3.0, 07/11/2007
11. The certificate for the root CA will be displayed. Close all certificate windows.
12. Select the desired user from the list presented in the Select User dialog window, and then click the OK button.
Version 3.0, 07/11/2007
13. The users account will now appear in the list of Users Who Can Transparently Access This File. Click OK to close the Encryption Details for <filename> dialog window. Click OK on the Advanced Attributes dialog window, and the Properties window to close and accept the changes.
Revocation Checking Windows XP performs revocation checking on all certificates for other users when they're added to an encrypted file. For performance reasons, users that hold a private key and recovery agent certificates are not checked for revocation, they are only verified for time validity. However, user certificates that do not contain a CRL Distribution Point (CDP) extension (such as those from some third party CAs) will not be validated for revocation status when added to a file. If the user does not chain to a trusted root CA certificate, or the certificate is not installed in the Trusted People certificate store, the user will be warned before adding the certificate. If the revocation status check on a certificate fails, the messages shown below will be displayed and the certificate will not be used.
Or
Version 3.0, 07/11/2007
If the user selects to add a certificate that does not chain to a trusted root CA, it will not be added. However, if the user selects to add a self-signed cert that was installed by another user on the same machine, the user will be allowed to add it. If the revocation status and chain building completed successfully, the user will be added to the dialog box and the file updated as shown in below. For more information on certificate status and chain building, refer to the following whitepaper: http://www.microsoft.com/technet/prodtechnol/winxppro/support/tshtcrl.mspx
Notes: Any user that can decrypt a file can also remove other users if the user doing the decrypting also has write permission. EFS has a limit of 256K in the file header for the EFS metadata. This limits the number of individual entries for file sharing that may be added. On average, a maximum of 800 individual users may be added to an encrypted file.
Removing a Users Authorization to Open an Encrypted File The owner of an encrypted file may use the following procedure to remove a users access to the file: 1. Right-click the encrypted file that is to be shared with other users and click Properties. 2. On the General tab, click Advanced. 3. On the Advanced Attributes dialog window, click the Details button. The Encryption Details for <filename> dialog window will appear displaying the names of all accounts that have access to the encrypted file. Select the account that is to be removed and click the Remove button.
Version 3.0, 07/11/2007
4. The account will be immediately removed from the list of authorized accounts. Click OK to close the Encryption Details for <filename> dialog window. Click OK on the Advanced Attributes dialog window, and the Properties window to close and accept the changes.
Decrypting Files and Folders Encrypted files can only be decrypted using the private key that encrypted them. Decrypt a file as follows: 1. Right-click the folder and click Properties. 2. On the General tab in the Properties dialog box, click Advanced. 3. Clear the Encrypt contents to secure data dialog box.
Version 3.0, 07/11/2007
4. Click OK. 5. Click OK again on the Properties window to confirm. Note: If a folder is being decrypted, there will be a dialog box offering the option to just decrypt the folder, or to decrypt the folder and all of its contents.
Copying an Encrypted Folder or File Because of the unique nature of encrypted files, different results can occur when moving or copying encrypted files between locations. For example, when copying an encrypted file from a local machine to a server on the network, different results of the copy operation will occur depending on the operating system being used on the server. In general, copying a file will inherit the EFS properties of the target, but a move operation will not inherit the EFS properties of the target folder. The following explains the procedures and limitations for copying encrypted folders or files on the same volume and from one volume to another. To copy a file or folder on the same computer from one NTFS partition in a Windows XP Professional computer to another NTFS partition. Copy the file or folder in the same manner as an unencrypted file. Use Windows Explorer or the command prompt. The copy is encrypted. To copy a file or folder on the same computer from an NTFS partition in a Windows XP Professional volume to a FAT partition. Copy the file or folder in the same manner as an unencrypted file. Use Windows Explorer or the command prompt. Because the destination file system does not support encryption, the copy is not encrypted. To copy a file or folder to a different computer where both use the NTFS partitions in Windows XP Professional. Copy the file or folder in the same manner as an unencrypted file. Use Windows Explorer or the command prompt. If the remote computer allows the user encryption of files, the copy is encrypted. When an encrypted file is copied to a target location that does not allow remote encryption, the user will be prompted with a dialog box that allows a choice of whether or not to decrypt the file. If the target server is running Windows Server 2003, and the machine account of the server is trusted for delegation in Active Directory, the file will be silently decrypted and copied to the server where it will be re-encrypted using a local profile and encryption key.
Version 3.0, 07/11/2007
Notes: The file is transmitted on the network between the client and the server in an unprotected format. If this file contains confidential information, care should be given to ensure that the network connection also provides secure transmission of the data. Such network data protection might include IP Security (IPSec). If the original file was encrypted, Microsoft recommends that the status of the destination file be confirmed by looking at the Advanced Attributes dialog box (click the Advanced button on the General tab of the files property sheet).
Moving or Renaming an Encrypted Folder or File The procedures and limitations for moving encrypted folders or files on the same volume and from one volume to another are as follows: To move or rename a file or folder within the same volume: Move or rename the file in the same manner as an unencrypted file. Use Windows Explorer, the shortcut menu, or the command prompt. The destination file or folder remains encrypted. To move a file or folder between volumes: This is essentially a copy operation. Review the previous subsection, Copying an Encrypted Folder or File.
Deleting an Encrypted Folder or File If a user has sufficient access to delete the file or folder, the user can delete it in the same manner as an unencrypted file. Note: Deleting an encrypted folder or file is not restricted to the user who originally encrypted the file.
System Folders and Files The operating system also prevents encryption of system folders, files and locations in the %SYSTEMROOT%\... path. When a user attempts to encrypt a system file, or attempts to copy an encrypted file into the system path, the user will receive an "access denied" message as shown below.
Encryption and Local Password Resets on Windows XP Windows XP Professional has new behavior regarding locally changed passwords and EFS. In Windows 2000, when a local user password was reset by an administrator, the administrator or third party could theoretically use the newly changed account to log on as the user and decrypt the encrypted files. In Windows XP Professional, the changing of a local user password by an administrator, or through a method other than by the user, will block all access to previously encrypted files by the user.
Version 3.0, 07/11/2007
In summary, the profile and keys of the user will be lost and will not be available to the account with the reset password. Windows XP gives the following warning when attempting to reset a user account password:
Clicking Proceed presents the following dialog window with additional warnings:
This feature helps to guard against offline attacks and prevents rogue administrators from gaining access to encrypted files of other users.
Restoring Files to a Different Computer To be able to use encrypted files on a computer other than the one the files were encrypted on, authorized administrators need to ensure that the encryption certificate and associated private key are available on the other system. This can be accomplished by manually moving the keys. Before moving keys manually, authorized users should back up encryption certificates and private keys. They can then restore the certificates and keys on a different system. Back up the encryption certificate and private key as follows: 1. Log on as the user that is going to export the encryption certificate and private key. 2. Click Start, select Run, type mmc in the Open box, and click OK. 3. On the Console menu, click Add/Remove snap-ins, and click Add. 4. Locate the Certificates snap-in, and click Add.
Version 3.0, 07/11/2007
5. Select My user account and then click Finish. Click Close. Click OK. 6. Locate the Encrypting File System certificates in the Personal certificate store. Click the + next to CertificatesCurrent User. Expand the Personal folder. Select Certificates. 7. Right-click on the users EFS certificate, point to All Tasks, and select Export.
8. This starts the Certificate Export Wizard. Click Next.
9. Click Yes, export the private key. Click Next.
Version 3.0, 07/11/2007
10. The export format available is Personal Information Exchange-PKCS#12, or .pfxpersonal exchange format. Click Next.
11. Provide the password to protect the .pfx data. Click Next. 12. Provide the path and file name where the .pfx data is to be stored. For this example, type c:\mykey in the File name entry box. Click Next. 13. Review the settings that were specified and click Finish.
14. A message will appear indicating that the export was successful. Click OK and close the Microsoft Management Console (MMC).
Version 3.0, 07/11/2007
This exports the encryption certificate and private key to a .pfx file that must be backed up securely. To restore an encryption certificate and private key on a different system do the following: 1. Copy the .pfx file to a floppy disk, and take it to the computer on which the encryption certificate and private key are to be imported. 2. Log on to the other computer as the user that owns the encryption certificate and private key. 3. Click Start, select Run, type mmc in the Open box, and click OK. 4. On the Console menu, click Add/Remove snap-ins, and click Add. 5. Locate the Certificates snap-in, and click Add. 6. Select My user account and then click Finish. Click Close. Click OK. 7. Right-click Personal store, point to All Tasks, and select Import to import the .pfx file.
8. This starts the Certificate Import Wizard. Click Next and follow the wizard steps to successfully import the certificate and private key.
9. Provide the path to the .pfx file. In our example, it is c:\mykey.pfx. If necessary, use the Browse button to search for the file. The Type of file selection for the search is Personal Information Exchange (*.pfx, *.p12). Click Next.
Version 3.0, 07/11/2007
10. Type the password to unwrap the .pfx data. Click Next.
11. Select the Place all certificates in the following store radio button, and accept the Personal certificate store. Click Next.
12. Review the settings and click Finish close the wizard.
13. A message will appear indicating that the import was successful. Click OK and close the MMC.
Version 3.0, 07/11/2007
Once the same keys available, the user can transparently use encrypted files that may have been backed up by an authorized administrator onto another computer.
Folder and File Encryption on a Remote Server Users can transparently encrypt and decrypt files and use encrypted files stored on a remote server. This works whether the users access those files remotely or log on to the other computer locally. However, remember that when encrypted files are moved using backup and restore mechanisms, the appropriate encryption certificate and private keys must also be moved to allow use of the encrypted files in their new destinations. Without correct private keys, users cannot open or decrypt the files. Note: If an encrypted file is opened over the network, the data that is transmitted over the network by this process is not encrypted. Other protocols, such as Secure Sockets Layer(SSL)/Personal Communication Technology (PCT) or IPSec must be used to encrypt data over the wire.
Web Distributed Authoring and Versioning (WebDAV) WebDAV extends the HyperText Transfer Protocol (HTTP/1.1) to allow clients to publish, lock, and manage resources on the Web. Integrated into Internet Information Services (IIS), WebDAV allows clients to do the following: Manipulate resources in a WebDAV publishing directory on a server. For example, users who have been assigned the correct rights can copy and move files around in a WebDAV directory. Modify properties associated with certain resources. For example, a user can write to and retrieve a file's property information. Lock and unlock resources so that multiple users can read a file concurrently. However, only one person can modify the file at a time. Search the content and properties of files in a WebDAV directory.
To make WebDAV available to Windows XP Professional clients, it must first be set up by an authorized administrator on a Windows Server 2003 system running IIS. When a publishing directory is made available, users who have been assigned the correct rights can publish documents to the server and manipulate files in the directory.
WebDAV Clients Users access and publish to a WebDAV directory through one of the Microsoft products listed below or through any other client that supports the industry standard WebDAV protocol. For the specific procedure on how to access and publish through these Microsoft products, consult the specific product's Help. Note: To access a WebDAV directory, an authorized administrator must first enable the WebClient service on a users computer. Windows Clients (Windows Server 2003 and Windows XP) Connect to a WebDAV directory by adding the directory to the list of Network Places and display the contents as if it were part of the
Version 3.0, 07/11/2007
same file system on the local computer. Once connected, users can drag and drop files, retrieve and modify file properties, and complete many other file-system tasks. Users can also connect using the command-line client (known as WebDAV Redirector). This client allows the use of existing applications across the Web and the sharing of files through firewalls and proxy servers. Internet Explorer (IE) (versions 5.0 and 6.0) Connect to a WebDAV directory by opening the target directory as a Web folder and complete the same file-system tasks as Windows clients. Note: IE is not an evaluated component of the Windows Server 2003 Evaluated Configuration. Microsoft Office products (Office 2000 and Office XP): Create, publish, edit, and save documents directly into a WebDAV directory through any application in Office 2000 or Office XP. Note: Microsoft Office products are not included in the Windows Server 2003 Evaluated Configuration.
Connecting to a WebDAV Directory Users can connect to a WebDAV directory by adding a network share in My Network Places. 1. On a Windows XP Professional client, click Start and select My Computer, then click the My Network Places link.
2. Click the Add Network Place link.
Version 3.0, 07/11/2007
3. The Add Network Place Wizard will appear. Click Next.
4. Select Choose another network location and click Next.
Version 3.0, 07/11/2007
5. In the Internet or network address text box, enter the network path to the WebDAV folder. Click Next.
6. Depending on the type of authentication requirements set for the WebDAV folder, an authentication request may appear. Enter the appropriate account and password information and click OK.
7. Enter a name for the network place, or accept the default, then click Next.
8. Click Finish to complete the Wizard.
Version 3.0, 07/11/2007
9. A network folder, mapped to the WebDAV folder, will appear in My Network Places.
10. The folder may be accessed in the same manner as any other folder in windows explorer and access to the contents will be based on virtual directory and NTFS permissions specified for the WebDAV site and its folder contents.
Version 3.0, 07/11/2007
Remote EFS Operations on File Shares and Web Folders (WebDAV folders) Users can encrypt and decrypt files that are stored on network file shares or on WebDAV Web folders. Web folders have many advantages compared to file shares, and Microsoft recommends the use of Web folders whenever possible for remote storage of encrypted files. Web folders require less administrative effort and are more secure than file shares. Web folders can also securely store and deliver encrypted files over the Internet by using standard HTTP file transfers. Using file shares for remote EFS operations within the Evaluated Configuration requires a Windows Server 2003 domain environment because EFS must impersonate the user by using Kerberos delegation to encrypt or decrypt files for the user. The primary difference between remote EFS operations on files stored on file shares and files stored on Web folders is where the operations occur. When files are stored on file shares, all EFS operations occur on the computer on which the files are stored. For example, if a user connects to a network file share and chooses to open a file that he or she previously encrypted, the file is decrypted on the computer on which the file is stored and then transmitted in plaintext over the network to the user's computer. When files are stored on Web folders, all EFS operations occur on the user's local computer. For example, if a user connects to a Web folder and chooses to open a file that he or she previously encrypted, the file remains encrypted during transmission to the user's computer and is decrypted by EFS on the user's computer. This difference in where EFS operations occur also explains why file shares require more administrative configuration than Web folders.
Remote EFS Operations in a Web Folder Environment When users open encrypted files stored on Web folders, the files remain encrypted during the file transfer, and EFS decrypts them locally. Both uploads to and downloads from Web folders are raw data transfers, so even if an attacker could access the data during the transmission of an encrypted file, the captured data would be encrypted and unusable. EFS with Web folders eliminates the need for specialized software to securely share encrypted files between users, businesses, or organizations. Files can be stored on common intranet or Internet file servers for easy access while strong security is maintained by EFS. The WebDAV redirector is a mini-redirector that supports the WebDAV protocol, an extension to the HTTP 1.1 standard, for remote document sharing over HTTP. The WebDAV redirector supports the use
Version 3.0, 07/11/2007
of existing applications, and it allows file sharing across the Internet (for example, using firewalls, routers) to HTTP servers. Users access Web folders in the same way that they access file shares. Users can map a network drive to a Web folder by using My Computer. Upon connecting to the Web folder, the user can choose to copy, encrypt, or decrypt files exactly as they would by using files on file shares. Note: Web folders are not included in browse lists. To connect to a Web folder, the user must specify the full path (for example, \\ServerName\WebShareName).
Remote Encryption of Files on Web Folders When a user chooses to encrypt a file on a Web folder, the file is automatically copied from the Web folder to the user's computer, encrypted on the user's computer, and then returned to the Web folder. The advantage to this is that the computer hosting the Web folder does not need to be trusted for delegation and does not require roaming or remote user profiles. No other administrative tasks beyond creating the Web folder and assigning user permissions are required. The disadvantage is that the file must be transmitted from the Web folder to the local computer in order to be encrypted. Organizations need to consider whether the bandwidth requirements for Web folders outweigh the administrative effort necessary to maintain file shares for encrypted file storage. It must also be considered that Web folders are not recommended for files over 60 MB in size. Note: Bandwidth requirements are reduced and greater security is ensured if the user first encrypts the file locally and then stores the file on the Web folder. The encrypted file is transmitted in ciphertext when it is transmitted to a Web folder.
Remote Decryption of Files on Web Folders When a user chooses to decrypt a file on a Web folder, the file is automatically copied from the Web folder to the user's computer in ciphertext. EFS then decrypts the file on the user's computer. If the user opens the encrypted file for use in an application, the file is never decrypted anywhere except on the user's computer. If the user chooses to decrypt a file on the Web folder rather than on the local computer, the file is transmitted in plaintext and stored in plaintext on the Web folder after it is decrypted on the user's computer. The computer hosting the Web folder does not require any configuration except for the creation of the Web folder and the assigning of user permissions in order for remote decryption to function.
File Copy from a Web Folder Encrypted files are copied from Web folders in the same way that plaintext files are copied from file shares. The file is transmitted in ciphertext and remains encrypted on the local computer if possible. The encryption status for files copied from Web folders is the same as that for files copied locally. For more information about encryption status for copied files see Copying an Encrypted Folder or File.
Certificates and Certification Authorities

A public key certificate, usually called a digital certificate, is a common credential that provides a means to verify identity by binding the value of a public key to the identity of the person, device, or service that holds the corresponding private key. Most certificates in common use are based on the X.509v3 certificate standard.
Version 3.0, 07/11/2007
A trusted organization assigns a certificate to an individual or an entity that associates a public key with the individual. The individual or entity to which a certificate is issued is called the subject of that certificate. The trusted organization that issues the certificate is a Certification Authority (CA) and is known as the certificates issuer. A trustworthy CA will issue a certificate only after verifying the identity of the certificate's subject. Certificates can be issued for a variety of functions, such as Web user authentication, Web server authentication, secure e-mail (Secure/Multipurpose Internet Mail Extensions (S/MIME)), Internet Protocol (IP) Security (IPSec), Transport Layer Security (TLS), and code signing. Certificates are also issued from one CA to another in order to establish a certification hierarchy Typically, certificates contain the following information: The subject's public key value, The subject's identifier information, such as the name and e-mail address, The validity period (the length of time that the certificate is considered valid), Issuer identifier information, and The digital signature of the issuer, which attests to the validity of the binding between the subject s public key and the subjects identifier information.
A certificate is valid only for the period of time specified within it; every certificate contains Valid From and Valid To dates, as shown in the certificate below, that set the boundaries of the validity period. Once a certificate's validity period has passed, a new certificate must be requested by the subject of the nowexpired certificate.
In instances where it becomes necessary to undo the binding that is asserted in a certificate, a certificate can be revoked by the issuer. Each issuer maintains a Certificate Revocation List (CRL) that can be used by programs when checking the validity of any given certificate.
Version 3.0, 07/11/2007
One of the main benefits of certificates is that hosts no longer have to maintain a set of passwords for individual subjects who need to be authenticated as a prerequisite to access. Instead, the host merely establishes trust in a certificate issuer. When a host, such as a secure Web server, designates an issuer as a trusted root authority, the host implicitly trusts the policies that the issuer has used to establish the bindings of certificates it issues. In effect, the host trusts that the issuer has verified the identity of the certificate subject. A host designates an issuer as a trusted root authority by placing the issuer's self-signed certificate, which contains the issuer's public key, into the trusted root CA certificate store of the host computer. Intermediate or subordinate certification authorities are trusted only if they have a valid certification path from a trusted root CA.
Certificate Uses Since certificates are generally used to establish identity and create trusts for the secure exchange of information, CAs can issue certificates to people, to devices (such as computers), and to services running on computers (such as IPSec). In some cases, computers must be able to exchange information with a high degree of confidence in the identity of the other device, service, or person involved in the transaction. In some cases, people need to exchange information with a high degree of confidence in the identity of the other person, computer, or service involved in the transaction. Applications and services that run on computers also frequently need to verify that they are accessing information from a trusted source. In circumstances where two entities, such as devices, persons or applications or services, attempt to establish identity and trust, the fact that both entities trust the same certification authority allows the bond of identity and trust to be established between them. Once a certificate subject has presented a certificate issued by a trusted CA, the entity attempting to establish trust can proceed with an information exchange by storing the certificate subject's certificate in its own certificate store, and, where applicable, using the public key contained in the certificate to encrypt a session key so that all subsequent communications to the certificate subject are secure.
Certificate Use in Organizations Organizations may install a Windows Server 2003 Certificate Server as their own CA and issue certificates to internal devices, services, and employees to create a more secure computing environment. Large organizations may have multiple CAs, set up in a hierarchy that leads to a root CA. Thus, an employee of an organization may have a multitude of certificates in their certificate store that have been issued by a variety of internal CAs, all of whom share a trust connection via the certification path to the root CA. A client computer certificate may serve multiple purposes, most of which are based in authentication, allowing the client to use many organizational resources without the need for individual certificates for each resource. For example, the client certificate might allow Virtual Private Network (VPN) connectivity as well as access to the company store intranet site, to product servers, and to the human resources database where employee data is stored. The VPN server certificate might also serve multiple purposes. The same certificate might have the purpose of verifying the identity of e-mail servers, Web servers, or application servers. The CA that issues the certificate determines the number of purposes for each certificate.
Certificates Issued to Persons Certificates issued by a Windows Server 2003 Certificate Server can be used to send personal e-mail messages that are encrypted for security or digitally signed to prove authenticity. By doing so, the
Version 3.0, 07/11/2007
message recipient can verify that the message has not been altered during transit and that the message actually came from the person claiming to have sent it. Additionally, when a user encrypts an e-mail message, nobody can read the message while it is in transit, and only the message recipient can decrypt and read the message.
Certificate Stores Windows XP Professional and Windows Server 2003 store certificates locally on the computer or device that requested it or, in the case of a user, on the computer or device that the user used to request it. The storage location is called the certificate store. A certificate store will often have numerous certificates, possibly issued from a number of different CAs. Using the Certificates snap-in can be used to display the certificate store for a user, a computer, or a service according to the purpose for which the certificates were issued or by using their logical storage categories. By using the Certificates snap-in, users can view certificates by purpose or by logical store. If viewed by purpose, a certificate with multiple purposes will appear listed in every folder that defines a purpose for which the certificate can be used. The Certificates snap-in below shows the certificates by Intended Purpose.
The Certificates snap-in below shows the certificates by logical store.
Version 3.0, 07/11/2007
If users have the rights to do so, they can import or export certificates from any of the folders in the certificate store. Additionally, if the private key associated with a certificate is marked as available for export, the user can export both into a Public Key Cryptography Standard (PKCS) #12 file for backup purposes. If a user does not own a certificate, the user will not have the right to export the private key associated with the certificate. The table below provides a brief description of some of the purpose and logical stores. Displaying certificates by logical stores is the Certificates default. Note that the list of certificate purpose stores shown below does not include all the possible purpose stores. Table 3.1 Certificate Stores
Display by Folder Name Personal Trusted Root Certification Authorities Disallowed Certificates Third-Party Root Certification Authorities Intermediate Certification Authorities Trusted People Contents Certificates associated with private keys to which you have access. These are the certificates that have been issued to you, or to the computer or service for which you are managing certificates. Implicitly trusted certification authorities. Includes all of the certificates in the Third-Party Root CAs store plus root certificates from your organization and Microsoft. These are certificates that you have explicitly decided not to trust using either Software Restriction policy or by clicking "Do not trust this certificate" when the decision is presented to you in mail or a Web browser. Trusted root certificates from certification authorities other than Microsoft and your organization.
Logical Store
Certificates issued to subordinate CAs. Certificates issued to people or end entities that are explicitly trusted. Most often these are self-signed certificates or certificates explicitly trusted in an application such as Microsoft Outlook. Certificates issued to people or end entities that are implicitly trusted. These certificates must be part of a trusted certification hierarchy. Most often these are cached certificates for services like Encrypting File System, where certificates are used for creating authorization for decrypting an encrypted file.
Other People
Version 3.0, 07/11/2007
Display by
Folder Name Certificate Enrollment Requests Server Authentication Client Authentication
Contents Pending or rejected certificate requests. Certificates that server programs use to authenticate themselves to clients. Certificates that client programs use to authenticate themselves to servers. Certificates associated with key pairs used to sign active content. Certificates associated with key pairs used to sign e-mail messages. Certificates associated with key pairs that encrypt and decrypt the symmetric key used for encrypting and decrypting data by the encrypting file system. Certificates associated with key pairs that encrypt and decrypt the symmetric key used for recovering encrypted data by the encrypting file system.
Purpose
Code Signing Secure Email Encrypting File System
Purpose (continued)
File Recovery
Notes: When looking at the contents of a certificate store in Logical Store mode, there may occasionally appear to be two copies of the same certificate in the store. This occurs because the same certificate is stored in separate physical stores under a logical store, such as the Registry and Enterprise physical stores under the Trusted Root CAs logical store. When the contents of the physical certificates stores are combined into one logical store view, both instances of the same certificate are displayed. This can be verified this by setting the view option to show the physical certificate stores and then noting that the certificate is stored in separate physical stores under the same logical store. It can be verified as the same certificate by comparing the serial numbers.
CA Trust For Windows users, computers, and services, trust in a CA is established when there is a copy of the root certificate in the Trusted Root Certification Authorities store, as well as a valid certification path, meaning that none of the certificates in the certification path has been revoked or has had its validity period expire. The certification path includes every certificate issued to each CA in the certification hierarchy from a subordinate CA to the root CA. For example, for a root CA, the certification path is one certificate, its own self-signed certificate. For a subordinate CA, just below the root CA in the hierarchy, its certification path is 2 certificates, its own certificate and the root CA certificate.
Version 3.0, 07/11/2007
If an organization is using Active Directory, then trust in the organization's certification authorities will typically be established automatically, based on decisions and settings made by the CA administrator. A related concept that users should be familiar with is certificate store inheritance. If a root CA certificate is placed into the computer's trusted root CAs store or enterprise trust store, then any user of the computer will see that certificate in their own user trusted root CA store, or enterprise trust store even though the root certificate is actually in the computer's store. Essentially, users will trust any CA that their computer trusts. Certificate store inheritance does not work the other way around: certificates in the user's trusted root CAs store and enterprise trust store are not inherited by the computer. If an organization is using the version of Windows Server 2003 Certificate Server as its CA, then the CA is one of two types: Enterprise or Stand-alone. The differences between the two standard types of Windows Server 2003 Certificate Server CAs for certificate users and requesters are summarized below.
Enterprise CA An Enterprise CA is dependent upon Active Directory being present. The Certificate Request Wizard or CA Web pages, if available, can be used to request certificates from an Enterprise CA. Enterprise CAs offers different types of certificates to a requester based on the certificates they are configured to issue as well as the security permissions of the requester. An Enterprise CA uses information available in Active Directory to help verify the requester's identity. It also publishes its certificate revocation list to Active Directory and can be configured to publish it to a shared directory.
Version 3.0, 07/11/2007
Stand-alone CA A Stand-alone CA is less automated for a user than an Enterprise CA because it does not depend on the use of Active Directory. By default, users can request certificates from a stand-alone CA only by using CA Web pages. A Stand-alone CA makes its CRL available from a shared folder or from Active Directory if it is available. Notes: The TOE does not include the use of Windows Certificate Services Web Pages. Although Stand-alone CAs may be used as offline root CAs supporting the TOE, they are not included in the TOE. As an offline root CA, a Stand-alone CA may be used to sign and provide a subordinate CA certificate to an issuing Enterprise CA within the TOE.
Requesting Certificates from a Windows Server 2003 Certificate Server
Requesting Certificates Certificate requests must be made by the user, computer, or service that has access to the private key associated with the public key that will be part of the certificate. Depending upon the public key policies established by the system administrator, machines and services can automatically request certificates without user intervention. Within the TOE, users will make certificate requests to a CA within their network domain by using the Certificate Request Wizard. The types of certificates that are available to the end user will depend on the type of certificate issuance policy that has been implemented at the CA. Notes: The TOE does not include the use of Windows Certificate Services Web Pages for certificate requests. Since the CA resides within a domain, and is directly accessible by domain members within the TOE, users will be able to use the Certificate Request Wizard to submit a certificate request directly to the CA.
User Auto-Enrollment In a Windows domain environment, Group Policy settings may be combined with Version 2 certificate templates to enable users to be automatically enrolled for user-type certificates when they log on. Automatic enrollment of user certificates is transparent to the user and provides support for enabling Public Key Infrastructure (PKI) applications (smart card logon, Encrypting File System (EFS), Secure Socket Layer (SSL), S/MIME, and others) within an Active Directory environment.
Request Certificates Using the Certificate Request Wizard To request a certificate from a Windows Server 2003 Certificate Server within an Active Directory domain, use the Certificate Request Wizard accessible from the Certificates snap-in.
Version 3.0, 07/11/2007
This wizard guides the user through the following steps: Selecting the CA to which a request is being submitted. Note: Only Enterprise CAs that are available in the local Windows domain will be able to issue certificates requested through the Certificate Request Wizard. Selecting the appropriate certificate template to use for the new certificate. Note: Certificate templates provide predefined configurations settings for the requested certificate. Certificate templates describe the purpose for which the requested certificate is to be used. The list of certificate templates that is available to the user is determined by the certificate types which the CA is configured to issue and whether the user has been granted the access rights to the certificate template by the CA Administrator. (Optional) Using Advanced Options in the Certificate Request Wizard to select the Cryptographic Service Provider (CSP) for the key pair associated with the certificate request.
Only Basic EFS and EFS Recovery Agent certificates have their associated private keys marked as available for export when the Certificate Request Wizard is used. The Certificate Request Wizard can also be used to request a new certificate from an Enterprise CA by using an existing key pair that is already associated with another certificate.
Processing of Certificate Requests Certificates can be manually or automatically requested from a Windows Server 2003 Enterprise CA. The user auto-enrollment features used with an Enterprise CA support both automatic and pending certificate requests and renewals. The request is held until administrative approval is received or the verification process is completed. The CA may be configured to issue certificates automatically; otherwise the request will remain pending until a Certificate Manager approves the request and issues the certificate. Once the certificate has been issued, the auto-enrollment process will complete and install the certificates automatically on the requesters computer. The process for renewing expired user certificates can also take advantage of the auto-enrollment mechanism. Certificates are automatically renewed on behalf of the user dependent upon the specifications in the certificate template.
Version 3.0, 07/11/2007
Certificate Request Procedures The subsections below define the procedures for using the Certificates snap-in and the Certificate Request Wizard to: Request a new certificate, Select an existing certificate and request a similar certificate with a new key, Select an existing certificate and request a similar certificate with the Same key, Renew an existing certificate with a new key, and Renew an existing certificate with the same key.
Procedures are also provided for verifying the CRL Distribution Point and for importing a CA certificate and the associated CRL. Note: The TOE does not include the use of Windows Certificate Services Web Pages. Therefore, certificate request procedures using Windows Certificate Services Web pages are not covered in this document.
Request a New Certificate 1. Log on to the computer with the user account that is making the certificate request. 2. Click Start and select Run. 3. Type mmc /s in the Open text field and click OK. This opens the Microsoft Management Console (MMC).
4. From the File menu, select Add/Remove Snap-in. 5. In the Add/Remove Snap-in window, click the Add button. An Add Standalone Snap-in window will appear displaying a list of available snap-ins. 6. Select the Certificates snap-in, click Add and click Close on the An Add Standalone Snap-in window.
Version 3.0, 07/11/2007
7. Click OK on the Add/Remove Snap-in window. 8. In the console tree, expand Certificates Current User. 9. Right-click Personal and select All Tasks, then select Request New Certificate.
10. If there is no trusted CA available or the user does not have appropriate permissions to request the certificate, a warning message will appear and the certificate request will fail. Contact the CA Administrator or the local System Administrator for assistance.
Version 3.0, 07/11/2007
Note: To request a certificate, users need both Request Certificates permission on the CA and Enroll permission on each certificate template associated with a certificate that the user wishes to request. Setting these permissions requires administrative access to the CA and its certificate templates.
11. If a trusted CA is available and the user has permissions to make the certificate request, the Certificate Request Wizard will appear. Click Next.
12. From the list of Certificate types, select the type of certificate being requested. In this case, select User.
13. To accept the default CSP and CA for the certificate, click Next and go to Step 15. Otherwise, to optionally select from the available CSPs and CAs, check the Advanced box and click Next. Note
Version 3.0, 07/11/2007
that the default CSP is Microsoft Enhanced Cryptographic Provider v1.0 with a key length of 1024 bits. 14. In the Cryptographic Service Provider selection box, select a CSP (Recommendation: Microsoft Enhanced Cryptographic Provider v1.0). Select a key length from the Key Length drop down menu. Key length options will vary depending on the CSP selected. (Recommendation: For the Microsoft Enhanced Cryptographic Provider v1.0 CSP, select a key length of 2048). Check the Mark this key as exportable check box, to allow the key to be backed up. Optionally, check the Enable strong private key protection check. The Enable strong private key protection option is used to ensure that the users private key is not used without the users knowledge. By enabling this option, the user will be prompted for a password every time the private key is used. Click Next.
15. In the Certificate Authority window of the Certificate Request Wizard, verify that the appropriate CA is selected in the CA box. To choose a different CA, click the Browse button to select a CA from the available list. Once a CA has been selected, click the Next button.
16. In the Certificate Friendly Name and Description window of the Certificate Request Wizard, enter a user friendly name for the certificate and a description, if desired.
Version 3.0, 07/11/2007
17. The Completing the Certificate Request window of the Certificate Request Wizard will appear displaying the specified certificate information. To make corrections, click the Back button. To complete the certificate request process, click Finish.
18. If the requested certificate is set to allow auto-enrollment, the user account has been granted autoenrollment permission for the requested certificate, and the CA has been set to automatically issue certificates, the user will receive a message indicating that the certificate request was successful as soon as the CA has processed the certificate request.
19. If auto-enrollment has not been enabled for the certificate, or the CA has been set to hold certificates pending approval of the Certificate Manager, the user will receive a message indicating that the certificate request was received by the CA and the certificate will be issued upon approval by the Certificate Manager.
Version 3.0, 07/11/2007
20. Once the requested certificate is issued, it will appear in the user's Certificates snap-in as shown below.
21. If finished, close the Certificates snap-in.
Request Certificate with New Key 1. Log on to the computer with the user account that is making the certificate request. 2. Click Start and select Run. 3. Type mmc /s in the Open text field and click OK. This opens the MMC. 4. From the File menu, select Add/Remove Snap-in. 5. In the Add/Remove Snap-in window, click the Add button. An Add Standalone Snap-in window will appear displaying a list of available snap-ins. 6. Select the Certificates snap-in, click Add and click close on the An Add Standalone Snap-in window. 7. Click OK on the Add/Remove Snap-in window. 8. In the console tree, expand Certificates Current User. 9. Expand Personal and then select Certificate. 10. In the details pane, right-click on a certificate to request a similar certificate with a new key. Point to All Tasks, and then select Request Certificate with New Key to start the Certificate Request Wizard.
Version 3.0, 07/11/2007
11. If there is no trusted CA available or the user does not have appropriate permissions to request the certificate, a warning message will appear and the certificate request will fail. Contact the CA Administrator or the local System Administrator for assistance. Note: To request a certificate, users need both Request Certificates permission on the CA and Enroll permission on each certificate template associated with a certificate that the user wishes to request. Setting these permissions requires administrative access to the CA and its certificate templates.
12. If a trusted CA is available and the user has permissions to make the certificate request, the Certificate Request Wizard will appear. Click Next and follow the same procedures previously defined for requesting certificate enrollment via Certificate Request Wizard. 13. Upon completing the procedures a new certificate, with a different encryption key, will appear in the Certificates MMC.
Version 3.0, 07/11/2007
14. If desired, verify that the newly requested certificate has a different key than the original as follows: Double-click on the original certificate. A Certificate dialog box will appear.
Click on the Details tab. Find and select the Subject Key Identifier in the Field and Value selection window.
Version 3.0, 07/11/2007
Copy the key value shown in the lower detail window. Repeat the last three procedures for the new certificate and compare the key values to verify that they are different.
Example: Key Value of original certificate: 46 e7 46 61 79 0b 7f 9c b0 61 a9 d3 36 c5 0b 6a 15 a0 fb 01 Key Value of new certificate: 95 74 ac 70 5b 1b b0 75 43 89 e7 55 d5 66 a6 b6 47 e8 f9 74 15. If finished, close the Certificates snap-in.
Request Certificate with Same Key 1. Log on to the computer with the user account that is making the certificate request. 2. Click Start and select Run. 3. Type mmc /s in the Open text field and click OK. This opens the MMC. 4. From the File menu, select Add/Remove Snap-in. 5. In the Add/Remove Snap-in window, click the Add button. An Add Standalone Snap-in window will appear displaying a list of available snap-ins. 6. Select the Certificates snap-in, click Add and click close on the An Add Standalone Snap-in window. 7. Click OK on the Add/Remove Snap-in window.
Version 3.0, 07/11/2007
8. In the console tree, expand Certificates Current User. 9. Expand Personal and then select Certificate. 10. In the details pane, right-click on a certificate to request a similar certificate with a new key. Point to All Tasks, and then select Request Certificate with New Key to start the Certificate Request Wizard.
11. If there is no trusted CA available or the user does not have appropriate permissions to request the certificate, a warning message will appear and the certificate request will fail. Contact the CA Administrator or the local System Administrator for assistance. Note: To request a certificate, users need both Request Certificates permission on the CA and Enroll permission on each certificate template associated with a certificate that the user wishes to request. Setting these permissions requires administrative access to the CA and its certificate templates.
12. If a trusted CA is available and the user has permissions to make the certificate request, the Certificate Request Wizard will appear. Click Next and follow the same procedures previously defined for requesting certificate enrollment via Certificate Request Wizard. The exception will be that when after the Advanced box, only the option to select a CA will be presented. The selection options for the CSP will not be provided since the same key as the currently selected certificate will be used. 13. Upon completing the procedures a new certificate, with the same encryption key used in the original certificate, will appear in the Certificates MMC.
Version 3.0, 07/11/2007
14. If desired, verify that the newly requested certificate has a same key as the original as follows: Double-click on the original certificate. A Certificate dialog box will appear.
Click on the Details tab. Find and select the Subject Key Identifier in the Field and Value selection window.
Version 3.0, 07/11/2007
Copy the key value shown in the lower detail window. Repeat the last three procedures for the new certificate and compare the key values to verify that they are the same.
Example: Key Value of original certificate: 95 74 ac 70 5b 1b b0 75 43 89 e7 55 d5 66 a6 b6 47 e8 f9 74 Key Value of new certificate: 95 74 ac 70 5b 1b b0 75 43 89 e7 55 d5 66 a6 b6 47 e8 f9 74 15. If finished, close the Certificates snap-in.
Renew Certificate with New Key 1. Log on to the computer with the user account that is making the certificate request. 2. Click Start and select Run. 3. Type mmc /s in the Open text field and click OK. This opens the Microsoft Management Console. 4. From the File menu, select Add/Remove Snap-in. 5. In the Add/Remove Snap-in window, click the Add button. An Add Standalone Snap-in window will appear displaying a list of available snap-ins. 6. Select the Certificates snap-in, click Add and click close on the An Add Standalone Snap-in window. 7. Click OK on the Add/Remove Snap-in window.
Version 3.0, 07/11/2007
8. In the console tree, expand Certificates Current User. 9. Expand Personal and then select Certificate. 10. In the details pane, right-click on a certificate to renew it using a new encryption key. Point to All Tasks, and then select Renew Certificate with New Key.
11. If the certificate selected for renewal was not obtained from the local CA, it may not contain sufficient information to generate a renewal request and the request will fail. Contact the CA Administrator or the local System Administrator for assistance.
12. If the certificate selected for renewal contains sufficient information to make the request and the Certificate Request Wizard will appear. Click Next.
Version 3.0, 07/11/2007
13. To use the default values to renew the certificate, click the Yes, use default values radio button. To provide different certificate renewal settings, click the No, I want to provide my own settings radio button. Click Next.
14. If using the default values, skip to step 14 where the Completing the Certificate Renewal Wizard window is displayed. Otherwise, if the No, I want to provide my own settings radio button was selected, the Cryptographic Service Provider window of the Certificate Renewal Wizard is displayed. 15. Select the required CSP and the key length (measured in bits) of the public key associated with the certificate (Recommendations: The Microsoft Enhanced Cryptographic Provider v1.0 CSP, with a key length of 2048. Check the Mark this key as exportable checkbox to allow certificate backups. Optionally, check the Enable strong private key protection check. The Enable strong private key protection option is used to ensure that the users private key is not used without the users knowledge. By enabling this option, the user will be prompted for a password every time the private key is used. Click Next.
16. If the Advanced check box was previously selected, the Certification Authority window is displayed. Make sure the appropriate CA is displayed in the CA: field. If not, use the Browse button to select from a list of available CAs to select the name of the certification authority that will issue the certificate. Click Next.
Version 3.0, 07/11/2007
17. The Completing the Certificate Request window of the Certificate Request Wizard will appear displaying the specified certificate information. To make corrections, click the Back button. To complete the certificate request process, click Finish.
18. If the requested certificate allows auto-enrollment, the user account has been granted autoenrollment permission for the requested certificate, and the CA has been set to automatically issue certificates, the user will receive a message indicating that the certificate request was successful as soon as the CA has processed the certificate request. 19. If auto-enrollment has not been enabled for the certificate, or the CA has been set to hold certificates pending approval of the Certificate Manager, the user will receive a message indicating that the certificate request was received by the CA and the certificate will be issued upon approval by the Certificate Manager. 20. Upon completing the procedures, the selected certificate will be renewed with the different encryption key than the one in the original certificate. 21. If finished, close the Certificates snap-in.
Version 3.0, 07/11/2007
Renew Certificate with Same Key 1. Log on to the computer using an account that is assigned the CA Officer role. 2. Click Start and select Run. 3. Type mmc /s in the Open text field and click OK. This opens the MMC. 4. From the File menu, select Add/Remove Snap-in. 5. In the Add/Remove Snap-in window, click the Add button. An Add Standalone Snap-in window will appear displaying a list of available snap-ins. 6. Select the Certificates snap-in, click Add and click close on the An Add Standalone Snap-in window. 7. Click OK on the Add/Remove Snap-in window. 8. In the console tree, expand Certificates Current User. 9. Expand Personal and then select Certificate. 10. In the details pane, right-click on a certificate to renew it using the same encryption key. Point to All Tasks, and then select Renew Certificate with Same Key.
11. If the certificate selected for renewal was not obtained from the local CA, it may not contain sufficient information to generate a renewal request and the request will fail. Contact the CA Administrator or the local System Administrator for assistance.
12. If the certificate selected for renewal contains sufficient information to make the request and the Certificate Request Wizard will appear. Click Next and follow the same procedures previously defined for Renew Certificate with New Key via Certificate Renewal Wizard. 13. If the requested certificate allows auto-enrollment, the user account has been granted autoenrollment permission for the requested certificate, and the CA has been set to automatically issue certificates, the user will receive a message indicating that the certificate request was successful as soon as the CA has processed the certificate request.
Version 3.0, 07/11/2007
14. If auto-enrollment has not been enabled for the certificate, or the CA has been set to hold certificates pending approval of the Certificate Manager, the user will receive a message indicating that the certificate request was received by the CA and the certificate will be issued upon approval by the Certificate Manager. 15. Upon completing the procedures, the selected certificate will be renewed with the same encryption key used in the original certificate. 16. If finished, close the Certificates snap-in.
Verify the Certificate Revocation List Distribution Point 1. Log on to the computer with a regular user account to verify the origin of the CRL associated with that user's Certificate. 2. Click Start and select Run. 3. Type mmc /s in the Open text field and click OK. This opens the MMC. 4. From the File menu, select Add/Remove Snap-in. 5. In the Add/Remove Snap-in window, click the Add button. An Add Standalone Snap-in window will appear displaying a list of available snap-ins. 6. Select the Certificates snap-in, click Add and click close on the An Add Standalone Snap-in window. 7. Click OK on the Add/Remove Snap-in window. 8. In the console tree, expand Certificates Current User. 9. Expand Personal and then select Certificate 10. In the details pane, double-click on the user's certificate to open the Certificate properties dialog window.
Version 3.0, 07/11/2007
11. Click on the Details tab. Find and select the Field item described as CRL Distribution Points. Details defining the distribution point of the CRL associated with the current certificate can be viewed in the in the lower detail window.
Version 3.0, 07/11/2007
12. Click OK on Certificate properties dialog window when finished and close the Certificates snap-in.
ADFS Enabled Web Applications

The Target of Evaluation (TOE) is configured with Active Directory Federation Services (ADFS) for authorizing users to Web-based applications that are protected by ADFS. ADFS provides Web single sign-on (SSO) technologies to authorize a user to multiple Web applications over the life of a single browser session. When the TOE is configured with ADFS and a user attempts to access an ADFS-enabled application, an SSL/TLS session is established with the clients Web browser. The Web browser does not allow the client access to the requested page because the client does not yet have a security token to present to the Web server. In response, behind the scenes, the TOE redirects the users request to ADFS where the user is validated against an Active Directory store and a Security Assertion Markup Language (SAML) token is issued to the client. After the client receives the token, the client is then authorized to access the ADFSenabled application for as long as the token is valid. There are two different ADFS scenarios set up in the TOE: Federated Web SSO with forest trust Web SSO
In the federated Web SSO with forest trust scenario, the user is accessing a Web-based application from a domain-joined computer that is either in the local network (called the resource realm) or in the network of a trusted partner (the account realm). The first time the user tries to access the ADFS-enabled Web application, the user is presented with a Web page that prompts for the users realm. The user can then select his or her home realm. ADFS then passes a token to the users Web browser that authorizes the user to access the Web application. Until the token expires or the user signs out of the application, the user can continue to access ADFS-enabled applications in the resource realm without signing on again. Note that deleting the cookies from the Web browser can also terminate the session. In the Web SSO scenario, the user is accessing a Web-based application from an external computer that is not joined to any domain but is rather connected to a perimeter network that has restricted access to the local network. Each time the user tries to access the ADFS-enabled Web application in a new browser session, the user is presented with a Web page that prompts for the users Active Directory user name and password. This information is passed to an ADFS server in the perimeter network serving as a proxy to the real federation server in the internal network that validates the users account and password against the Active Directory store. The federation server issues the security token, which is passed to the client by way of the federation server proxy. Then the client is authorized to access the ADFS-enabled Web application.
Configuring the Web Browser for Accessing ADFS-enabled Web Applications

In a federated Web SSO with forest trust scenario, in order for the client computer to access a Web site that uses Active Directory Federation Services (ADFS), the clients Web browser must be configured to trust the account federation server Web site. For example, in Internet Explorer the Local Intranet Web content zone must be configured to trust the account federation server Web site. Use the following procedure to configure the Internet Explorer settings so that the browser settings will trust the account federation server. Any member of the Users group on the local computer can complete this procedure.
Version 3.0, 07/11/2007
Configure browser settings to trust the account federation server The following example demonstrates the configuration of settings used by Internet Explorer. 1. In Windows XP Professional SP2, click Start, and run Control Panel. Note: If Control Panel is in Category View, click Network and Internet Connections. 2. Click the Internet Options Control Panel icon. 3. On the Security tab, click the Local intranet icon, and then click Sites. 4. Click Advanced, and in Add this Web site to the zone, type https:// and the address of the account federation server (e.g., https://<AcctFedSvrFQDN>), and then click Add. Note: To obtain the address of the account federation server contact the ADFS system administrator. 5. Click OK three times. In the Web SSO scenario, where the client is on an external network, no special configuration is required for the clients Web browser.
Using Federated Web Applications

The Target of Evaluation (TOE) is includes the use of Active Directory Federation Services (ADFS) for authorizing users to Web-based applications that are protected by ADFS. ADFS provides Web single sign-on (SSO) technologies to authorize a user to multiple Web applications over the life of a single browser session. When the TOE is configured with ADFS and a user attempts to access an ADFS-enabled application, an SSL/TLS session is established with the clients Web browser. The Web browser does not allow the client access to the requested page because the client does not yet have a security token to present to the Web server. In response, behind the scenes, the TOE redirects the users request to ADFS where the user is validated against an Active Directory store and a Security Assertion Markup Language (SAML) token is issued to the client. After the client receives the token, the client is then authorized to access the ADFS-enabled application for as long as the token is valid. There are two different ADFS scenarios set up in the TOE: Federated Web SSO. In the Federated Web SSO scenario, the user is accessing a Web-based application from a domain-joined computer that is either in the local network (called the resource realm) or in the network of a trusted partner (the account realm). Note: A realm represents a single unit of security administration or trust, such as a domain. A users home realm is typically the network that he or she normally logs on to. The first time the user tries to access the ADFS-enabled Web application, the user is presented with a Web page that prompts for the users realm. The user can then select his or her home realm. ADFS then passes a token to the users Web browser that authorizes the user to access the Web application. Until the token expires or the user signs out of the application, the user can continue to access ADFS-enabled applications in the resource realm without signing on again. Note that deleting the cookies from the Web browser can also terminate the session. Web SSO. In the Web SSO scenario, the user is accessing a Web-based application from an external computer that is not joined to any domain but is rather connected to a perimeter network that has restricted access to the local network. Each time the user tries to access the ADFS-enabled Web application in a new browser session, the user is presented with a Web page that prompts for the users Active Directory user name and password. This information is passed to an ADFS server in the perimeter network serving as a proxy to the real federation server in the internal network that
Version 3.0, 07/11/2007
validates the users account and password against the Active Directory store. The federation server issues the security token, which is passed to the client by way of the federation server proxy. Then the client is authorized to access the ADFS-enabled Web application.
Configuring the Web Browser for Accessing ADFS-enabled Web Applications

In a Federated Web SSO scenario, in order for the client computer to access a Web site that uses ADFS, the clients Web browser must be configured to trust the account federation server Web site. For example, in Internet Explorer, the Local Intranet Web content zone must be configured to trust the account federation server Web site. Use the following procedure to configure the Internet Explorer settings so that the browser settings will trust the account federation server. Any member of the Users group on the local computer can complete this procedure, but only it will only affect the Web browser settings of the currently logged on user account.
Configure browser settings to trust the account federation server The following example demonstrates the configuration of settings used by Internet Explorer. 1. In Windows XP Professional with SP2, click Start, and select Control Panel. Note: If Control Panel is in Category View, click Network and Internet Connections. 2. Click the Internet Options Control Panel icon. 3. On the Security tab, click the Local intranet icon, and then click Sites. 4. Click Advanced, and in Add this Web site to the zone, type the secure URL to the account federation server (https://<AcctFedSvrFQDN>), and then click Add. Note: To obtain the address of the account federation server contact the ADFS administrator. 5. Click OK three times. In the Web SSO scenario, where the client is on an external network, no special configuration is required for the clients Web browser.
Using Federated Web Applications

Active Directory Federation Services (ADFS) is a component in Windows Server 2003 R2 with SP2 that provides Web single sign-on technologies to authenticate a user to multiple Web applications over the life of a single browser session. The procedures for accessing the sample applications are outlined in Accessing an ADFS-enabled Web Application later in this chapter. When the user first accesses a Web site that uses ADFS for authentication and authorization, an SSL/TLS session is established with the clients Web browser. The Web server does not allow the client access to the requested page because the client does not have an authentication token to present to the Web server. If the user is accessing the ADFS-enabled application from a network that is configured as a federated partner to the users internal network (as opposed to an external or perimeter network with no direct access to the protected internal network), the scenario works as follows: 1. The user must wait while the Web server is redirected to the default logon Uniform Resource Locator (URL) at the resource federation server. The resource federation server then determines the us ers home organization (or realm). The resource federation server responds to the client and provides
Version 3.0, 07/11/2007
the Client Realm Discovery page, where the user selects his or her home realm from a drop-down list. Typically, the realm is listed as the users organization or division name. The Web browser is then redirected to the logon page for the account federation server that exists in the users realm. 2. The account Federation Service and the Active Directory account information are used to validate the users credentials and obtain attributes for building a Security Assertion Markup Language (SAML) security token. The security token is stored as a cookie in the clients Web browser. At that point, the Web browser is redirected to the resource federation server, where it presents its cookie. The federation server checks the security token and then issues a security token that can be used to access the Web server. 3. The Web browser presents the security token issued by the federation server to the Web server. The Web server evaluates the security token and, if acceptable, it creates an authentication token that is written to the browser and then used to access the Web application. The user can continue to access the application, provided the Web session remains open and the token has not expired. The default lifetime of a token is 60 minutes. After the cookie expires, the user is prompted again for a home realm upon accessing the ADFS-enabled application. Note: If the user is accessing the ADFS-enabled application from a perimeter network that is not a partner in a federation trust (i.e., in a Web SSO scenario instead of a Federated Web SSO scenario), the process is similar except that there is no account federation server. Instead, there is one federation server on the users internal network and a federation server proxy in the perimeter network, and ADFS prompts the user for authentication. If the authentication method in use is Windows integrated authentication, then the user is presented with a Web page requesting a username/password. The user is not prompted for a home realm in this scenario, just for a user name and password.
Types of ADFS-aware Web applications

There are two types of ADFS-enabled applications that the user can access: Claims-aware applications. Claims are statements (for example, name, identity, key, group, privilege, or capability) made about users, and understood by both partners in an ADFS federation, that are used for authorization purposes in an application. A claims-aware application is a Microsoft ASP.NET application that has been written using the ADFS library. This type of application is fully capable of using ADFS claims to make authorization decisions directly. A claims-aware application accepts claims that the Federation Service sends in ADFS security tokens. Windows NT token-based applications. A Windows NT tokenbased application is an Internet Information Services (IIS) application that has been written to use traditional Windows native authorization mechanisms. This type of application is not prepared to consume ADFS claims. Windows NT tokenbased applications can be used only by Windows users from the local realm or any realm that is trusted by the local realm that is, only by users who can log on to the computer with Windows NT tokenbased authentication techniques. However, because the type of application is mostly irrelevant to the user accessing it, the user does not need to concern himself with the type of application. ADFS provides the proper prompts for the user to respond to in order to access ADFS applications authorized for viewing by that user.
Accessing ADFS-enabled Sample Web Applications from the Account Realm: Federated Web SSO Scenario Use the following procedure to access the sample claims-aware application from a client in the account realm that is authorized for that application in a Federated Web SSO ADFS scenario.
Version 3.0, 07/11/2007
Access a claims-aware application from the account realm The following procedures demonstrate how a user accesses a claims-aware application. The claimsaware application used in this example is called Claimapp and is configured on the Web server to use port 8081. Note: Contact the ADFS administrator for the URL address of the claims-aware application. On the ADFS client computer that is in the account domain: 1. Log on to the computer as an authorized user in the account domain. Note: The user account must belong to a group that has been granted access to the desired claimsaware application. Contact the ADFS administrator assistance in configuring access to the claimsaware application. 2. Click Start, click Run, type the URL address and port number of the claims-aware application (e.g., https://<WebSvrFQDN>:8081/claimapp/), and press the Enter key. A Web browser is launched. 3. If a Security Alert window is displayed indicating You are about to view pages over a secure connection, select the check box for In the future do not show this warning, and click OK. Wait for the Web page to open. 4. If prompted with one or more Security Alert windows indicating a potential problem with the security certificate, click Yes each time such an alert appears. Note: To avoid future certificate prompts, instead of choosing yes in the Security Alert dialog box, the user can choose View Certificate, select the Details tab, and click Install Certificate. In the Welcome to the Certificate Import Wizard window, click Next, ensure that the radio button for Automatically select the certificate store based on the type of certificate is selected, click Next, click Finish, click OK at the import was successful message, click OK again, and select Yes in the Security Alert dialog box. This procedure can be repeated for each Security Alert dialog box presented on the client. 5. When the Web page opens prompting for a home realm, from the drop-down list select the account realm name (<AccountDomainOrganizationName>), and then click Submit. 6. The sample application appears in the browser, displaying the claims that were sent to the Web server in the SingleSignOnIdentity.SecurityPropertyCollection section. 7. Without signing out (or clicking any links in the sample Web page), exit the Web browser. Remain logged on and follow the next procedure. 0.
Access the secondary claims-aware application from the account realm Use the following procedure to access a second sample claims-aware application from a client in the account realm that is authorized for that application in a Federated Web SSO scenario. The claimsaware application used in this example is called Claimapp2 and uses port 8083. Note: Contact the ADFS administrator for the URL address of the claims-aware application. On the ADFS client computer in the account domain: 1. Click Start, click Run, type the address and port number of the second claims-aware application (e.g., https://<WebSvrFQDN>:8083/claimapp2/), and press the Enter key.
Version 3.0, 07/11/2007
Note: The user account must belong to a group that has been granted access to the desired claimsaware application. Contact the ADFS administrator assistance in configuring access to the claimsaware application. 2. When the sample Web page opens, there should not be a prompt for a home realm, because a token was received when accessing Claimapp in the previous procedure. 3. The secondary sample application appears in the browser, displaying the claims that were sent to the Web server in the SingleSignOnIdentity.SecurityPropertyCollection section. 4. Click the Sign out link on the Web page and exit the Web browser. 5. Log off Windows by clicking Start, Log Off, and Log Off again.0.
Access the Windows NT token-based1 application from the account realm Use the following procedure to access a token-based application from a client in the account realm that is authorized for that application in a Federated Web SSO scenario. The token-based application used in this example uses port 8091. Note: Contact the ADFS system administrator for the URL address of the token-based application. On the ADFS client computer in the account domain: 1. Log on to the computer as an authorized user in the local account domain. Note: The user account must belong to a group that has been granted access to the desired tokenbased application. Contact the ADFS administrator assistance in configuring access to the tokenbased application. 2. Click Start, click Run, type the URL address of the Web site hosting the token-based application (e.g., https://<WebSvrFQDN>:8091/), and press the Enter key. 3. If a Security Alert window is displayed indicating You are about to view pages over a secure connection, select the check box for In the future do now show this warning, and click OK. Wait for the Web page to open. 4. If prompted with one or more Security Alert windows indicating a potential problem with the security certificate, click Yes each time such an alert appears. Note: To avoid future certificate prompts, instead of choosing yes in the Security Alert dialog box, the user can choose View Certificate, select the Details tab, and click Install Certificate. In the Welcome to the Certificate Import Wizard window, click Next, ensure that the radio button for Automatically select the certificate store based on the type of certificate is selected, click Next, click Finish, click OK at the import was successful message, click OK again, and select Yes in the Security Alert dialog box. This procedure can be repeated for each Security Alert dialog box presented on the client. 5. At this point the Token-based Sample Application appears in the browser, displaying a single line of text indicating the application type on a colored background. 6. In the browser, click Tools, click Internet Options, and click the Delete Cookies button on the General tab. Click OK twice and then exit the browser.
1 Hereafter referred to as simply token-based application. Copyright 2008 Microsoft Corporation. All Rights Reserved. 102
Version 3.0, 07/11/2007
7. Click Start, click Run, type the URL address of the Web site hosting the token-based application (e.g., https://<WebSvrFQDN>:8091/), and press the Enter key. 8. If a Security Alert window is displayed indicating You are about to view pages over a secure connection, select the check box for In the future do now show this warning, and click OK. Wait for the Web page to open. 9. If prompted with one or more Security Alert windows indicating a potential problem with the security certificate, click Yes each time such an alert appears. 10. Or, to avoid future certificate prompts, instead of choosing yes in the Security Alert dialog box, the user can choose View Certificate, select the Details tab, and click Install Certificate. In the Welcome to the Certificate Import Wizard window, click Next, ensure that the radio button for Automatically select the certificate store based on the type of certificate is selected, click Next, click Finish, click OK at the import was successful message, click OK again, and select Yes in the Security Alert dialog box. This procedure can be repeated for each Security Alert dialog box presented on the client. 11. The sample application appears in the browser without prompting the user for a home realm because a token was received when accessing the sample application earlier in the procedure. 12. Exit the Web browser and log off of Windows by clicking Start, Log Off, and Log Off again.0.
Accessing ADFS-enabled Web Applications from within the Resource Realm: Federated Web SSO Scenario Use the following procedure to access a claims-aware application from a computer within the resource realm. The claims-aware application used in this example is called Claimapp and uses port 8081. Note: Contact the ADFS system administrator for the URL address of the claims-aware application.
Access the claims-aware application from the resource realm On the ADFS client computer that is in the resource domain: 1. Log on to the computer as an authorized user in the local resource domain. Note: The user account must belong to a group that has been granted access to the desired claimsaware application. Contact the ADFS administrator assistance in configuring access to the tokenbased application. 2. Click Start, click Run, type the URL address of the second claims-aware application (e.g., https://<WebSvrFQDN>:8081/claimapp/), and press the Enter key. 3. If a Security Alert window is displayed indicating You are about to view pages over a secure connection, select the check box for In the future do now show this warning, and click OK. Wait for the page to open.
4. When the Web page opens prompting for a home realm, ensure that the resource realm (<ResourceDomainOrganizationName>) is selected in the drop-down list, and then click Submit. 5. The Claims-aware Sample Application appears in the browser, displaying the claims that were sent to the Web server in the SingleSignOnIdentity.SecurityPropertyCollection section. 6. Exit the Web browser, then repeat Step 2 above. Single sign-on allows the user to access Claimapp without being prompted for a home realm again, and the Claims-aware Sample Application appears in the browser, displaying the claims that were sent to the Web server in the SingleSignOnIdentity.SecurityPropertyCollection section.
Version 3.0, 07/11/2007
7. Click the Sign out link on the Web page and exit the Web browser. 8. Log off Windows by clicking Start, Log Off, and Log Off again.0.
Accessing ADFS-enabled Web Applications: Web SSO Scenario Use the following procedure to access a claims-aware application from an external computer in the perimeter network of a Web SSO scenario. The claims-aware application used in this example is called Claimapp and uses port 8081. Note: Contact the ADFS system administrator for the URL address of the claims-aware application.
Access the claims-aware application from an external computer On the external client computer: 1. Log on locally to the external computer. 2. Click Start, click Run, type the URL address of the claims-aware application (e.g., https://<WebServerFQDN>:8081/claimapp/), and click Open. 3. If a Security Alert window is displayed indicating You are about to view pages over a secu re connection, select the check box for In the future do now show this warning, and click OK. Wait for the page to open. 4. If prompted with one or more Security Alert windows indicating a potential problem with the security certificate, click Yes each time such an alert appears. Or, to avoid future certificate prompts, instead of choosing yes in the Security Alert dialog box, the user can choose View Certificate, select the Details tab, and click Install Certificate. In the Welcome to the Certificate Import Wizard window, click Next, ensure that the radio button for Automatically select the certificate store based on the type of certificate is selected, click Next, click Finish, click OK at the import was successful message, click OK again, and select Yes in the Security Alert dialog box. This procedure can be repeated for each Security Alert dialog box presented on the client. 5. When the CollectInitialCredentials Active Directory Federation Services Web page opens prompting for a username and password, type the name of a user account that is in the domain hosting the claims-aware application, type the users domain password in the appropriate field, and then click Submit. Note: Within the TOE, the Web SSO scenario allows access to ADFS-enabled applications only to users that have valid domain accounts. The Web SSO scenario allows these users to access ADFSenabled applications from computers that are external to the domain where their user account exists. Additionally, the user account must have been granted access to the desired claims-aware application. Contact the ADFS administrator assistance in configuring access to the claims-aware application. 6. The Claims-aware Sample Application appears in the browser, displaying the claims that were sent to the Web server in the SingleSignOnIdentity.SecurityPropertyCollection section. 7. Exit the Web browser, then repeat Step 1 above. Single sign-on allows the user to access Claimapp without being prompted for a home realm again, and the Claims-aware Sample Application appears in the browser, displaying the claims that were sent to the Web server in the SingleSignOnIdentity.SecurityPropertyCollection section. 8. Click the Sign out link on the Web page and exit the Web browser. Remain logged on to Windows for the next procedure.0.
Version 3.0, 07/11/2007
Access the Windows NT token-based application from an external computer Use the following procedure to access a Windows NT token-based application from an external client in the perimeter network of a Web SSO scenario. On the external client computer: 1. Click Start, click Run, type the address and port number of the claims-aware application (e.g., https://<WebServerFQDN>:8081/claimapp/), and click Open. 2. If prompted with one or more Security Alert windows indicating a potential problem with the security certificate, click Yes each time such an alert appears. Or, to avoid future certificate prompts, instead of choosing yes in the Security Alert dialog box, the user can choose View Certificate, select the Details tab, and click Install Certificate. In the Welcome to the Certificate Import Wizard window, click Next, ensure that the radio button for Automatically select the certificate store based on the type of certificate is selected, click Next, click Finish, click OK at the import was successful message, click OK again, and select Yes in the Security Alert dialog box. This procedure can be repeated for each Security Alert dialog box presented on the client. 3. The token-based sample application appears in the Web browser without prompting for a username or password. Note: If a session was not first established with another ADFS-enabled application, or if the cookie has expired, a username/password prompt is displayed when accessing the Windows NT tokenbased application. 4. Exit the Web browser.0.
Troubleshooting ADFS-enabled Application Failures

If the client fails to gain access to the ADFS-enabled Web application, an error is generated and the Uniform Resource Locator (URL) in the browser indicates the point of failure. Common errors are Domain Name System (DNS) failures and 401 access denied errors. In the Federated Web SSO scenario, assuming there is good connectivity and name resolution between the account and resource domains, the user can try to delete cookies from the browser and exit the browser to correct the problem before contacting the systems administrator for assistance. For example, if the user is using Internet Explorer to access the ADFS-enabled application, the following procedure can be used to delete cookies. Any member of the Users group on the local computer can complete this procedure.
Delete all cookies in Internet Explorer 1. In Internet Explorer, on the Tools menu, click Internet Options. 2. On the General tab, click Delete Cookies. 3. In the Delete Cookies dialog box, click OK. 4. In the Internet Options dialog box, click OK. 5. Exit the browser and try to access the ADFS-enabled Web application again. If this does not resolve the problem, contact a systems administrator.
Version 3.0, 07/11/2007
4. Acronyms
3DES AES API BIOS CA CAPP CC CDP CD-ROM CIMC CP CPS CRL CryptoAPI CSP DC DES DDF DLL DPAPI DRA DRF EFS FAT FEK FIPS FSRTL HTTP ID IE IIS IP IPSec IT Triple-DES Advanced Encryption Standard Application Programming Interface Basic Input-Output System Certification Authority Controlled Access Protection Profile Common Criteria CRL Distribution Point Compact DiskRead Only Memory Certificate Issuing and Management Components Certificate Policy Certification Practices Statement Certificate Revocation List Cryptographic API Cryptographic Service Provider Domain Controller Data Encryption Standard Data Decryption Field Dynamic Link Library Data Protection API Data Recovery Agent Data Recovery Field Encrypted File System File Allocation Table File Encryption Key Federal Information Processing Standards File System RunTime Library HyperText Transfer Protocol Identification Internet Explorer Internet Information Services Internet Protocol Internet Protocol Security Information Technology
Version 3.0, 07/11/2007
LPC LSA MB MMC NTFS PIN PKCS PKI RSA S/MIME SP SSL SSL/PCT ST TLS TOE TSF UI VPN WebDAV
Local Procedure Call Local Security Authority MegaByte Microsoft Management Console New Technology File System Personal Identification Number Public Key Cryptography Standard Public Key Infrastructure Rivest, Shamir, and Adleman Secure/Multipurpose Internet Mail Extensions Service Pack Secure Socket Layer Secure Socket Layer/Personal Communication Technology Security Target Transport Layer Security Target of Evaluation TOE Security Function User Interface Virtual Private Network Web Distributed Authoring and Versioning
Version 3.0, 07/11/2007
5. References
Encrypting and decrypting data |http://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/enus/sag_seconceptsunencrypt.mspx Remote EFS Operations in a Web Folder Environment |http://www.microsoft.com/resources/documentation/Windows/XP/all/reskit/enus/Default.asp?url=/resources/documentation/windows/xp/all/reskit/en-us/prnb_efs_xqao.asp Remote EFS Operations on File Shares and Web Folders |http://www.microsoft.com/resources/documentation/Windows/XP/all/reskit/enus/Default.asp?url=/resources/documentation/windows/xp/all/reskit/en-us/prnb_efs_hzqx.asp Smart Cards |http://www.microsoft.com/resources/documentation/WindowsServ/2003/standard/proddocs/enus/Default.asp?url=/resources/documentation/WindowsServ/2003/standard/proddocs/enus/sag_SC_topnode.asp Microsoft Knowledge Base Article 223316: Best practices for the Encrypting File System |http://support.microsoft.com/default.aspx?scid=kb;EN-US;223316 Microsoft TechNet: 5-Minute Security Advisor - Recovering Encrypted Data Using EFS |http://www.microsoft.com/technet/community/columns/5min/5min-401.mspx Microsoft TechNet: 5-Minute Security Advisor - Using the Encrypting File System |http://www.microsoft.com/technet/community/columns/5min/5min-202.mspx Microsoft TechNet: Encrypting File System in Windows XP and Windows Server 2003 |http://www.microsoft.com/technet/prodtechnol/winxppro/deploy/cryptfs.mspx Microsoft TechNet: Smart Cards |http://www.microsoft.com/technet/prodtechnol/windowsserver2003/library/ServerHelp/bcac400745cf-4260-876c-7bfca5a01a8a.mspx Microsoft Windows XP Professional Resource Kit Documentation. Microsoft Press What's New in Security for Windows XP Professional and Windows XP Home Edition |http://www.microsoft.com/technet/prodtechnol/winxppro/evaluate/xpsec.mspx Windows 2000 Evaluated Configuration Users Guide, Version 1.0 |http://www.microsoft.com/technet/security/topics/issues/w2kccug/default.mspx Windows XP Professional Evaluated Configuration Administrators Guide, Draft. Windows XP Professional Product Documentation: Password must meet complexity requirements |http://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/504.mspx Windows XP Resource Kit, Chapter 17, Encrypting File System |http://www.microsoft.com/resources/documentation/Windows/XP/all/reskit/enus/Default.asp?url=/resources/documentation/windows/xp/all/reskit/en-us/prnb_efs_hzqx.asp How to Article: Using Digital Certificates| http://www.microsoft.com/windows/ie/using/howto/digitalcert/using.asp Microsoft Knowledge Base Article 281260: A Certificate Request That Uses a New Template Is Unsuccessful|http://support.microsoft.com/default.aspx?scid=kb;en-us;281260 Microsoft Knowledge Base Article 271861: Windows Cannot Find a Certificate Authority That Processes the Request|http://support.microsoft.com/default.aspx?scid=kb;EN-US;271861
Copyright 2008 Microsoft Corporation. All Rights Reserved.
Version 3.0, 07/11/2007
Microsoft Knowledge Base Article 310389: HOW TO: Request a Certificate by Using the Certificates Snap-In in Windows 2000|http://support.microsoft.com/default.aspx?scid=kb;enus;310389 Microsoft TechNet: Requesting certificates| http://www.microsoft.com/technet/treeview/default.asp?url=/TechNet/prodtechnol/winxppro/proddocs/ sag_CMreqCerts.asp Microsoft Windows XP Home: Certificates overview| http://www.microsoft.com/windowsxp/home/using/productdoc/en/default.asp?url=/windowsxp/home/u sing/productdoc/en/sag_cmintrocerts.asp Microsoft Windows XP Home: Certificate stores| http://www.microsoft.com/windowsxp/home/using/productdoc/en/default.asp?url=/windowsxp/home/u sing/productdoc/en/sag_CMunCertStor.asp Step-by-Step Guide to End User Certificate Management| http://www.microsoft.com/windows2000/techinfo/planning/security/eucertsteps.asp

Windows XP Pro SP2 User&#39;s Guide 3.0

Uploaded by

Document Information

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

Windows XP Pro SP2 User&#39;s Guide 3.0

Uploaded by

Copyright:

Available Formats

Windows XP Professional with SP2 Evaluated Configuration Users Guide

Version 3.0 July 11, 2007

Microsoft Corporation Corporate Headquarters One Microsoft Way Redmond, WA 98052-6399

Windows XP Professional SP2 Evaluated Configuration Users Guide

Version 3.0, 07/11/2007

Windows XP Professional SP2 Evaluated Configuration Users Guide

Version 3.0, 07/11/2007

Windows XP Professional with SP2 Evaluated Configuration Users Guide

Windows XP Professional SP2 Evaluated Configuration Users Guide

Version 3.0, 07/11/2007

Windows XP Professional SP2 Evaluated Configuration Users Guide

Version 3.0, 07/11/2007

Copyright 2008 Microsoft Corporation. All Rights Reserved. iii

Windows XP Professional SP2 Evaluated Configuration Users Guide

Version 3.0, 07/11/2007

Copyright 2008 Microsoft Corporation. All Rights Reserved. 1

Windows XP Professional SP2 Evaluated Configuration Users Guide

Version 3.0, 07/11/2007

2. Windows XP Professional Evaluated Configuration

Copyright 2008 Microsoft Corporation. All Rights Reserved. 2

Windows XP Professional SP2 Evaluated Configuration Users Guide

Version 3.0, 07/11/2007

Audio Adaptor, and Network Adaptor.

Copyright 2008 Microsoft Corporation. All Rights Reserved. 3

Windows XP Professional SP2 Evaluated Configuration Users Guide

Version 3.0, 07/11/2007

3. Using Windows XP Professional in a Secure Manner

Organizational Security Policies

Copyright 2008 Microsoft Corporation. All Rights Reserved. 4

Windows XP Professional SP2 Evaluated Configuration Users Guide

Version 3.0, 07/11/2007

Table 3-1 Organizational Security Policies

Secure Usage Assumptions

Copyright 2008 Microsoft Corporation. All Rights Reserved. 5

Windows XP Professional SP2 Evaluated Configuration Users Guide

Version 3.0, 07/11/2007

Table 3-2 Connectivity Assumptions

Copyright 2008 Microsoft Corporation. All Rights Reserved. 6

Windows XP Professional SP2 Evaluated Configuration Users Guide

Version 3.0, 07/11/2007

Copyright 2008 Microsoft Corporation. All Rights Reserved. 7

Windows XP Professional SP2 Evaluated Configuration Users Guide

Version 3.0, 07/11/2007

User and Group Accounts

Copyright 2008 Microsoft Corporation. All Rights Reserved. 8

Windows XP Professional SP2 Evaluated Configuration Users Guide

Version 3.0, 07/11/2007

Copyright 2008 Microsoft Corporation. All Rights Reserved. 9

Windows XP Professional SP2 Evaluated Configuration Users Guide

Version 3.0, 07/11/2007

Copyright 2008 Microsoft Corporation. All Rights Reserved. 10

Windows XP Professional SP2 Evaluated Configuration Users Guide

Version 3.0, 07/11/2007

Copyright 2008 Microsoft Corporation. All Rights Reserved. 11

Windows XP Professional SP2 Evaluated Configuration Users Guide

Version 3.0, 07/11/2007

Copyright 2008 Microsoft Corporation. All Rights Reserved. 12

Windows XP Professional SP2 Evaluated Configuration Users Guide

Version 3.0, 07/11/2007

Copyright 2008 Microsoft Corporation. All Rights Reserved. 13

Windows XP Professional SP2 Evaluated Configuration Users Guide

Version 3.0, 07/11/2007

4. A successful password change is verified with the following message:

Copyright 2008 Microsoft Corporation. All Rights Reserved. 14

Windows XP Pro SP2 User's Guide 3.0

Windows XP Pro SP2 User's Guide 3.0