The first question to ask yourself when looking at deploying EFS is whether or not to integrate it with a Microsoft Public Key Infrastructure (PKI). This is a fundamental question that should be determined before moving forward. EFS does not require a PKI, but it does provide for EFS key recovery and makes it much easier to share encrypted files with other users because users' EFS public keys can be automatically published to Active Directory (AD). Assuming that you are going to build a PKI or you already have one follow the steps here to configure your PKI for EFS.
Whether or not you decide to use a PKI, it is a good idea to create at least one new Data Recovery Agent (DRA) key pair. By default, your Default Domain Policy will use the Administrator account from the first Domain Controller created on your domain as the DRA. This has several disadvantages. First, this DRA will expire after a few years. Second, if you ever decommission the original Domain Controller the DRA private key will be lost (assuming you don't export it first). Follow these steps to create a new DRA with a 100 year expiration:
- Create a new DRA domain account (i.e. dra1)
- Log onto a workstation as dra1
- Open a command prompt and run "cipher /r:dra1"
- Enter the domain password for dra1
- Save the keys to a secure location
Next, edit your Default Domain Policy and add the new DRA:
choose the .cer file for the DRA created above.
It's a good idea to leave the old DRA in place as well just in case users have already begun using EFS. The new DRA will not work on files that have already been encrypted until those files have been opened and saved by the user. If you have a large AD build out with sub-administrators you can also create sub-DRA's and attach them to Organizational Units (OU) that the sub-administrators manage. This will allow them to recover encrypted files on computers in their OU without needing access the domain wide DRA.
Once you have your recovery options setup, turning on encryption for files/folders is simple:
If the user's EFS key is lost or damaged you can use the DRA, or if you setup a PKI with key recovery then the key pair can be imported back into the user's profile. The DRA option is more cumbersome because you will have to logon to the user's workstation with the DRA, import the DRA key pair, and manually decrypt all of the encrypted files.
So now that you've got everything setup, what should you actually encrypt? Here is a list of the easy ones:
- %userprofile%My Documents
- Mail client (i.e. %appdata%MicrosoftOutlook or %appdata%Thunderbird)
This will take care of the most common locations where users save files. Note the mail client bullet: If you are using something other than Microsoft Outlook or Thunderbird then locate the mail storage folder for that client and turn on encryption. If your users are locked down (non-admins) then this will give you pretty good coverage. If your users have administrator access to their boxes then it is much more difficult to guarantee protection of sensitive information. These users can create new folders wherever they want so you will need to provide some training on the importance of placing files in folders designated for encryption as well as how to turn on encryption.
Using EFS with Offline Files is kind of a beast in XP. Unfortunately, offline files are stored in a shared database used by all users. No one user can encrypt this database with a personal EFS key pair. This means that when Offline Files are designed for encryption (to secure data) the SYSTEM account generates its own EFS key pair and that is used to encrypt the Offline Files database. It's pretty easy to reset an administrator password if you have physical access to a Windows machine, and once you have administrator access it's even easier to run something as the SYSTEM account. To get around this problem (by protecting your administrator account) you can encrypt the security accounts manager (SAM) database by requiring a password when booting up:
Vista makes this little problem go away by encrypting Offline Files with the user's EFS key pair.
There are also a few locations where you should probably not turn on encryption. Be wary of encrypting anything in %ProgramFiles% or %temp%. Remember that files are encrypted using the creator's EFS key. By default, users will not be able to run programs installed by another user. Also, sometimes programs will use the %temp% folder during installation. Files that are uncompressed here and copied to other folders may retain the encryption settings from the user who performed the install. This will deny access to other users.
Dealing With High Security Environments
For those among us who are a little more paranoid or operate with extremely sensitive data there are a few other items that need to be addressed. During normal operation Windows saves chunks of raw memory to a page file that resides on the hard drive. In Windows 2000/XP, the page file cannot be protected by encryption and may contain data that originally came from an encrypted location on your hard drive. The only workaround here is to delete the page file upon shutdown:
Thankfully Windows Vista allows encryption of the page file:
Of course, both of these setting are available through group policy as well.
The other two items that must be addressed in a high security environment are hibernation and slack space. When your computer hibernates, the current memory contents are saved to your hard disk. There is no way to encrypt this data so for complete security this feature must be disabled. Slack space is space that is marked as available on your hard disk, but may contain old data because hard drives usually don't immediately overwrite information when it is deleted. You can clean this up this by running cipher -W. This only needs to be run once because after your data is marked for encryption the "leftovers" are still encrypted.