healthcare efs tool

68
Healthcare EFS Tool Administration Guide Prepared by Microsoft Version 1.0.0.0 Baseline First published 6 October 2006

Upload: others

Post on 03-Feb-2022

6 views

Category:

Documents


0 download

TRANSCRIPT

Page 1: Healthcare EFS Tool

Healthcare EFS Tool Administration Guide

Prepared by Microsoft

Version 1.0.0.0 Baseline

First published 6 October 2006

Page 2: Healthcare EFS Tool

Prepared by Microsoft

Copyright

This document and/or software (“this Content”) has been created in partnership with the National Health Service (NHS) in England. Intellectual Property Rights to this Content are jointly owned by Microsoft and the NHS in England, although both Microsoft and the NHS are entitled to independently exercise their rights of ownership. Microsoft acknowledges the contribution of the NHS in England through their Common User Interface programme to this Content. Readers are referred to www.cui.nhs.uk for further information on the NHS CUI Programme.

All trademarks are the property of their respective companies. Microsoft and Windows are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries.

© Microsoft Corporation and Crown Copyright 2006

Disclaimer

At the time of writing this document, Web sites are referenced using active hyperlinks to the correct Web page. Due to the dynamic nature of Web sites, in time, these links may become invalid. Microsoft is not responsible for the content of external Internet sites.

The example companies, organisations, products, domain names, e-mail addresses, logos, people, places, and events depicted herein are fictitious. No association with any real company, organisation, product, domain name, e-mail address, logo, person, places, or events is intended or should be inferred.

Page ii

Healthcare EFS Tool Administration Guide Version 1.0.0.0 Baseline

Page 3: Healthcare EFS Tool

Prepared by Microsoft

TABLE OF CONTENTS

1  Executive Summary ....................................................................................................................... 1 

2  Introduction .................................................................................................................................... 2 

2.1  Value Proposition ...................................................................................................................... 2 

2.2  Knowledge Prerequisites .......................................................................................................... 2 2.2.1  Skills and Knowledge ........................................................................................................ 2 2.2.2  Training and Assessment .................................................................................................. 3 

2.3  Infrastructure Prerequisites ...................................................................................................... 3 

2.4  Audience ................................................................................................................................... 4 

2.5  Assumptions ............................................................................................................................. 4 

3  Using This Document .................................................................................................................... 5 

3.1  Document Structure .................................................................................................................. 5 

4  Plan ................................................................................................................................................. 7 

4.1  Key EFS Tool Planning Activities ............................................................................................. 7 

5  Develop ........................................................................................................................................... 8 

5.1  EFS Tool Components and Configuration ................................................................................ 8 5.1.1  StartEFSscript.cmd Script ................................................................................................. 8 5.1.2  EFSFunction.vbs and Main EFS Tool Parameters ........................................................... 9 5.1.3  Additional EFS Tool Configuration Options ..................................................................... 10 

5.2  EFS Tool – Execution Workflow ............................................................................................. 13 

6  Stabilise ........................................................................................................................................ 15 

6.1  Designing a Test Environment ............................................................................................... 15 6.1.1  Developing a Test Lab .................................................................................................... 15 6.1.2  Creating a Test Plan ........................................................................................................ 16 6.1.3  Conducting the Tests ...................................................................................................... 16 

6.2  Designing a Pilot Environment ............................................................................................... 16 6.2.1  Creating a Pilot Plan ........................................................................................................ 16 6.2.2  Preparing for the Pilot ...................................................................................................... 16 6.2.3  Deploying and Testing the Pilot ....................................................................................... 17 6.2.4  Evaluating the Pilot .......................................................................................................... 17 

6.3  Preparing for Production Deployment .................................................................................... 17 

7  Deploy ........................................................................................................................................... 18 

7.1  Network Certificate Authority Implementation ........................................................................ 19 7.1.1  Network CA Installed on Windows 2000 Server ............................................................. 19 7.1.2  Network CA Installed on Windows Server 2003 ............................................................. 23 

7.2  Creation of EFS Data Recovery Solution ............................................................................... 24 7.2.1  Create a DRA Certificate on Windows Server 2003 Active Directory ............................. 24 

Page iii

Healthcare EFS Tool Administration Guide Version 1.0.0.0 Baseline

Page 4: Healthcare EFS Tool

Prepared by Microsoft

7.2.2  Create a DRA Certificate on Windows 2000 Server Active Directory ............................. 25 7.2.3  Backup a DRA Certificate ................................................................................................ 29 

7.3  EFS Target Folder Customisation .......................................................................................... 30 

7.4  EFS Tool Rollout ..................................................................................................................... 31 7.4.1  Configuring EFS Tool Group Policy Object ..................................................................... 31 7.4.2  EFS Tool Deployment via Group Policy .......................................................................... 33 

7.5  Encryption of Client Side Cache ............................................................................................. 33 7.5.1  Protecting the Client Side Cache Using EFS .................................................................. 33 7.5.2  Protecting the EFS Machine Keys Using SysKey ........................................................... 35 

8  Operate ......................................................................................................................................... 37 

8.1  Data Recovery Agent Renewal .............................................................................................. 38 

8.2  Data Recovery Operations ..................................................................................................... 39 8.2.1  Recovery Using NTBackup ............................................................................................. 40 8.2.2  Recovery Using the DRA on the User’s Workstation ...................................................... 44 

8.3  Data Migration ........................................................................................................................ 45 8.3.1  Data Migration Using DRA .............................................................................................. 45 8.3.2  Data Migration Using EFS Tool ....................................................................................... 45 

8.4  Required EFS Tool Support Processes.................................................................................. 46 8.4.1  User Profiles .................................................................................................................... 46 8.4.2  Network Certificate Authority Monitoring ......................................................................... 46 

8.5  EFS Tool Troubleshooting ...................................................................................................... 48 8.5.1  Efslog.log ......................................................................................................................... 48 8.5.2  EFSFileList Files.............................................................................................................. 49 

8.6  EFS Tool Issues ..................................................................................................................... 50 8.6.1  Residual Data .................................................................................................................. 50 8.6.2  Shortcuts ......................................................................................................................... 50 8.6.3  Read Only Files ............................................................................................................... 50 

APPENDIX A  Skills and Training Resources ................................................................................. 52 

PART I  EFS .................................................................................................................................. 52 

PART II  Group Policy – Both Domain and Local .......................................................................... 52 

PART III  Supplemental Training Resources .................................................................................. 53 

APPENDIX B  EFS Script Utility Functions ..................................................................................... 54 

APPENDIX C  Network Certificate Authority .................................................................................. 55 

PART I  Network CA Design ......................................................................................................... 55 

PART II  Installing the Network CA ................................................................................................ 56 

PART III  Configuring the Network CA ............................................................................................ 56 

PART IV  Summary ......................................................................................................................... 58 

APPENDIX D  Performance Test Results ........................................................................................ 59 

Page iv

Healthcare EFS Tool Administration Guide Version 1.0.0.0 Baseline

Page 5: Healthcare EFS Tool

Prepared by Microsoft

Page v

Healthcare EFS Tool Administration Guide Version 1.0.0.0 Baseline

PART I  Conclusions ..................................................................................................................... 59 

PART II  Performance Test Details ................................................................................................ 59 

PART III  Test Results..................................................................................................................... 61 

APPENDIX E  Document Information .............................................................................................. 62 

PART I  Terms and Abbreviations ................................................................................................ 62 

PART II  References ...................................................................................................................... 62 

Page 6: Healthcare EFS Tool

Prepared by Microsoft

1 EXECUTIVE SUMMARY Windows® XP Professional supports the encryption of files using the Encrypting File System (EFS). EFS uses a certificate to encrypt and decrypt files transparently to the end user. Encrypted files are protected even if an attacker has full access to the computer's data storage, for example, the attacker is in possession of the physical hard disk.

This document aims to provide guidance around the deployment and operation of the EFS Tool. The EFS Tool is designed to help protect the healthcare organisation against loss of data that might, for example, occur as a result of theft or loss of a laptop or desktop. The EFS Tool has been designed to make the use of EFS consistent and easy to operate; thereby allowing the healthcare organisation to protect user data in a more cost effective manner. It is targeted at the Windows XP (Service Pack 1 onwards) platform.

Page 1

Healthcare EFS Tool, Administration Guide Version 1.0.0.0 Baseline

Page 7: Healthcare EFS Tool

Prepared by Microsoft

2 INTRODUCTION The EFS Tool makes the deployment and operation of EFS simpler, and to provide guidance around the following functionality:

The design, implementation and configuration of the Healthcare EFS Tool and supporting infrastructure to encrypt end-user file based data on Healthcare Desktops

The ability to centrally control encryption of user data at the folder level

The ability to centrally control decryption of user data at the folder level

The ability to centrally force encryption refresh after updates to the Data Recovery Agent (DRA) certificates

The new guidance documentation will also provide high-level operational information around:

The deployment of the EFS Tool

DRA certificate renewals

Data recovery processes

A data migration scenario

This guidance can be used by any healthcare organisation that requires advice and guidance on how to deploy EFS using the EFS Tool.

2.1 Value Proposition The information contained within this document will guide a healthcare organisation through the process of securing data using the EFS Tool. This will enable an additional layer of security to provide more defence to the overall security of the Microsoft infrastructure which will be relatively easy to manage.

While no security design guidance can be applied as a ‘one size fits all’, the guidance provided in this document empowers a healthcare organisation to simplify the design, deployment and operational process of EFS, whilst also allowing them to take local requirements into account.

2.2 Knowledge Prerequisites To implement the recommendations made throughout this document effectively, a number of knowledge-based and environmental infrastructure prerequisites should be in place. This section outlines the knowledge and skills required to use the Healthcare EFS Tool Administration Guide, while section 2.3 details the necessary infrastructure prerequisites.

Section 2.2.1 details the prerequisite skills and knowledge, and section 2.2.2 details the information and suggested training resources or skill assessment.

2.2.1 Skills and Knowledge The technical knowledge and minimum skills required to use this guidance are:

An understanding of the healthcare organisation’s security requirements

Previous experience of Microsoft Windows operating systems in a networked environment, including design, deployment, troubleshooting, and so on

Experience with Active Directory technologies and a good understanding of Group Policy administration

An understanding of the support and operations procedures for IT infrastructure within the applicable healthcare organisation

Page 2

Healthcare EFS Tool, Administration Guide Version 1.0.0.0 Baseline

Page 8: Healthcare EFS Tool

Prepared by Microsoft

Page 3

Healthcare EFS Tool, Administration Guide Version 1.0.0.0 Baseline

Preferably qualified as Microsoft Certified Systems Engineer (MCSE) 2000 or 2003

Preferably qualified with the MCSE 2003: Security on Microsoft Windows Server 2003 Specialisation examinations

Experience of Change Management processes

Understanding at a high level of certificates and Public Key Infrastructure

Understanding at a high level of Encrypting File System (EFS)

2.2.2 Training and Assessment Guidelines on the basic skill-sets that are required in order to make best use of this guidance are detailed in APPENDIX A. The list in APPENDIX A represents the training courses and other resources available. However, all courses listed are optional and can be provided by a variety of certified training partners.

2.3 Infrastructure Prerequisites The following is a list of Microsoft infrastructure prerequisites required to successfully deploy and operate the EFS Tool:

Windows XP (SP1 onwards) operating system installed on the target workstation

Crypto API COM (CAPICOM)1 object v2 onwards installed on each Windows XP target workstation

The presence of Active Directory®

The presence of a Network Certificate Authority (CA)

In order to install a Network CA the following infrastructure prerequisites are required:

Install CAPICOM onto the Network CA

For a Windows 2003 Network CA only, the following additional infrastructure prerequisites are required:

Install GPMC2 onto Windows Server 2003 Network CA

Install Windows Server 2003 Support Tools onto Windows Server 2003 Network CA

Install the Securing Wireless LANs with Protected Extensible Authentication Protocol (PEAP) and Password3 tools onto Windows Server 2003 Network CA. Please note that there is no requirement for Wireless functionality – the reason it is recommended that the Tools package (which form part of the Securing Wireless LANs with PEAP and Passwords guidance4) is installed, is because it allows you to automate the installation of the Network CA using a scripted install.

Note

The Healthcare EFS Tool cannot be used in environments where Active Directory or a Network CA is not present.

1 Platform SDK Redistributable: CAPICOM {R1} can be downloaded from: http://www.microsoft.com/downloads/details.aspx?FamilyID=860ee43a-a843-462f-abb5-ff88ea5896f6&DisplayLang=en 2 Group Policy Management Console {R2} can be downloaded from: http://go.microsoft.com/fwlink/?LinkId=46570 3 Securing Wireless LANs with PEAP and Passwords {R3} can be downloaded from: http://www.microsoft.com/downloads/details.aspx?FamilyID=60c5d0a1-9820-480e-aa38-63485eca8b9b&displaylang=en 4 Overview of Securing Wireless LANs with PEAP and Passwords {R4}: http://www.microsoft.com/technet/security/guidance/cryptographyetc/peap_0.mspx

Page 9: Healthcare EFS Tool

Prepared by Microsoft

2.4 Audience The guidance contained in this document is targeted at a variety of roles within the healthcare IT organisation. Table 1 provides a reading guide for this document, illustrating the roles and the sections of the document that are likely to be of most interest.

Role Document Usage

Exec

utive

Su

mm

ary

Plan

Deve

lop

Stab

ilise

Depl

oy

Oper

ate

IT Manager Use this guidance to understand the justification and drivers of the EFS Tool, and to develop an understanding of the implementation requirements

IT Architect Use the relevant areas within this guidance to assess the EFS Tool against local architecture strategy and implementation plans

IT Professional/ Administrator

Use this guidance to implement the EFS Tool to meet local requirements

Table 1: Document Audience

2.5 Assumptions The EFS Tool guidance provided in this document assumes that healthcare organisations that want to share services and resources between sites already have suitable IP Addressing schemes in place to enable successful site to site communication; that is, unique IP Addressing schemes assigned to each participating healthcare organisation with no overlap. Active Directory, and the underlying Domain Naming Services (DNS), require the use of unique IP Addressing schemes at adjoining sites in order for cross site communication to function successfully. The use of NAT (Network Address Translation) within an Active Directory environment is neither recommended nor supported by Microsoft.

Page 4

Healthcare EFS Tool, Administration Guide Version 1.0.0.0 Baseline

Page 10: Healthcare EFS Tool

Prepared by Microsoft

Page 5

Healthcare EFS Tool, Administration Guide Version 1.0.0.0 Baseline

3 USING THIS DOCUMENT This document is intended for use by healthcare organisations and IT administrators who wish to use the EFS Tool for file encryption. The document should be used to assist with the planning and implementation of an encryption solution and as a reference guide for the most common tasks involved.

3.1 Document Structure This document contains five sections that deal with the project lifecycle, as illustrated in Figure 1 and in the list below:

Plan

Develop

Stabilise

Deploy

Operate

Each section is based on the Microsoft IT Project Lifecycle as defined in the Microsoft Solutions Framework (MSF) Process Model, and the Microsoft Operations Framework (MOF). The IT Project Lifecycle is described in more detail in the Microsoft Solutions Framework Core White Papers5 and the MOF Executive Overview6. The MSF Process Model and MOF describe a high-level sequence of activities for building, deploying and managing IT solutions. Rather than prescribing a specific series of procedures, they are flexible enough to accommodate a broad range of IT projects.

5 Microsoft Solutions Framework Core Whitepapers {R5}: http://www.microsoft.com/downloads/details.aspx?FamilyID=e481cb0b-ac05-42a6-bab8-fc886956790e&DisplayLang=en 6 MOF Executive Overview {R6}: http://www.microsoft.com/technet/solutionaccelerators/cits/mo/mof/mofeo.mspx

Page 11: Healthcare EFS Tool

Prepared by Microsoft

Figure 1: MSF Process Model Phases and Document Structure

Page 6

Healthcare EFS Tool, Administration Guide Version 1.0.0.0 Baseline

Page 12: Healthcare EFS Tool

Prepared by Microsoft

4 PLAN During the Plan phase the EFS Tool implementation planning is completed, areas for further analysis are identified and the design process commences.

4.1 Key EFS Tool Planning Activities The Plan phase for the deployment and operation of the EFS Tool is covered at a high level in this document. The key activities that need to be executed during this phase are:

The identification of the EFS target user groups and their workstations within a healthcare organisation.

The identification of the EFS target folders for each target user group within a healthcare organisation.

The planning of logical grouping(s) in Active Directory for each target user group.

The planning of the deployment of a Network Certificate Authority (if not already present), see section 7.1 for further information.

Ensure that the system engineers/administrators involved with the deployment and operation of the EFS Tool have the appropriate skills as listed in section 2.2.

Plan in-depth testing of the EFS Tool within an isolated test environment, see section 6.1 for further information.

Create a Project Plan to execute the deployment of the EFS Tool and supporting infrastructure. It is recommended that a phased deployment is conducted, starting with a small scale pilot deployment. See section 6.2 for further information around planning a pilot deployment.

Confirm that all required resources are available to execute the deployment of the EFS Tool within the required timeframes (for example, hardware, software, and system engineers).

Ensure that system engineers/administrators are available and have the appropriate skills to support the EFS Tool for end-users in a live environment.

Page 7

Healthcare EFS Tool, Administration Guide Version 1.0.0.0 Baseline

Page 13: Healthcare EFS Tool

Prepared by Microsoft

5 DEVELOP During the Develop phase the EFS Tool is configured according to the requirements that were investigated in the Plan phase. Further refinement of the EFS Tool will continue into the stabilisation phase.

This section covers:

An introduction to the components that make up the EFS Tool

An overview of the main encryption related parameters and how to configure the EFS Tool to execute each of these parameter choices

An overview of the additional EFS Tool parameters that are configurable

A high-level overview of the EFS Tool execution workflow

Figure 2 acts as a high-level checklist, illustrating the sequence of events required to configure the EFS Tool within a healthcare organisation.

Figure 2: Sequence for Configuring the EFS Tool

5.1 EFS Tool Components and Configuration The EFS Tool consists of two scripts as follows:

The first script is a single line command file called StartEFSscript.cmd

The second script is the main EFS Tool script and is called EFSFunction.vbs

Both these scripts need to be deployed via Active Directory Group Policy as a logon script, for more information on how to do this, see section 7.4.

5.1.1 StartEFSscript.cmd Script This single line command file is used to start the main EFS Tool script called EFSFunction.vbs.

By default, the StartEFSscript.cmd file in the EFS Tool calls the EFSFunction.vbs script as follows: start /min /low cscript \\%~p0EFSFunction.vbs

This command allows the EFSFunction.vbs script to run as minimised (/min option) and at a low process priority (/low option).

Because no additional encryption related parameters are specified in the default command, the EFSFunction.vbs script will execute the default action of encryption of all the files in the specified target folders.

In order to change encryption related parameters passed to EFSFunction.vbs, the StartEFSscript.cmd script will need to be edited. The next section describes the various encryption parameter related choices and how to edit StartEFSscript.cmd to execute each of these.

Page 8

Healthcare EFS Tool, Administration Guide Version 1.0.0.0 Baseline

Page 14: Healthcare EFS Tool

Prepared by Microsoft

5.1.2 EFSFunction.vbs and Main EFS Tool Parameters The EFSFunction.vbs file constitutes the main script of the EFS Tool and is written in the Visual Basic Script (VBS) language.

EFSFunction.vbs has only a single entry point from the command line (triggered by StartEFSscript.cmd) that initialises some variables and then calls the main EFS function (EFSMain).

Table 2 lists the different parameters that can be passed to EFSFunction.vbs by StartEFSscript.cmd to modify the encryption behaviour:

Parameter Description ENCRYPT (Default)

The default action is to encrypt all user data. To encrypt all files with the specified target folder, edit the default StartEFSscript.cmd file to run the following command:

start /min /low cscript \\%~p0EFSFunction.vbs

DECRYPT Forces decryption of all user data. This option is useful before a computer migration is performed. See section 8.3.2 for further information on the use of this parameter. To configure the main script to decrypt all files within the specified target folder, edit the StartEFSscript.cmd file to run the following command:

start /min /low cscript \\%~p0EFSFunction.vbs DECRYPT

High Water Mark (Default value is 1)

The High Water Mark (HWM) would be incremented after updating the DRA certificate and re-encrypts all user files using the latest DRA certificate. See section 8.1 for further information on using the HWM parameter. To increment the High Water Mark parameter to a value of 2, edit the StartEFSscript.cmd file to run the following command:

start /min /low cscript \\%~p0EFSFunction.vbs 2

Each time the DRA is renewed the parameter needs to be incremented by one. The EFS Tool rounds down the passed HWM parameter to an integer. Any fractional parts of this parameter (for example 0.5) are ignored.

Table 2: EFS Tool Parameters

As mentioned in the previous section, by default the script executes the ENCRYPT parameter. If you changed this to execute any of the other encryption related parameters and wish to revert back to the default ENCRYPT parameter, you will need to edit the StartEFSscript.cmd file to execute the following default command: start /min /low cscript \\%~p0EFSFunction.vbs

The exception to this rule applies when you have incremented the High Water Mark (HWM), as the latest incrementation needs to remain part of the command; for example if you have incremented the HWM once, then the default command should be as follows: start /min /low cscript \\%~p0EFSFunction.vbs 2

Page 9

Healthcare EFS Tool, Administration Guide Version 1.0.0.0 Baseline

Page 15: Healthcare EFS Tool

Prepared by Microsoft

Page 10

Healthcare EFS Tool, Administration Guide Version 1.0.0.0 Baseline

5.1.3 Additional EFS Tool Configuration Options The EFSFunction.vbs script uses various data items in order to function. These data items are either constants or variables within the script, or within external data, such as the file system, the user certificate stores and the registry.

Table 3 below details the main data items that will be used, together with details on whether or not they can be configured within the healthcare organisation.

Data Item Location Description Healthcare

Organisation Configurable

Possible Values

aryEFSEncryptList EFSFunction.vbs Used to define which folders to encrypt. For more information on changing this value, please see section 7.3

Yes This is an array of comma delimited strings that specify which folder paths to encrypt on the XP Workstation. These strings can be found between lines 258 and 270 in the script. More details on configuring this value can be found in section 5.1.3.1.

EFSDEBUG EFSFunction.vbs Used to enable more detailed debugging of the EFS Tool

Yes True or False The default False value means that detailed logging is not performed. This value can be configured in line 147 in the script.

EFS_LOG_APPEND EFSFunction.vbs Determines whether the EFS Tool appends to log files or replaced them each time it runs

Yes True or False The default False value means that the script overwrites the old log file each time it runs. This value can be configured in line 150 in the script.

EFS_LOG_FOLDER EFSFunction.vbs Folder where log files will be stored This is stored as a string

Yes String that specifies the folder path. The default value is "Local Settings\Logs". To change the log folder path, change the above string in the code to the desired folder path value. This string can be configured in line 151 in the script.

EFS_CIPHER_LOG EFSFunction.vbs Base filename for log files Yes String that specifies the first part of the log filenames. The default value is "EFSFileList". To change the log filename, change the above string in the code to the desired value. This string can be configured in line 154 in the script.

Page 16: Healthcare EFS Tool

Prepared by Microsoft

Page 11

Healthcare EFS Tool, Administration Guide Version 1.0.0.0 Baseline

Data Item Location Description Healthcare

Organisation Configurable

Possible Values

LOGONSCR EFSFunction.vbs The name of the EFSFunction.vbs script. If the script is renamed, this constant needs to be changed

Yes String that specifies the name of the script. The default value is "efsfunction.vbs" To change the script name, change the above string in the code to the desired name. This string can be configured in line 166 in the script.

EFS Certificates User certificate store in the user profile

An EFS certificate is required in order to successfully encrypt or decrypt data files. The EFS certificate is enrolled from an online Windows Enterprise CA. For more information on configuring a Windows Enterprise CA, see section 7.1

No N/A

EFS Tool Log File Local Settings\Logs \efslog.log

Log file for EFS Tool Activities No N/A

Encryption Log Files Local Settings\Logs directory within the user’s Documents and Settings folder

Log files for each folder that is encrypted, detailing: Which files are encrypted Failed encryption

execution error messages

No N/A

EFSRegistryHash (EFS_REGVAL_USERHASH and EFS_REGVAL_USERHASH_TYPE)

The user portion of the registry (Software\NHSCUI\EFS\CertificateHash)

This key is used to store the hash of the EFS certificate that has been previously used to encrypt user files

No N/A

High Water Mark (EFS_REGVAL_HWM and EFS_REGVAL_HWM_TYPE)

The user portion of the registry (Software\NHSCUI\EFS\RefreshHWM)

This key is used to store the last High Water Mark used by the EFS Tool For more information on using the HWM parameter, see section 8.1

No N/A

EFS Certificate Thumbprint

The user portion of the registry

The thumbprint of the EFS certificate that is currently being used by the operating system to encrypt user files

No N/A

Table 3: EFS Tool Data Items

Note

Constants in the EFS Tool script that are specified after the following comment should not be modified:

'// ----------- SYSTEM & CODE CONSTANTS - DO NOT MODIFY! -----------

These constants can be found between line 171 and line 234 in the script.

Page 17: Healthcare EFS Tool

Prepared by Microsoft

Page 12

Healthcare EFS Tool, Administration Guide Version 1.0.0.0 Baseline

5.1.3.1 Configuring the Encryption Folders – aryEFSEncryptList The string array variable called aryEFSEncryptList contains the list of folders that are to be encrypted. Folders that are configured to be encrypted should not be shared between users as EFS is not very well suited to sharing encrypted files between users.

If roaming profiles are in use then it is important not to encrypt any of the contents of the roaming profile. If encrypted files are found in a roaming profile, Windows will not save the roaming profile to a file server. It should also be noted that Windows maintains the user’s encryption keys in the user’s profile and if these are encrypted using EFS then at next logon it will not be possible to decrypt them (the keys cannot be decrypted as they are encrypted using themselves).

Windows XP SP2 now supports Credential Roaming7 for users with local (non-roaming) profiles. Credential Roaming allows the user’s certificates to be replicated between computers using Active Directory rather than relying on a roaming profile. The use of Credential Roaming allows automatic recovery of certificates within a deleted user profile without administrator intervention and thus should dramatically reduce the impact of profile deletions.

Folders can be specified in one of several different ways as specified below:

Using an absolute path to a directory, such as C:\UserData.

Using a relative path from the users profile directory. For instance, specifying ‘Local Settings\Application Data’ would cause the folder ‘C:\Documents and Settings\<username>\ Local Settings\Application Data’ to be encrypted.

Using a special folder such as MyDocuments. Special folders can be specified by the use of the # character followed by the special folder name. Special folders that can be used include the following:

Desktop – The user's desktop

Favorites – The user's favourites list

MyDocuments – The user's My Documents folder

NetHood – The user’s My Network Places folder

Programs –The user’s programs folder

Recent – A folder containing the user’s shortcuts to recently opened files

SendTo – A folder containing the user’s shortcuts to applications to send documents to

StartMenu – The user's start menu

Startup – The user’s startup folder

Templates – The user's file templates

Folder paths containing the username as a parameter such as C:\UserData\%username%.

The Outlook Temporary Files Folder uses the special string ‘OLK’.

7 For more information, see User credential roaming {R7}: http://technet2.microsoft.com/WindowsServer/en/library/ef08bb73-716a-4476-95ba-882714c26b991033.mspx?mfr=true

Page 18: Healthcare EFS Tool

Prepared by Microsoft

5.2 EFS Tool – Execution Workflow The EFSFunction.vbs script has one entry point that calls the main EFS function (EFSMain). This function implements the core logic of EFSFunction.vbs. The EFSFunction.vbs script terminates after completing EFSMain function. Figure 3 below illustrates the workflow of this function within the script.

Figure 3: Workflow for the EFSMain Function

Page 13

Healthcare EFS Tool, Administration Guide Version 1.0.0.0 Baseline

Page 19: Healthcare EFS Tool

Prepared by Microsoft

The EFSMain function will perform the following actions:

1. Open the EFS Tool log file

2. Open a handle to the user certificate store using Crypto API COM {R1} (CAPICOM provides a scriptable certificates interface)

If CAPICOM is not present, this operation will fail with a fatal error

3. Write an initial log entry to the EFS Tool log file

4. Get the current EFS certificate thumbprint

If the thumbprint is not present, the script encrypts a test file to create the thumbprint. This process will cause the Windows XP client to automatically enrol for an EFS certificate from an online Network CA

If the EFS certificate thumbprint is still not present, the script exits with fatal error (this error will be written in the EFS Tool log file)

5. Read the EFS certificate from the certificate store using the thumbprint

If the thumbprint is not present, the script exits with fatal error (this error will be written in the EFS Tool log file)

6. Check that the EFS certificate is valid

The check will be performed by calling a certificate validation routine

If the certificate is not valid, the script exits with fatal error (this error will be written in the EFS Tool log file)

7. Compare the current EFS certificate with the previous EFS certificate

If this is a new certificate, the script forces a complete re-encryption of user files by setting the refresh Data Decryption Fields (DDF) flag

This check means that user files are encrypted using valid non expired EFS certificates

8. Check the High Water Mark (HWM) parameter

If the passed HWM parameter is different from the previous HWM, force a complete re-encryption of user files by setting the refresh DDF flag. See section 8.1 for more information on using the HWM parameter

Store the new High Water Mark in the registry

This functionality allows the administrator to replace the DRA certificate and force re-encryption using the new certificate

9. Encrypt or De-crypt files as specified by the passed Action parameter in StartEFSscript.cmd (ENCRYPT or DECRYPT).

The script will perform this process asynchronously at low priority

10. If a complete re-encryption is required (DDF flag), perform the re-encryption process asynchronously at low priority

A list of utility functions within the script, which are required for the execution of the workflow detailed above, can be found in APPENDIX B.

Page 14

Healthcare EFS Tool, Administration Guide Version 1.0.0.0 Baseline

Page 20: Healthcare EFS Tool

Prepared by Microsoft

6 STABILISE The Stabilise phase involves testing the solution components whose features are complete, resolving and prioritising any issues that are found. Testing during this phase emphasises usage and operation of the solution components under realistic environmental conditions.

The Stabilise phase involves testing, and the acceptance of, the EFS Tool. The aim is to minimise the impact on normal business operations by testing the design assumptions, and verifying the deployment process, in a pilot program.

Figure 4 acts as a high-level checklist, illustrating the sequence of events required to stabilise the EFS Tool within a healthcare organisation:

Figure 4: Sequence for Stabilising the EFS Tool

6.1 Designing a Test Environment Before deploying the EFS Tool, it is important to first test the EFS Tool in a standalone test environment. This will allow you to identify and address any issues prior to deploying the script within a production environment.

6.1.1 Developing a Test Lab The test lab will need to include the following components as a minimum:

Windows Active Directory running on Windows Server 2003 or Windows 2000 Server

Windows Network CA running on Windows Server 2003 or Windows 2000 Server

Windows XP Service Pack 1 or Service Pack 2 client with CAPICOM {R1} (v2.0 onwards) installed

The test environment can be built onto either physical computers or, alternatively, be deployed using virtual machines. For accurate performance testing, the Windows XP workstation needs to use a real computer that is representative of production hardware. Therefore, it is recommended that the test lab includes at least one physical Windows XP client.

Page 15

Healthcare EFS Tool, Administration Guide Version 1.0.0.0 Baseline

Page 21: Healthcare EFS Tool

Prepared by Microsoft

6.1.2 Creating a Test Plan It is critical to create a test plan to ensure the success of testing the EFS Tool. This should define the following components:

Define testing scope and objectives of the EFS Tool testing effort

Identify the required resources; such as hardware, software and tools required for testing the EFS Tool

Define the data and data locations that will be encrypted using the EFS Tool

Define acceptable performance metrics for the test

Establish a testing schedule

6.1.3 Conducting the Tests When conducting the EFS Tool tests, the tester must:

Perform each test as described in the test plan

Evaluate the test results

Escalate problems that arise until they are resolved

Document the test results

The pilot phase can be started if the tests are passed.

6.2 Designing a Pilot Environment

6.2.1 Creating a Pilot Plan Conducting the pilot is the last major step before deployment of the EFS Tool. During the pilot, the release management team tests the EFS Tool in a small-scale controlled environment in which users perform their normal business tasks using the new encryption features. This demonstrates that the EFS Tool works in the production environment as expected and that it meets the healthcare organisation’s business requirements. Any encountered problems can immediately be fed back into testing and the EFS Tool reconfigured as required, therefore, minimising the risk to the business of issues during deployment.

The pilot plan should define the following aspects:

The scope and objectives of the pilot

Identify pilot participants and where the pilot will be conducted

A schedule for deploying and conducting the EFS Tool pilot and required supporting infrastructure

Plans for training and communicating with pilot participants

Evaluating the pilot

Identifying risks and contingencies

6.2.2 Preparing for the Pilot Preparation for the pilot deployment should consider the following points:

Prepare the pilot participants

Deploy the required EFS Tool supporting infrastructure. For more information on achieving this, see section 7

A contingency plan to roll-back the deployment of the EFS Tool

Page 16

Healthcare EFS Tool, Administration Guide Version 1.0.0.0 Baseline

Page 22: Healthcare EFS Tool

Prepared by Microsoft

6.2.3 Deploying and Testing the Pilot When deploying the pilot, the EFS Tool implementation is being tested under live conditions. A trial run of the pilot deployment process should be carried out to identify any problems that may be encountered. When the full pilot begins, keep track of which deployment tasks have been completed so that it is possible to monitor the progress of the pilot.

The simplest method of piloting the EFS Tool is to create a separate Organisational Unit (OU) for the pilot users. Ideally, this should be created as a sub OU (called “EFS Pilot Users”) of the existing user OU, into which the pilot users should be moved. The EFS Users Group Policy Object will need to be linked to the new OU using either the Group Policy Management Console (GPMC) {R2} in Windows Server 2003, or using the Active Directory Users and Computers snap-in in Windows 2000. For more information on creating the EFS Group Policy Object and applying it to the relevant OUs, see section 7.4.

When users logon to the workstations, the EFS Users Group Policy Object will be applied and all user data will be encrypted. As participants use the system, ensure that the pilot team track the progress of the pilot, and pinpoint areas of concern. Ensure that adequate communication processes are in place to allow pilot users to report problems, or to escalate issues when immediate problem resolution is not possible.

6.2.4 Evaluating the Pilot When the EFS Tool pilot is complete, obtain feedback from a variety of sources, including participants, pilot release management, support teams and other observers, to evaluate the pilot’s success.

Once enough pilot data has been collected and participant feedback has been evaluated, the team must decide how to proceed. Depending on how well the EFS Tool pilot meets the success criteria, there are a number of strategies that can be employed at this point in the pilot deployment:

Roll the pilot forward

Roll back the pilot

Suspend the pilot

Update the pilot and continue

Proceed to the production deployment phase

The pilot is not complete until the team ensures that the EFS Tool is viable in the production environment and the solution is ready for deployment.

6.3 Preparing for Production Deployment Once the team has agreed that the EFS Tool pilot has been successfully completed and has obtained management approval for proceeding, the next step in the deployment project is to fully deploy the EFS Tool to the appropriate healthcare organisation level. During this phase, the release team deploys the core EFS Tool and supporting infrastructure, stabilises the deployment, transitions the management of the project to the operations and support teams, and obtains final management approval of the project.

Page 17

Healthcare EFS Tool, Administration Guide Version 1.0.0.0 Baseline

Page 23: Healthcare EFS Tool

Prepared by Microsoft

7 DEPLOY During the Deploy phase, the EFS Tool is deployed for widespread application and use, and the deployment is stabilised through ongoing monitoring. The solution is then transitioned to the operations and support teams.

The configuration and installation of the EFS Tool require the following steps to be carried out; these steps are explained in detail within this section:

Deployment of a Network CA, healthcare organisations that already have a Microsoft Enterprise PKI in place do not need to build another CA

Configuration of the Network CA to issue EFS Certificates

Creation of a Data Recovery solution

If required, customisation of the target folders to be encrypted via EFS

EFS Tool Deployment Using Group Policy

If the Offline Files feature is being used, it is recommended that the Client Side Cache is also encrypted on the target Windows XP workstations. This cannot be done using the EFS Tool. However, this section contains a step by step explanation on how to achieve this.

Figure 5 acts as a high-level checklist, illustrating the sequence of events required to deploy the EFS Tool within a healthcare organisation.

Network Certificate Authority

Implementation

Creation of EFS Data Recovery

Solution

EFS Target Folder Customisation

EFS Tool Rollout

Create a DRA Certificate on

Windows Server 2003 Active Directory

Create a DRA Certificate on

Windows 2000 Server Active Directory

Backup a DRA Certificate

Network CA Installed on Windows 2000

Server

Network CA Installed on Windows Server

2003

Configuring EFS Tool Group Policy Object

EFS Tool Deployment via Group Policy

Encryptionof Client Side Cache

Protecting the Client Side Cache Using

EFS

Protecting the EFS Machine Keys Using

SysKey

Figure 5: Sequence for Deploying the EFS Tool

Page 18

Healthcare EFS Tool, Administration Guide Version 1.0.0.0 Baseline

Page 24: Healthcare EFS Tool

Prepared by Microsoft

7.1 Network Certificate Authority Implementation The EFS Tool requires a Network CA to issue the EFS certificates and Data Recovery Agent certificate(s).

This guide covers two different methods for installing the Network CA, the first using Windows 2000 Server and the second using Windows Server 2003. The choice of operating system used to deploy the Network CA should be determined by the healthcare organisation based on local preferences.

After installation of the Network CA, Windows XP clients will perform a Group Policy refresh every 90 minutes, with a randomised offset of plus or minus 30 minutes. Hence it is advised not to deploy the EFS Tool until several hours after the Network CA has been built (to allow for Domain Controller (DC) to DC replication and refresh to occur).

7.1.1 Network CA Installed on Windows 2000 Server The installation of the Network CA onto Windows 2000 Server should be done purely to support EFS and not as a general CA. The Windows 2000 Server CA installation process is purely manual rather than scripted.

To install the Network CA:

1. Open the Control Panel.

2. Double-click on Add/Remove Programs.

Page 19

Healthcare EFS Tool, Administration Guide Version 1.0.0.0 Baseline

Page 25: Healthcare EFS Tool

Prepared by Microsoft

3. Select Add/Remove Windows Components.

4. Select Certificate Services.

5. Click Yes on the warning dialog box that displays.

Page 20

Healthcare EFS Tool, Administration Guide Version 1.0.0.0 Baseline

Page 26: Healthcare EFS Tool

Prepared by Microsoft

6. Select Next.

7. Select Enterprise root CA and click Next.

Page 21

Healthcare EFS Tool, Administration Guide Version 1.0.0.0 Baseline

Page 27: Healthcare EFS Tool

Prepared by Microsoft

8. Enter the CA name EFSCA and fill out the other fields in the CA Identifying Information dialog box. The CA should be configured to be valid for 25 years and select Next.

9. Leave the database files in the default location and select Next.

Page 22

Healthcare EFS Tool, Administration Guide Version 1.0.0.0 Baseline

Page 28: Healthcare EFS Tool

Prepared by Microsoft

Page 23

Healthcare EFS Tool, Administration Guide Version 1.0.0.0 Baseline

10. Click Finish to complete.

7.1.2 Network CA Installed on Windows Server 2003 Before installing the Network CA into a Windows 2000 Active Directory environment the directory will need to be prepared. This process needs to be done from a Windows 2000 Server Domain Controller as a Schema Administrator. The process involves running two command lines to prepare the schema8 and the domain. The commands are contained on the Windows Server 2003 CD in the \i386 folder.

Run the following two commands on the Domain Controller (press ENTER between each command): \i386\adprep /forestPrep

\i386\adprep /domainPrep

After preparing the forest and the domain(s), the directory will take some time to replicate changes. This time will vary depending upon the site and connection topology. It is important to allow changes to replicate across the forest before continuing the installation process.

The Network CA should be deployed and configured using the guidance in APPENDIX C.

By default, Windows XP clients will perform a Group Policy refresh every 90 minutes, with a randomised offset of plus or minus 30 minutes. Hence it is advised not to deploy the EFS Tool until several hours (and preferably longer) after the Network CA has been built (to allow for DC to DC replication and refresh to occur).

8 For more information, see Upgrading from a Windows 2000 domain {R8}: http://technet2.microsoft.com/WindowsServer/en/library/1e2541bb-d42c-49ef-9f8a-18e30b4f26671033.mspx?mfr=true

Page 29: Healthcare EFS Tool

Prepared by Microsoft

Page 24

Healthcare EFS Tool, Administration Guide Version 1.0.0.0 Baseline

7.2 Creation of EFS Data Recovery Solution When EFS is used, there needs to be a mechanism to recover data should (for whatever reason) the user’s private decryption keys be lost or unavailable, otherwise it will not be possible to recover lost data when a user loses a private key. Windows XP EFS provides built-in data recovery9 support by one of two mechanisms as follows:

Using DRA Keys – Files are encrypted using the user’s EFS key and also one or more data recovery keys, which are configured using Active Directory Group Policy

Using Key Recovery – When Certificate Services is installed on Windows Server 2003 Enterprise Edition, it supports the archiving10 of private keys at enrolment time, thus allowing the user’s private key to be recovered to a password protected file

It is recommended that DRA keys be used to recover data unless a full PKI is put into place. The user interface for creating the DRA certificate is slightly different between Windows 2000 Server and Windows Server 2003 (see sections 7.2.1 and 7.2.2 below for further information).

Note

The EFS Tool will not run unless a valid DRA certificate is found, thus protecting the healthcare organisation against possible data loss.

7.2.1 Create a DRA Certificate on Windows Server 2003 Active Directory

Using Active Directory and a Network CA, the DRA should be created and configured.

To configure the EFS recovery certificate:

1. Start the Group Policy Editor and edit the Default Domain Policy:

2. Right click on the Encrypting File System settings in the policy and select Create Data Recovery Agent.

3. After creating the new data recovery certificate, remove the old, self signed recovery certificate by right-clicking on it and selecting Delete.

9 More details on Data Protection and Recovery in Windows XP can be found at {R9}: http://technet.microsoft.com/en-us/library/bb457020.aspx 10 Key Archival and Management in Windows Server 2003 {R10}: http://technet2.microsoft.com/windowsserver/en/library/296f87df-06c3-4e27-89ff-5283cb76fb811033.mspx

Page 30: Healthcare EFS Tool

Prepared by Microsoft

7.2.2 Create a DRA Certificate on Windows 2000 Server Active Directory

To create the new EFS recovery certificate (DRA):

1. Start the Certificate MMC by executing the command (or alternatively run MMC.EXE and add the certificates snap in for the My User account): C:> certmgr.msc

2. Open Current User > Personal > Certificates. Right-click on Certificates and select All Tasks > Request New Certificate.

3. Click Next in the Certificate Request Wizard.

Page 25

Healthcare EFS Tool, Administration Guide Version 1.0.0.0 Baseline

Page 31: Healthcare EFS Tool

Prepared by Microsoft

4. Select the EFS Recovery Agent and click Next.

5. Enter a friendly name for the certificate and click Next.

Page 26

Healthcare EFS Tool, Administration Guide Version 1.0.0.0 Baseline

Page 32: Healthcare EFS Tool

Prepared by Microsoft

6. Click Finish.

7. Right-click on the new certificate and select Export.

8. Click Next in the Certificate Export Wizard.

9. Select No to Export the Private Key and click Next.

10. Click Next again.

11. Enter a filename for the exported certificate (such as, C:\DRA.cer) and click Next.

12. Click Finish.

Page 27

Healthcare EFS Tool, Administration Guide Version 1.0.0.0 Baseline

Page 33: Healthcare EFS Tool

Prepared by Microsoft

To configure the EFS recovery certificate:

1. Access the Users and Computers console, start the Group Policy Editor and edit the Default Domain Policy.

2. Right-click on the Encrypted Data Recovery Agents settings in the policy and select New > Encrypted Recovery Agent.

3. Click Next in the Add Recovery Agent Wizard.

Page 28

Healthcare EFS Tool, Administration Guide Version 1.0.0.0 Baseline

Page 34: Healthcare EFS Tool

Prepared by Microsoft

4. Click the Browse Folders button.

5. Select the DRA.cer files created in step 11 of section 7.2.2. Click Open and, if requested, answer Yes to install the certificate.

6. Click Next and then Finish to complete the Add Recovery Agent Wizard.

7. After creating the new data recovery certificate, remove the old, self signed recovery certificate by right-clicking on it and selecting Delete.

7.2.3 Backup a DRA Certificate After creating and configuring the DRA certificate it is important to back up the certificate. Failure to backup the data recovery certificate may result in the loss of encrypted user data in the event of the EFS user certificate and original DRA certificate being lost.

To create a backup of the DRA certificate:

1. Start the Certificate MMC by executing the command: C:> certmgr.msc

2. Open Current User > Personal > Certificates. The new EFS recovery certificate should be displayed:

The EFS data recovery certificate should be exported to a secure location.

Page 29

Healthcare EFS Tool, Administration Guide Version 1.0.0.0 Baseline

Page 35: Healthcare EFS Tool

Prepared by Microsoft

3. Right-click the certificate and select Export.

4. Click Next and then Yes to Export the Private Key.

5. Click Next and then Next again.

6. Enter a password for the exported key and then click Next.

7. Enter a filename for the exported certificate, which could be on a floppy disk, then select Next and Finish.

The certificate is written to the filename specified. This file should be kept in a secure location (preferably a safe, as the theft of the recovery certificate would allow an attacker to decrypt any files within the healthcare organisation, which needs to be avoided). The password should also be noted because, without this, it will not be possible to recover data.

The backup copy of the certificate can be exported, using the same procedure, which should be put into an alternative safe location as a backup in case of disaster (for example, fire or flood). After exporting the recovery certificate, the certificate can be removed from the computer which will prevent anyone (including administrators) from using it to recover any files.

Note

The DRA backup file is assumed to be called DRA.PFX for the remainder of this document.

By default the DRA certificate created using the above process will have a lifetime of 2 years and, hence, will need to be renewed before it expires. The renewal process is described in section 8.1.

It should again be noted that failure to create a backup of the DRA certificate itself constitutes a high risk to the wellbeing of the entire data recovery solution and strategy. Loss of the DRA certificate will also prevent administrators from accessing data that belongs to users who have left the healthcare organisation, and who no longer have network accounts or profiles.

7.3 EFS Target Folder Customisation Before deploying the EFS Tool, the healthcare organisation’s IT administrator needs to determine which user folders to encrypt. The IT administrator needs to document the paths used by users to store data. Typically user data will be stored within the user's ‘My Documents’ folder but other folders and network drives can also be used. The user's ‘My Documents’ folder may also be redirected to another location.

The EFS Script will need to be amended to include all paths that users store data in. The script includes a variable at line 258 (the debug version) and 265 called ‘aryEFSEncryptList’ that defines which folders to encrypt. aryEFSEncryptList = Array( _

"Local Settings\Application Data", _

"#MyDocuments", _

"Local Settings\Temp", _

"Local Settings\Temporary Internet Files\Content.IE5", _

"OLK")

This variable needs to be updated before deployment of the script to include all user data folders. The variable is an array of comma separated strings. In order to make the code more readable the definition is split across multiple lines by using the ‘_’ line continuation character. The aryEFSEncryptList variable is defined in more detail in section 5.1.3.1.

It is also possible that different groups of healthcare users require different folders to be encrypted. In such a scenario, multiple copies of the EFS Tool will have to be created which will need to be targeted to their respective target user group.

Page 30

Healthcare EFS Tool, Administration Guide Version 1.0.0.0 Baseline

Page 36: Healthcare EFS Tool

Prepared by Microsoft

7.4 EFS Tool Rollout

7.4.1 Configuring EFS Tool Group Policy Object The recommended way of running the EFS Tool is by adding a new Group Policy Object (GPO) to Active Directory. It is recommended that the new GPO is called ‘EFS Users Policy’.

To edit the user logon scripts’ settings in the policy:

1. Start the Group Policy Management Console.

2. Select EFS Users Policy and click Edit.

3. In the Group Policy Object Editor, expand User Configuration > Window Settings and select Scripts (Logon/Logoff).

4. Select the Logon script and click Properties. The Logon Properties dialog box displays:

5. Click Show Files…. A Windows Explorer window displays, showing the logon scripts for the GPO.

Page 31

Healthcare EFS Tool, Administration Guide Version 1.0.0.0 Baseline

Page 37: Healthcare EFS Tool

Prepared by Microsoft

6. Copy the two scripts that form the EFS Tool (StartEFSscript.cmd and EFSFunction.vbs) into the folder. After copying the files, the folder displays the new contents:

7. Close the Windows Explorer window.

8. In the Logon Properties dialog box, click Add…. The Add a Script dialog box displays:

9. Enter StartEFSscript.cmd in the Script Name text box and click OK.

10. Finally, click OK to close the Logon Properties dialog box.

Page 32

Healthcare EFS Tool, Administration Guide Version 1.0.0.0 Baseline

Page 38: Healthcare EFS Tool

Prepared by Microsoft

Page 33

Healthcare EFS Tool, Administration Guide Version 1.0.0.0 Baseline

7.4.2 EFS Tool Deployment via Group Policy Group Policies are normally applied by linking them to specific Organisational Units (OU) within Active Directory. If you are unable to link the ‘EFS Users Policy’ GPO to the existing OUs, it possible to use one of the following alternatives:

Configure an additional OU for EFS users, move the respective users to this OU and apply the ‘EFS Users Policy’.

Create a new security group and populate it with the EFS Users. Apply the ‘EFS Users Policy’ to all the OUs in which the EFS Users reside, but filter the application of the policy based on the newly created security group. This will ensure that the policy only applies to the EFS Users rather than on all users residing in these OUs.

Configure an OU for EFS Computers (rather than users) by enabling merge loopback11 processing in the GPO as shown in Figure 6 below:

Figure 6: Enable Loopback Processing in the GPO

The Active Directory OU structure should be designed following the recommendations found in section 6.1 of the Group Policy for Healthcare Desktop Management guidance {R11}.

7.5 Encryption of Client Side Cache Windows XP clients support the caching of network shares on workstations, such that users are able to continue to work while offline and then synchronise any changes after reconnecting to a network. The Client Side Cache (CSC) can be protected using EFS, but this cannot be done using the EFS Tool itself. However, section 7.5.2 contains a step by step explanation on how to achieve CSC encryption without using the EFS Tool.

Note

Protecting the contents of the CSC requires an additional boot-time password to be manually added to every workstation using the SysKey utility. The loss of this password will render the workstations unbootable (and all data lost) and, therefore, care should be taken before deciding to protect the CSC using SysKey.

7.5.1 Protecting the Client Side Cache Using EFS Files stored in the Client Side Cache can be encrypted using EFS by editing the Default Domain Group Policy (or if required, creating a new Group Policy Object for specifically targeted OUs).

11 Group Policy Loopback processing is described within the Step-by-Step Guide to Understanding the Group Policy Feature Set guide {R12} which can be downloaded from the following location: http://www.microsoft.com/technet/prodtechnol/windowsserver2003/technologies/directory/activedirectory/stepbystep/gpfeat.mspx

Page 39: Healthcare EFS Tool

Prepared by Microsoft

To open the Group Policy Management console:

1. Select Start > Administrative Tools > Group Policy Management. The following window is displayed:

2. Select the appropriate Group Policy Object (in this example, the Default Domain Policy), right-click and select Edit… as shown below:

3. Within the Group Policy Editor, Open Computer Configuration> Administrative Templates > Network > Offline Files. Right-click on Encrypt the Offline Files cache and select Properties:

Page 34

Healthcare EFS Tool, Administration Guide Version 1.0.0.0 Baseline

Page 40: Healthcare EFS Tool

Prepared by Microsoft

4. Enable the encryption of the Offline Files cache and click OK:

7.5.2 Protecting the EFS Machine Keys Using SysKey The files in the CSC are encrypted using a machine based encryption key, rather than the user’s encryption key. This leaves the machine based keys susceptible to various offline attacks which would allow a thief to reset a user password and then access the cached encrypted data. In the default configuration of Windows XP it is relatively easy to reset the local administrator password and get access to the CSC files.

Windows has a mechanism to protect against these attacks by using SysKey, which adds a boot time password to the computer; this means a password must be entered in order to boot the computer.

To enable SysKey on the client:

1. Select Start > Run, type SysKey.exe and click OK. The Securing the Windows XP Account Database dialog box displays:

Page 35

Healthcare EFS Tool, Administration Guide Version 1.0.0.0 Baseline

Page 41: Healthcare EFS Tool

Prepared by Microsoft

2. Click Update. The Startup Key dialog box displays. This allows you to enter a strong password.

Warning

The loss of the password will render the client unbootable and hence recovery of encrypted data on the client will not be possible.

3. Ensure Password Startup is selected and enter a password in both text fields.

4. Click OK. The Securing the Windows XP Account Database dialog box displays.

5. Click OK to finish.

Page 36

Healthcare EFS Tool, Administration Guide Version 1.0.0.0 Baseline

Page 42: Healthcare EFS Tool

Prepared by Microsoft

8 OPERATE During the Operate phase, the deployed EFS Tool and its supporting infrastructure are proactively managed to ensure they provide the required levels of solution reliability, availability, supportability, and manageability.

This section deals with the operation and management of the EFS Tool.

Figure 7 acts as a high-level checklist, illustrating the critical components for ensuring a managed and operational EFS Tool:

Data Recovery Agent Renewal

Data Recovery Operations

Data Migration

Required EFS Tool Support Processes

Recovery Using NTBackup

Recovery Using the DRA on the

User’s Workstation

Recovery Using NTBackup

Recovery Using the DRA on the

User’s Workstation

User Profiles

Network Certificate Authority

Monitoring

EFS Tool Troubleshooting Efslog.log EFSFileList Files

EFS Tool Issues Residual Data Shortcuts Read Only Files

Figure 7: EFS Tool Operate Phase

Page 37

Healthcare EFS Tool, Administration Guide Version 1.0.0.0 Baseline

Page 43: Healthcare EFS Tool

Prepared by Microsoft

8.1 Data Recovery Agent Renewal This section builds on top of section 7.2. As described previously, the DRA certificate will expire after a period of time and will need to be renewed. By default a Network CA will issue a DRA Certificate (using the EFS Recovery Agent template) with a two year lifetime and, hence, the DRA will need to be renewed before it expires. A suggested renewal period is every 18 months. The process for renewal is basically the same as for the initial configuration, as described in section 7.2.

After updating the DRA certificate, Windows XP clients will perform a Group Policy refresh every 90 minutes, with a randomised offset of plus or minus 30 minutes. The change to the GPO may also take from a few minutes to many hours to replicate across all domain controllers within Active Directory depending upon the site and connection topology. Administrators should be careful to make sure that they wait until all clients have received the new DRA before continuing the DRA renewal process.

After a new DRA certificate has been issued, all clients will need to re-encrypt user data with the new DRA. This is done by adding an optional numerical command line parameter to the EFS Tool. The parameter is referred to as the ‘High Water Mark’ (HWM). When not specified in the StartEFSscript.cmd file, the default value of the HWM is 1. Each time the DRA is renewed the HWM parameter will need to be incremented by one.

To change the HWM:

1. Start the Group Policy Management Console.

2. Select EFS Users Policy and click Edit.

3. In the Group Policy Object Editor, expand User Configuration > Window Settings and select Scripts (Logon/Logoff).

Page 38

Healthcare EFS Tool, Administration Guide Version 1.0.0.0 Baseline

Page 44: Healthcare EFS Tool

Prepared by Microsoft

4. Select the Logon script and click Properties. The Logon Properties dialog box displays:

5. Click Show Files… to display the EFS Users Policy logon scripts.

6. Open the StartEFSscript.cmd file in Notepad and add a numerical parameter (each time the DRA is renewed the parameter needs to be incremented by one) to the script as shown below:

start /min /low cscript \\%~p0EFSFunction.vbs 2

7. Save and close the script.

8. Close the logon scripts folder, the Group Policy Object Editor and the Group Policy Management Console.

8.2 Data Recovery Operations After deploying the EFS Tool, it is necessary to have procedures in place that will allow for the recovery of data in the eventuality of a user losing their EFS keys. The user keys are stored in the user profile and could be deleted or corrupted in several ways, including:

The user deletes a certificate from the user certificate store using the Certificate MMC

The user profile is deleted (profile deletions are occasionally done by IT support staff)

The user profile is corrupted

Page 39

Healthcare EFS Tool, Administration Guide Version 1.0.0.0 Baseline

Page 45: Healthcare EFS Tool

Prepared by Microsoft

In the event of the user EFS keys being lost, it will be necessary to use the DRA to recover the encrypted user files.

In order to recover files it is necessary to use the DRA certificate and private keys which were previously backed up following the guidance in section 7.2.3. Without access to the DRA private keys, it is not possible to recover encrypted data. It is assumed that the DRA.PFX file (this was originally created following section 7.2) and password are available during the following processes.

Most major backup solution providers are able to back-up the raw EFS files (using the built-in Windows Backup API). Please verify with your backup solution provider whether the solution is able to back up the file in its encrypted state.

8.2.1 Recovery Using NTBackup The most secure method for recovering encrypted data is to backup the data on the workstation, restore the data onto a recovery computer and then decrypt the data using the DRA on the recovery computer. This approach means that the DRA is controlled and never needs to be installed onto a user laptop (which could potentially be compromised).

Although secure, this approach has the disadvantage of being relatively slow, requiring all user data to be first backed up, then restored and decrypted.

To recover the user’s encrypted files and data using NTBackup: Note

Third-party backup products can also be used to perform this process although the screenshots and process will vary slightly

1. Start the NTBackup Application (ntbackup.exe). The Backup or Restore Wizard displays:

2. Click Next.

Page 40

Healthcare EFS Tool, Administration Guide Version 1.0.0.0 Baseline

Page 46: Healthcare EFS Tool

Prepared by Microsoft

3. Select Back up files and settings and click Next. The What to Back Up page displays:

4. Select Let me choose what to back up and click Next. The Items to Back Up page displays:

5. Select all files and folder that belong to the user and click Next.

6. Set the destination location for the backup to be on a network share on the recovery computer and click Next.

7. Click Finish to perform the backup.

After the backup of the user’s data has been completed, the data is ready to be restored on the destination recovery computer using the NTBackup utility.

Page 41

Healthcare EFS Tool, Administration Guide Version 1.0.0.0 Baseline

Page 47: Healthcare EFS Tool

Prepared by Microsoft

8. Create a Restore directory on the recovery computer using Windows Explorer. (This will be used later.)

9. Start the NTBackup Application (ntbackup.exe) as shown in step 1 and click Next.

10. Select Restore files and settings and click Next.

11. Click Browse…, navigate to the location specified in step 6 above and select the backup file that was created.

12. Double-click on the backup file.

13. Select all files and folders that need to be restored and click Next.

14. Click Advanced….

15. Change the restore file location to Alternative Location. Enter the name of the recovery directory created in step 8 and click Next.

16. Click Next > Next and then Finish to restore the files.

The files will have been restored on to the recovery computer, ready for decryption.

17. To start the Certificates MMC, select Start > Run, type certmgr.msc and click OK. The Certificates dialog box displays.

18. Expand Certificates - Current User > Personal > Certificates:

19. Right-click on the personal Certificates folder and select Import. The Certificate Import Wizard displays.

20. Click Next.

21. In the File to Import page, enter the location of the DRA.PFX file (this was originally created following section 7.2) and click Next.

22. Enter the password for the DRA and click Next.

23. Click Next and then Finish to import the certificate and private key into the certificate store on the recovery computer.

It is now possible to decrypt all the user data on the recovery computer using the Windows Explorer interface.

Page 42

Healthcare EFS Tool, Administration Guide Version 1.0.0.0 Baseline

Page 48: Healthcare EFS Tool

Prepared by Microsoft

24. Start Windows Explorer, right-click the relevant folder and select Properties. The {Folder} Properties dialog box displays:

25. Click Advanced…. The Advanced Attributes dialog box displays:

26. De-select the Encrypt contents to secure data check box (as shown above) and click OK. All the user data will be decrypted.

After the data has been decrypted, the following should be carried out:

The user should copy the data back to the workstation using Windows Explorer (the user will need to be given access to the network share on the recovery computer in order to do this)

The DRA should be removed from the recovery computer by selecting the DRA certificate in the Certificates MMC and selecting Delete.

Page 43

Healthcare EFS Tool, Administration Guide Version 1.0.0.0 Baseline

Page 49: Healthcare EFS Tool

Prepared by Microsoft

8.2.2 Recovery Using the DRA on the User’s Workstation This method for recovering data is less secure than the method described in section 8.2.1 above, but it is considerably faster. This approach should be used where there is a very large volume of data that would take too long to backup and restore to another computer.

This approach requires that the DRA certificate and private keys are installed onto a user workstation. This means that it is theoretically possible for a malicious user to take a copy of the DRA certificate and private key using an installed Trojan; thus gain access to every encrypted file from every workstation for which the DRA has the authority to encrypt/decrypt files.

To recover the user’s encrypted files and data using DRA on their workstation:

1. Log onto to the user’s workstation as an Administrator.

2. Start the Certificates MMC by selecting Start > Run, typing certmgr.msc and clicking OK. The Certificates dialog box displays.

3. Expand Certificates – Current User > Personal > Certificates.

4. Right-click on the personal Certificates folder and select Import. The Certificate Import Wizard displays.

5. In the Certificate Import Wizard, click Next.

6. In the File to Import page, enter the location of the DRA.PFX file (this was originally created following section 7.2) and click Next.

7. Enter the password for the DRA and click Next.

8. Click Next and then Finish to import the certificate and private key into the certificate store on the user’s workstation.

It is now possible to decrypt all the user data on the user’s workstation using the Windows Explorer interface.

9. Start Windows Explorer, right-click the relevant folder and select Properties. The {Folder} Properties dialog box displays.

Note

In certain circumstances depending upon the user’s file permissions, it may be necessary for an administrator to take ownership of the user’s files and then change the permissions before continuing.

10. Select Advanced…. The Advanced Attributes dialog box displays.

11. De-select the Encrypt contents to secure data check box and select OK. All the user data will be decrypted.

12. After the data has been decrypted, the DRA should be removed from the user’s workstation by selecting the DRA certificate in the Certificates MMC and selecting Delete.

Page 44

Healthcare EFS Tool, Administration Guide Version 1.0.0.0 Baseline

Page 50: Healthcare EFS Tool

Prepared by Microsoft

8.3 Data Migration If computers are to be migrated between different Active Directory domains or forests, all encrypted user data will also need to be migrated.

Data migration will involve the decryption of all user data and then the re-encryption after the user has joined the new domain.

8.3.1 Data Migration Using DRA For a small number of computers, it is possible to decrypt data prior to computer migration by using the process described in section 8.2.2. All encrypted data on a workstation can be decrypted in a single operation by this mechanism, regardless of how many users have used a workstation.

Note

For a large number of workstations, this approach will prove to be time consuming. The process detailed in the following section 8.3.2 provides an alternative method.

8.3.2 Data Migration Using EFS Tool An alternative mechanism to migrate all user data is to force decryption of user data using the EFS Tool. This approach is useful for situations where there are a large number of workstations to be migrated. The main disadvantage of this approach is that it requires each user who has encrypted data to logon to the workstation before decryption is completed. The decryption process can also potentially fail for files that are held open by applications and are “locked”. Where important files are left encrypted, it may be necessary to stop applications to allow manual decryption or alternatively use the DRA based Data Migration process described in section 8.3.1 above.

After the data has been decrypted by this process, the workstation can be migrated from one domain to another.

To force decryption of all data:

1. Start the Group Policy Management Console.

2. Select EFS Users Policy and click Edit.

3. In the Group Policy Object Editor, expand User Configuration > Window Settings and select Scripts (Logon/Logoff).

4. Select the Logon script and click Properties. The Logon Properties dialog box displays (as shown in section 8.1 previously).

5. Click Show Files… to display the EFS Users Policy logon scripts.

6. Open the StartEFSscript.cmd file in Notepad and add the DECRYPT parameter to the script, as shown below: start /min /low cscript \\%~p0EFSFunction.vbs DECRYPT

7. Save close the script.

8. Close the logon scripts folder, the Group Policy Object Editor and the Group Policy Management Console.

The next time the user logs onto a computer, the EFS Tool will start decrypting all the user data. If a workstation is shared by several users, all of the users must log onto it to complete the decryption process before the migration can be completed.

Page 45

Healthcare EFS Tool, Administration Guide Version 1.0.0.0 Baseline

Page 51: Healthcare EFS Tool

Prepared by Microsoft

Page 46

Healthcare EFS Tool, Administration Guide Version 1.0.0.0 Baseline

8.4 Required EFS Tool Support Processes Some general support process may need to be changed in order to take account of the EFS Tool. Specifically IT administrator/professional handling of user profiles will need to change in many environments. Lastly, the Network CA will need to be periodically checked to make sure that it is functioning correctly.

8.4.1 User Profiles User profiles are used to store all sorts of user preferences and settings. These profiles can sometimes become corrupt (for various reasons outside of the scope of this document). Therefore, many support organisations routinely delete user profiles in order to attempt to solve user support issues. It is paramount to understand that when EFS is being used, this approach can have disastrous consequences as the user EFS certificate and private keys are part of the user profile.

Important Recommendations

The user’s profile should not be deleted unless as a last resort to resolve support issues.

Attempt to decrypt all user data using the Windows Explorer interface prior to deleting the user profile.

If the user profile needs to be deleted in order to resolve a problem, the user’s data must first be decrypted. Failure to do this will result in the user being unable to access their files and the administrator having to follow the Data Recovery Guidance in section 8.2 above.

Windows XP SP2 now supports Credential Roaming for users with local (non-roaming) profiles. Credential Roaming allows the user’s certificates to be replicated between computers using Active Directory rather than relying on a roaming profile. The use of Credential Roaming allows automatic recovery of certificates within a deleted user profile without administrator intervention and thus should dramatically reduce the impact of profile deletions. For more information on Credential Roaming, see User credential roaming {R7}.

8.4.2 Network Certificate Authority Monitoring The Network CA should be regularly checked to ensure that it is functioning correctly. This can be done either using an automated monitoring solution or manually. One way to manually check the health of the Network CA is by using the PKI Health Tool that is part of the downloadable Windows Server 2003 Resource Kit Tools12.

To run the PKI Health Tool:

After installing the resource kit, select Start > Run, type pkiview.msc and click OK. The PKI Health Tool displays a main window similar to Figure 8.

12 Windows Server 2003 Resource Kit Tools {R13}: http://www.microsoft.com/downloads/details.aspx?FamilyID=9d467a69-57ff-4ae7-96ee-b18c4790cffd&DisplayLang=en

Page 52: Healthcare EFS Tool

Prepared by Microsoft

Page 47

Healthcare EFS Tool, Administration Guide Version 1.0.0.0 Baseline

Figure 8: PKI Health Tool

The PKI Heath Tool allows the CA certificate to be checked. (The Network CA certificate will by default expire after 25 years and, hence, will typically never need to be renewed.)

The PKI Health Tool also displays the revocation and CA certificate publication points. The Authority Information Access (AIA) locations are used to publish the CA certificate. For more information on CA certificate publication points, AIA and CDP locations and Windows based PKI, see Best Practices for Implementing a Microsoft Windows Server 2003 Public Key Infrastructure13.

8.4.2.1 Revocation Checking When a certificate private key has been compromised, for whatever reason, the certificate should be manually revoked on the Network CA. All revoked certificates are added to the Certificate Revocation List (CRL) that is periodically published by the Network CA. The Network CA will publish the revocation list weekly with an overlap of four days.

Every certificate issued by the Network CA includes a CRL Distribution Points (CDP) extension that is used to indicate where the CRL for the certificate may be obtained. Delta CRLs (small changes to the CRL since the previous full CRL publication) may also be published by a CA if required.

The PKI Health Tool reads the various CRLs from the CDP locations, and displays whether or not the CRLs are valid. If for any reason any of these locations are not available, the PKI Health Tool will highlight it in red.

The PKI Health Tool should be run on a daily basis to check that all AIA and CDP locations are still valid, and that the CRL has not expired. Failure to do this will lead to EFS certificates failing revocation checks, which will cause operational issues.

13 Best Practices for Implementing a Microsoft Windows Server 2003 Public Key Infrastructure {R14}: http://technet2.microsoft.com/WindowsServer/en/library/091cda67-79ec-481d-8a96-03e0be7374ed1033.mspx

Page 53: Healthcare EFS Tool

Prepared by Microsoft

8.5 EFS Tool Troubleshooting The EFS Tool may sometimes not work as expected. This section attempts to document the different ways in which the EFS Tool may fail, as well as provide guidance on how to determine and correct the problem.

The EFS Tool generates log files. If the EFS Tool is not working as expected, the log files should be checked for any errors. Table 4 summarises the two different types of log files that the EFS Tool generates.

Log File Name Log File Location Description

efslog.log %UserProfile%\Local Settings\Logs (default location) For example: C:\Documents and Settings\<username>\Local Settings\Logs

The main EFS Tool log file. The log file is stored in the Logs folder in the user’s local settings folder.

EFSFileList{<folder>}.log %UserProfile%\Local Settings\Logs (default location) For example: C:\Documents and Settings\<username>\Local Settings\Logs

An additional log file is generated for each folder that is encrypted by the EFS Tool. The additional files are stored in the EFS Tool log files folder.

Table 4: EFS Tool Log Files

8.5.1 Efslog.log This log file is created by the EFS Tool during script processing. The Efslog.log includes error and other potentially useful information, including:

A usage message if invalid parameters are passed to the script

Various fatal error messages, including those shown in Table 5 below

Error Message Description Could not load CAPICOM store object - Check CAPICOM installed

Can be caused by CAPICOM {R1} either not being installed or registered. The CAPICOM library needs to be registered on every workstation by using the regsrv32 command as follows: regsrv32 capicom.dll. The user also needs permission to access Capicom.dll in the file system (required user permission is Read and Execute).

Could not encrypt test file (EFS is not working for some unexpected reason)

The script attempts to encrypt a single test file to force an enrolment to the Network CA. This may fail, for instance, if the client does not have permissions to enrol or the Network CA is offline.

No EFS certificate thumbprint found The operating system stores the thumbprint of the current EFS certificate in the registry. This error means that the thumbprint is not present and may be caused by registry corruption or registry permissions issues.

No enterprise EFS certificates found in user store (No Network CA found)

After attempting to enrol for an EFS certificate form a network CA, the script checks that a certificate was actually issued. This may fail for instance if the client does not have permissions to enrol or the CA is offline. Check that the CA is online and also run the PKI Health tool (see section 8.4.2).

Could not set EFS thumbprint in user registry The script attempts to save the certificate hash to the registry. If this fails, this error is generated. This error may be caused by registry corruption or registry permissions issues. Registry corruption might potentially be caused by shortage of memory, installed malware, software or hardware errors or bugs (and potentially other causes).

Page 48

Healthcare EFS Tool, Administration Guide Version 1.0.0.0 Baseline

Page 54: Healthcare EFS Tool

Prepared by Microsoft

Page 49

Healthcare EFS Tool, Administration Guide Version 1.0.0.0 Baseline

Error Message Description Error reading HWM from registry The HWM parameter is saved into the registry when the script is first run.

This error is generated when the HWM is not found and may be caused by registry corruption or permissions problems. Registry corruption might potentially be caused by shortage of memory, installed malware, software or hardware errors or bugs (and potentially other causes).

Errors running the encryption/decryption/re-encryption process:

Error invalid command passed to EFSEncrypt This error should not be possible.

Could not exec cipher.exe to perform EFS operation The cipher command failed to run. This could be caused by the user not having the appropriate permissions to run the executable, or possibly by the Cipher command having been removed from a workstation.

Error folder does not exist One or more of the folders specified in the aryEFSEncryptList array does not exist or is not valid. See section 7.3 for more details on configuring this array.

Error refreshing EFS file DDFs:

Could not exec cipher.exe to refresh EFS FEKs The cipher command failed to run. This could be caused by the user not having the appropriate permissions to run the executable, or possibly by the Cipher command having been removed from a workstation.

Error updating EFS High Water Mark:

Error unable to save the new HWM in the registry The registry write operation failed, this could be due to registry corruption or by the user not having the appropriate permissions to write to the registry. Registry corruption might potentially be caused by shortage of memory, installed malware, software or hardware errors or bugs (and potentially other causes).

ChkOSVersion failed version check The EFS Tool is designed to run on Windows XP SP1 or above. It will not run on Windows 95, 98, ME, NT, 2000, Windows Server 2003 or Windows Vista.

DRA is not valid The Data Recovery Agent is not valid. This can be caused by various reasons including: DRA Expiry – typically every 2 years The DRA is self-signed as the process documented in section 7.2 has

not been followed The DRA has been revoked The DRA is not issued by a trusted CA

Table 5: Fatal Error Messages

8.5.2 EFSFileList Files For each folder that is encrypted, a corresponding log file gets created in the Local Settings\Logs folder. These files contain the output of the Cipher command as it encrypts or decrypts files.

Each time the user logs onto the computer, all the logs in this folder are updated. As a general rule most of the file encryption operations will succeed and hence there should be few, if any errors in these files. Some folders and files are held open and locked either by the operating system (for instance explorer.exe) or by third-party applications and, hence, operations on these files or folders will fail. This is expected behaviour and should not be considered an issue. Other files may be marked as read-only and these files will also not be changed by the Cipher command.

Page 55: Healthcare EFS Tool

Prepared by Microsoft

8.6 EFS Tool Issues The sections below detail the known issues with the EFS Tool.

8.6.1 Residual Data EFS incorporates a crash recovery scheme to ensure that data is not lost in the event of a fatal error, such as system crash, disk full, or hardware failure. This is accomplished by creating a plaintext backup of the original file that is being encrypted or decrypted. Once the original is successfully encrypted or decrypted, the backup is deleted.

Creating a plaintext copy has a side effect; the plaintext version of the file may exist on the disk until those disk blocks are overwritten by NTFS for some other file. Therefore, if the EFS Tool is run on a drive with existing user data, it may be possible to recover some or all of the encrypted files by using an undelete utility or other low-level disk utility.

It is possible to manually wipe deleted files on a disk by using the following command (this will wipe all unused space on drive C:): Cipher /W:C:\

The main disadvantage of doing this is that it takes a considerable amount of time to run and, therefore, it is not practical to automate the running of the Cipher /W command within the EFS Tool.

On a typical workstation, the Cipher /W command will be able to wipe approximately 1GB of free disk space per minute. For a modern 200GB disk that is largely empty (180GB of free space), the command would be expected to run for at least 3 hours. During this time, the disk would be very heavily utilised. These performance figures will vary depending upon the disk performance of a workstation.

The Cipher /W command should be run periodically when the workstation is not going to be in use for several hours (for example, the command could be run during the night).

8.6.2 Shortcuts When the EFS Tool finds a shortcut within a folder that is set to be encrypted, it encrypts the shortcut file, but will not encrypt the target of the shortcut. For instance, the ‘My Documents\My Pictures’ folder contains a shortcut to the Sample Pictures folder (stored in ‘All Users\Documents\My Pictures\Sample Pictures’). When the EFS Tool runs, the shortcut file is encrypted but the Sample Pictures folder is not.

This behaviour is by design. If the shortcuts point to user data that resides in other folders, these should be added to the list of folders to be encrypted by modifying the aryEFSEncryptList variable. For more information on this, see section 5.1.3.1.

8.6.3 Read Only Files The EFS Tool will not currently encrypt files that are set to be read only within the user’s folders. This behaviour is by design.

If this is viewed as a serious issue by a healthcare organisation, the script can be modified to automatically remove the read only attribute from user files before the encryption operation is performed.

The following block of code (line 1537 in the script): strCmd = "cmd /c attrib -h -r """ & strEFSPath & """ >> """ & strEFSFileLog & """ 2>&1"

EFSWriteLog("EFS Attrib Command Line - " & strCmd )

Call objWshShell.Run(strCmd, 0, RUN_SYNC)

Page 50

Healthcare EFS Tool, Administration Guide Version 1.0.0.0 Baseline

Page 56: Healthcare EFS Tool

Prepared by Microsoft

should be updated to include three additional lines below the original code: strCmd = "cmd /c attrib -h -r """ & strEFSPath & """ >> """ & strEFSFileLog & """ 2>&1"

EFSWriteLog("EFS Attrib Command Line - " & strCmd )

Call objWshShell.Run(strCmd, 0, RUN_SYNC)

strCmd = "cmd /c attrib -h -r """ & strEFSPath & "\*.*"" /s /d >> """ & strEFSFileLog & """ 2>&1"

EFSWriteLog("EFS Attrib Command Line - " & strCmd )

Call objWshShell.Run(strCmd, 0, RUN_SYNC)

The replacement code will recursively remove the ‘read only’ and ‘hidden’ attributes from all user files, and folders, specified for encryption.

Page 51

Healthcare EFS Tool, Administration Guide Version 1.0.0.0 Baseline

Page 57: Healthcare EFS Tool

Prepared by Microsoft

Page 52

Healthcare EFS Tool, Administration Guide Version 1.0.0.0 Baseline

APPENDIX A SKILLS AND TRAINING RESOURCES The tables in this appendix provide details of the suggested training and skill assessment resources available. This list is not exhaustive; there are many third-party providers of such skills. The resources listed are those provided by Microsoft.

PART I EFS

Skill or Technology Area Resource Location Description

Implementing and Administering Security in a Microsoft Windows Server 2003 Network

http://www.microsoft.com/learning/syllabi/en-us/2823bfinal.mspx

Course 2823: Five days; instructor-led

Applying Microsoft Security Guidance

http://www.microsoft.com/learning/syllabi/en-us/2811bfinal.mspx

Course 2811: One day; instructor-led

Designing Security for Microsoft Networks

http://www.microsoft.com/learning/syllabi/en-us/2830Afinal.mspx https://www.microsoftelearning.com/eLearning/offerDetail.aspx?offerPriceId=45924

Course 2830: Three days; instructor-led Microsoft eLearning Library (MELL): Designing Security for Microsoft Networks

Designing and Managing a Windows Public Key Infrastructure

http://www.microsoft.com/learning/syllabi/en-us/2821Afinal.mspx

Course 2821: Four days; instructor-led

Implementing and Administering Security in a Microsoft Windows Server 2003 Network

http://www.microsoft.com/learning/exams/70-299.asp MCSA/MCSE Training Kit (Exam 70-299)

Table 6: EFS Training

PART II Group Policy – Both Domain and Local

Skill or Technology Area Resource Location Description Controlling Operating System configuration and security

http://www.microsoft.com/grouppolicy Follow links on the page to resources

Design and implementation for application deployment

As above As above

Management using Microsoft Group Policy Management Console (GPMC): scripting, policy export and import, backup and restore

As above As above

Implementation within an Active Directory Organisational Unit hierarchy and using security groups to control scope

As above As above

Table 7: Group Policy Training

Page 58: Healthcare EFS Tool

Prepared by Microsoft

Page 53

Healthcare EFS Tool, Administration Guide Version 1.0.0.0 Baseline

PART III Supplemental Training Resources

Title Link

Microsoft Windows Group Policy Guide ISBN 0-7356-2217-5

http://www.microsoft.com/MSPress/books/8763.asp

Microsoft® Windows Server™ 2003 PKI and Certificate Security ISBN 0-7356-2021-0

http://www.microsoft.com/MSPress/books/6745.asp

Protect Your Windows Network – From Perimeter to Data ISBN 0-3213-3643-7

http://www.awprofessional.com/bookstore/product.asp?isbn=0321336437&redir=1&rl=1#info1

TechNet Technical Training – Training CDs are released on a regular basis on many topics

http://www.microsoft.com/technet/security/default.mspx

(ISC)2 CISSP The (ISC)2 training and the CISSP examination are both worthwhile for security professionals working within the IT industry. This training is not specific to any vendor or technology but covers security from all aspects including design, physical and logical.

http://www.isc2.org

Table 8: Supplemental Training Resources

Page 59: Healthcare EFS Tool

Prepared by Microsoft

APPENDIX B EFS SCRIPT UTILITY FUNCTIONS There are many utility functions used by the EFS Tool script to perform various activities. These are detailed in Table 9 below:

Function Description

FindOLKFolder The Outlook temporary files folder name varies for each user profile, therefore, this function finds the actual folder name used by Outlook

EFSEnabled Checks local registry for a valid EFS recovery policy. If there is one there, it checks the certificate to make sure it is a domain certificate. If either of these checks fail, it returns false

GetEFSCertificateThumbprint Reads the thumbprint of the EFS certificate from the user's profile

SetEFSCertificateThumbprint Writes the thumbprint of the EFS certificate to the user's profile

GetCertFromStore Retrieves a certificate from the store that matches the passed thumbprint

EFSCertificateValid Checks EFS Certificate: In validity period Valid chain Not revoked Issued from current CA Contains EFS Usage

EFSRACertificateValid Checks EFS Recovery Agent Certificate: In validity period Valid chain and trusted root Not revoked

FindEFSCertInStore Searches through user certificate store for valid EFS certificate

EFSEncryptTestFile Encrypts a random file to force EFS operation. This forces the client to enrol for an EFS certificate from a Network Certificate Authority

EFSRefreshDDFs Forces a refresh of all Data Decryption and Data Recover fields on all local drives

EFSEncrypt Performs requested EFS action on supplied list of files/folders

CheckLogsFolder Checks that the log folder path exists and can be written. If the folder does not exist, it is created

EFSNewThumbprint Compares new EFS Certificate hash (thumbprint) to a previously stored value. If different, the stored hash is updated and the function returns true

EFSNewHWM Compares the current HWM against the one stored locally. If different, returns true and updates the HWM stored in the registry

EFSUpdateHWM Compares the current HWM against the one stored locally. If different, returns true.

EFSFatalError Reports error and quits

EFSError Reports error

EFSOpenFile Opens a text file and returns textstream object

EFSCloseFile Closes an open file

EFSWriteLog Writes a line to the log file

ByteToHexString Converts array of bytes to hex string

HexToByteString Converts hex string to array of bytes

ByteArrayToBinString Converts array of bytes to a binary string

RegWriteBinary Uses WMI Registry provider to write binary value since the Wscript RegWrite function only handles single-byte items

Table 9: Utility Functions Required

Page 54

Healthcare EFS Tool, Administration Guide Version 1.0.0.0 Baseline

Page 60: Healthcare EFS Tool

Prepared by Microsoft

APPENDIX C NETWORK CERTIFICATE AUTHORITY

Figure 9: Network CA

Recommendation

It is recommended that healthcare organisations implement a PKI based on Windows Server 2003 Certificate Services that is able to meet all PKI requirements within the organisation. The Network CA described in this appendix provides the minimum CA functionality required to implement the other security technologies in the guide and should not be considered a full PKI.

The Network or Embedded CA (see Figure 9) is required in order to issue certificates to both computers and to users. The Network CA is designed to meet the following requirements:

Computer Authentication certificates are required for the Radius servers to authenticate them to clients

Computer Authentication certificates are required on the ISA Server 2004 VPN server in order to authenticate and provide encryption of IPsec traffic

Computer Authentication certificates are required for every client that will be using the VPN Remote Access in order to authenticate the client to the VPN server (using L2TP/IPsec)

EFS Encryption certificates are required by all users who wish to encrypt data

PART I Network CA Design The Network or Embedded CA will comprise a single tier (rather than traditional multi tier) PKI as shown in Figure 10.

Figure 10: Network CA Single Tier PKI Hierarchy

Page 55

Healthcare EFS Tool, Administration Guide Version 1.0.0.0 Baseline

Page 61: Healthcare EFS Tool

Prepared by Microsoft

The Network CA will be built following the scripts contained in the guide: Microsoft Securing Wireless LANs with PEAP and Passwords {R3}. The CA will be built with a 2048 bit Rivest Shamir Adleman (RSA) self signed certificate valid for 25 years. The CA will publish a revocation list to Active Directory every week with an overlap time of four days.

The Network CA is however not designed as a general purpose PKI and should only be used for issuing certificates in order to support certificate requirements for securing infrastructure.

PART II Installing the Network CA The Network CA will be installed by following the Network CA build instructions within the Building the Network Certification Authority chapter of the guide: Securing Wireless LANs with PEAP and Passwords {R3}.

Before installing the Network CA the following steps are required:

Install CAPICOM

Install GPMC

Install Windows Server 2003 Support Tools

Install the Securing Wireless LANs with PEAP and Passwords tools

After performing the above installations, change directory to “C:\Program Files\Microsoft\Microsoft WLAN-PEAP Tools\” (or wherever the tools were installed) and run the following commands: > MSSsetup CheckCAenvironment

> MSSsetup InstallCA

> MSSsetup VerifyCAInstall

> MSSsetup ConfigureCA

> MSSsetup ImportAutoenrollGPO

> MSSsetup VerifyCAConfig

PART III Configuring the Network CA The Network CA should now be successfully installed but will need to be configured in order to issue certificates required by this guide.

The Network CA is not configured to issue EFS certificates and hence it needs to be updated to do so. The permissions on the computer’s certificate template also require updating to allow any computer within the domain to enrol for a computer certificate. Lastly the Default Domain Group Policy Object needs to be changed to allow workstations and servers in the domain to enrol for computer certificates.

The Network CA will now need to be configured to issue EFS certificates (both user EFS certificates and EFS data recovery certificates) by running the following commands: C:> Certutil -SetCATemplates +"EFS"

C:> Certutil –SetCATemplates +"EFSRecovery"

The computer’s certificate template permissions also need to be modified to allow computers that are members of the domain to enrol for computer certificates. Run the following command, after first changing <CONTOSO> to match the healthcare organisation’s Active Directory: C:> dsacls "cn=Machine,cn=Certificate Templates,CN=Public Key Services,CN=Services,CN=Configuration,DC=<CONTOSO>,DC=contoso,DC=com" /G "Domain Computers":CA;Enroll;

After this the Default Domain Policy requires updating to enable the enrolment of computer certificates across the domain.

Page 56

Healthcare EFS Tool, Administration Guide Version 1.0.0.0 Baseline

Page 62: Healthcare EFS Tool

Prepared by Microsoft

To enrol the certificates across the domain:

1. Start the Group Policy Editor and navigate to the Automatic Certificate Request Settings.

2. Right-click Automatic Certificate Request Settings, and select New > Automatic Certificate Request:

3. In the Automatic Certificate Request Setup Wizard, click Next.

4. From the Certificate templates page, select Computer:

5. Click Next, and then Finish.

After building and configuring the CA it take several hours before the Microsoft infrastructure will fully synchronise to use the CA. Delays that can occur include the following:

The directory synchronisation across Active Directory can take anything from a few minutes to a few hours depending upon how the replication topology is configured.

Typically within a site will replicate in under a minute (15/45).

Between sites typically can take up to 3 hours.

Page 57

Healthcare EFS Tool, Administration Guide Version 1.0.0.0 Baseline

Page 63: Healthcare EFS Tool

Prepared by Microsoft

The clients also need to wait for the GPO refresh cycle which takes up to 2 hours by default.

Computers also maintain a certificate template cache which updates typically every 20 minutes.

PART IV Summary The Network CA is designed as an embedded CA to provide certificates that enable the infrastructure to be secured. This CA should not be considered a full PKI but more an embedded point PKI.

The Network CA will have minimal implement and operational complexity and cost, with the installation and configuration largely automated.

Page 58

Healthcare EFS Tool, Administration Guide Version 1.0.0.0 Baseline

Page 64: Healthcare EFS Tool

Prepared by Microsoft

APPENDIX D PERFORMANCE TEST RESULTS This appendix contains Performance Test results for the Healthcare EFS Tool.

Important

All information in this document refers to the Healthcare EFS Tool build number 1.0.060907.000 produced by Microsoft on 07 September 2006.

The tests were aimed at assessing any end user productivity impact whilst running the script.

The response times for opening and editing a Word document were investigated. This was done using a 1MB Word 2003 document (using Word 2003 SP2) whilst running the EFS script on a real (not virtual PC) Windows XP SP2 client with CAPICOM installed. The script was triggered at logon, and interacted with a certificate server on a virtual machine running Windows 2003 Advanced Server.

PART I Conclusions The EFS Tool script runs several cipher processes to encrypt the files. These processes are run at low priority and do not significantly impact applications once the user’s applications are loaded into memory.

When the script runs for the first time, all the user’s files (in the specified directories) must be encrypted. The cipher processes cause a large number of disk accesses, as each file is read, encrypted and written. As a consequence, any disk related activity, such as application loads and saves, are slowed. The tests focused on application loading and disk access. Response times were found to be:

Twice as long when starting on a newly booted machine and no user applications had been launched (cold start)

Fifty percent longer when Word had already been launched (warm start)

The cipher processes mark the target folders as encrypted. Files created or copied into these folders are encrypted in real time by the file system. Once the initial bulk encryption is complete, the cipher tasks skip encrypted files and only process files that have been unencrypted within the target folders. The cipher tasks ran for around a minute, after that performance returned to normal.

PART II Performance Test Details

Test Environment The specification of the client machine was:

Pentium® III 500 MHz processor

384 MB RAM

12.6 GB Hard Disk Drive

Word 2003 SP2 was used to manipulate a 1MB Word 2003 document

A manual stopwatch was used to record the response time

The data to be encrypted consisted of 1GB of files, which were evenly distributed in the folders:

My Documents

Local Settings\Application Data

Local Settings\Temp

Page 59

Healthcare EFS Tool, Administration Guide Version 1.0.0.0 Baseline

Page 65: Healthcare EFS Tool

Prepared by Microsoft

Initial Encryption This is to simulate the first time the script is run. All files and folders start as unencrypted.

The timing was started in the following way:

1. The user logged onto the machine.

2. The Windows Task Manager was launched.

3. The timing was started in the following way:

Without the EFS script running (control test), the timing was started when the wait cursor had stopped.

With the EFS script running, the timing was started when the cipher tasks appeared on the Task Manager processes list.

The timed tests consisted of two parts:

Part 1:

1. The document was opened by double-clicking the desktop shortcut.

2. The document was paged down five pages and “the cat sat on the mat” was typed.

3. If the typing was echoed directly to the screen, the clock was stopped. If the text was not displayed directly, the sentence was retyped until the application ‘caught up’, and then the clock was stopped.

Part 2:

1. The document was opened by double-clicking the desktop shortcut.

2. A picture image (70 KB JPEG) was inserted into the document from a disk file. The clock was stopped when the picture showed in the document.

Subsequent Encryption This is to simulate the normal running conditions, where all files are encrypted in the specified directories.

The same tests were run as the initial encryption tests above.

Page 60

Healthcare EFS Tool, Administration Guide Version 1.0.0.0 Baseline

Page 66: Healthcare EFS Tool

Prepared by Microsoft

PART III Test Results All timings below are listed in seconds. Table 10 shows the results for the initial encryption and Table 11 shows subsequent encryption. The following terms are used:

Cold Start – Reboot the machine, log on and immediately run the test

Warm Start – Already logged on, launched Word and then run the test

Note

These observed timings should be considered as indicative numbers only.

With or Without the EFS Script Running? Run

Cold Start Warm Start

Test 1 Test 2 Test 1 Test 2

Without EFS script 1 15 8 10 5

2 20 15 10 8

3 12 12 8 5

With EFS script 1 45 15 15 8

2 15 35 12 10

3 15 20 11 8

Table 10: Initial Encryption Test Results – Time in Seconds 

With or Without the EFS Script Running? Run

Cold Start Warm Start

Test 1 Test 2 Test 1 Test 2

Without EFS script 1 12 9 11 5

2 40 15 10 6

3 15 7 11 6

With EFS script 1 18 8 9 6

2 17 10 9 6

3 12 8 10 6

Table 11: Subsequent Encryption Test Results – Time in Seconds

Page 61

Healthcare EFS Tool, Administration Guide Version 1.0.0.0 Baseline

Page 67: Healthcare EFS Tool

Prepared by Microsoft

Page 62

Healthcare EFS Tool, Administration Guide Version 1.0.0.0 Baseline

APPENDIX E DOCUMENT INFORMATION

PART I Terms and Abbreviations

Abbreviation Definition AIA Authority Information Access

CA Certificate Authority

CAPICOM Crypto API COM

CDP CRL Distribution Points

CRL Certificate Revocation List

CSC Client Side Cache

DC Domain Controller

DDF Date Decryption Fields

DNS Domain Naming Service

DRA Data Recovery Agent

EFS Encrypting File System

HWM High Water Mark

IP Internet Protocol

LAN Large Area Network

MELL Microsoft eLearning Library

MOF Microsoft Operations Framework

MSF Microsoft Solutions Framework

NAT Network Address Translation

OU Organisational Unit

PEAP Protected Extensible Authentication Protocol

PKI Public Key Infrastructure

WMI Windows Management Instrumentation

Table 12: Terms and Abbreviations

PART II References

Reference Document Version R1. Microsoft Download Center: Platform SDK Redistributable: CAPICOM:

http://www.microsoft.com/downloads/details.aspx?FamilyID=860ee43a-a843-462f-abb5-ff88ea5896f6&DisplayLang=en

R2. Microsoft Download Center: Group Policy Management Console with Service Pack 1: http://go.microsoft.com/fwlink/?LinkId=46570

R3. Microsoft Download Center: Securing Wireless LANs with PEAP and Passwords: http://www.microsoft.com/downloads/details.aspx?FamilyID=60c5d0a1-9820-480e-aa38-63485eca8b9b&displaylang=en

Page 68: Healthcare EFS Tool

Prepared by Microsoft

Page 63

Healthcare EFS Tool, Administration Guide Version 1.0.0.0 Baseline

Reference Document Version R4. Microsoft TechNet: Overview of Securing Wireless LANs with PEAP and Passwords:

http://www.microsoft.com/technet/security/guidance/cryptographyetc/peap_0.mspx

R5. Microsoft Download Center: Microsoft Solutions Framework Core Whitepapers: http://www.microsoft.com/downloads/details.aspx?FamilyID=e481cb0b-ac05-42a6-bab8-fc886956790e&DisplayLang=en

R6. Microsoft TechNet: Microsoft Operations Framework: MOF Executive Overview: http://www.microsoft.com/technet/itsolutions/cits/mo/mof/mofeo.mspx

R7. Microsoft TechNet: Microsoft Windows Server TechCenter: User credential roaming: http://technet2.microsoft.com/WindowsServer/en/library/ef08bb73-716a-4476-95ba-882714c26b991033.mspx?mfr=true

R8. Microsoft TechNet: Microsoft Windows Server TechCenter: Upgrading from a Windows 2000 domain: http://technet2.microsoft.com/WindowsServer/en/library/1e2541bb-d42c-49ef-9f8a-18e30b4f26671033.mspx?mfr=true

R9. Microsoft TechNet: Windows Client TechCenter: Data Protection and Recovery in Windows XP: http://technet.microsoft.com/en-us/library/bb457020.aspx

R10. Microsoft TechNet: Microsoft Windows Server TechCenter: Key Archival and Management in Windows Server 2003: http://technet2.microsoft.com/windowsserver/en/library/296f87df-06c3-4e27-89ff-5283cb76fb811033.mspx

R11. Group Policy for Healthcare Desktop Management: http://www.microsoft.com/industry/healthcare/technology/hpo/desktop/grouppolicy.aspx

1.0.0.0

R12. Microsoft TechNet: Microsoft Windows Server TechCenter: Step-by-Step Guide to Understanding the Group Policy Feature Set: http://www.microsoft.com/technet/prodtechnol/windowsserver2003/technologies/directory/activedirectory/stepbystep/gpfeat.mspx

R13. Microsoft Download Center: Windows Server 2003 Resource Kit Tools: http://www.microsoft.com/downloads/details.aspx?FamilyID=9d467a69-57ff-4ae7-96ee-b18c4790cffd&DisplayLang=en

R14. Microsoft TechNet: Microsoft Windows Server TechCenter: Best Practices for Implementing a Microsoft Windows Server 2003 Public Key Infrastructure: http://technet2.microsoft.com/windowsserver/en/library/091cda67-79ec-481d-8a96-03e0be7374ed1033.mspx?mfr=true

Table 13: References