Inside Windows Server 1002003 [Electronic resources] نسخه متنی

Special EFS Guidelines

This section contains information about EFS limitations and special operational considerations for deploying EFS effectively.

Moving and Copying Encrypted Files

Files are like children growing up in rural communities. They rarely stay in the folder where they were created. When users move or copy encrypted files, they may get unexpected results, especially if they are unaware that the files were encrypted in the first place.

A user who encrypts a file (or whose name is on the list of additional users who can access an encrypted file) can copy the file contents anywhere. This is because the data stream is decrypted as it leaves the drive.

If a user attempts to copy or move an encrypted file to a location that does not support EFS, the Explorer shell will warn of the possibility of exposing the file's contents. The user can choose to ignore the warning and save the file anyway. If the user is working at the command line, the COPY and XCOPY commands will block operations involving insecure target volumes. There are new switches to override the block. The syntax is copy /d and xcopy /g.

If a user copies an unencrypted file into an encrypted folder, the new file is encrypted. If a user

moves an unencrypted file into an encrypted folder, an action that ordinarily does not touch the file's data, the system takes over and encrypts the file anyway on the assumption that this is what the user would have wanted. This is not true if you work from the command line. The MOVE command leaves a file in clear text even if it is moved to an encrypted folder.

If a user copies an encrypted file to a server that has been trusted for delegation, the file is first decrypted at the client, then transmitted in clear text across the network, then encrypted again at the server using the public key in the user profile at the server. If you want files to traverse the wire in encrypted form, use WebDAV or implement IPSec (described in the next chapter).

A user who cannot access the data of an encrypted file can still

move the file to another location on the same volume as long as he has sufficient NTFS permissions on the file. This is because moving the encrypted file does not touch the file's data, only the back-link to the parent directory. This ability to access the non-data portions of the file includes the ability to delete the file either by moving it to the Recycle Bin or removing it from the volume completely. Encryption is not a replacement for proper NTFS permissions.

If a user attaches an encrypted file to an email message, the file is first decrypted and then copied into the MIME attachment. This exposes the file unless the user has enabled S/MIME.

Files That Cannot Be Encrypted

Just about any file can be encrypted. This includes data files, executables and DLLs, temp files, and configuration files. Here are a few exceptions:

• Compressed files.
  Encrypted files cannot be compressed, and compressed files cannot be encrypted. The encryption algorithm scrambles a file to such an extent that there are no consecutive sets of characters to make compression worthwhile.




• Mount points and reparse points.
  Symbolic links to other file systems or folders cannot be encrypted. If you want to encrypt the files and folders behind a mount point, you can change directory into the mount point and then select the files from there. The mount point must contain a file system running NTFS 3.0 or later.




• System files.
  EFS will refuse to encrypt a file that has its system attribute set. The operating system may need to read a system file at boot time before EFS has had a chance to initialize. You can use this feature to your advantage by setting the system attribute on files you don't want users to encrypt.

In addition, if you have enabled the Content Indexing Service on a machine, any file that is encrypted is automatically removed from the index. This prevents giving away the contents of the file within the index catalog.

Temp Files, Paging Files, Hibernation Files, and Spool Files

If an application saves temp files, be sure to put the temp files in the same folder as the encrypted fileseither that or encrypt the folder where the temp files are saved.

When encrypting temp folders, don't forget to include the \Local Settings\Temp folder in the user's profile. The simplest way to find this folder is to open a command prompt and run cd /d %temp%.

The contents of the paging file and hibernation file are not encrypted. You can enable policies to remove the paging file at logoff and disable hibernation. Erasing the paging file does not prevent someone from examining the contents with a hex editor, though it's a daunting task to search through 4KB pages looking for worthwhile information. Using XP, you can disable the paging file entirely. This eliminates the vulnerability, but you must ensure that you have sufficient memory in the machine to handle the applications loaded by the user.

If your laptop users threaten to mutiny if you disable hibernation, make a deal with them that you will leave hibernation enabled if they always close their data files before hibernating their machines. There's a big difference between "cross my heart" promises and full compliance, though, so let your auditing group know to be on the lookout for this problem.

If you want to protect the contents of files as they print, be sure to encrypt the spool files located in \Windows\System32\Spool\Printers.

Offline Files

If you enable offline files for laptop users, you should consider encrypting the offline folders cache. This encrypts the entire contents of the cache and does so without changing the encryption status of the files on the server.

The option to encrypt the files is set in the Offline Files tab of the Folder Options window. Figure 17.13 shows an example.

This feature is not available in Windows 2000. I recommend upgrading your laptops to XP as quickly as possible if you want to use Microsoft's file encryption services.

Virus Checking

Most virus scanners run in either the Local System security context or the new Local Service context. In that configuration, a scanner cannot open a user's encrypted files and therefore may miss a virus.

Unfortunately, there is not a clean workaround to this problem. Any solution that would permit a virus scanner to see a user's files could permit a bad guy to see the files, as well. The best solution is to have a real-time virus scanner running at the desktops and servers that can analyze files for virus signatures as they open. For some viruses, this might be too little, too late. Look for progress on this front from vendors of virus software.

Encryption and System Restore

Windows XP sports a new feature called System Restore. This feature takes a snapshot of a system every so often and saves the settings to a cache file. This includes any software that's loaded along with drivers and system configuration settings. If a user installs an application that causes the system to become unstable, the user can return the system to the settings in a stored snapshot.

When System Restore rolls back a system to a previous configuration, you take the chance of exposing encrypted files. It has been my experience that System Restore does a good job of maintaining encryption status, but Microsoft warns of this possibility so it's worth taking seriously.

The System Restore service can be configured to exclude selected folders from the list of monitored folders and files. You can configure the service to avoid encrypted folders. In production, you may not be able to guarantee that the only encrypted files on a machine are in the designated folders. If you perform a system restore for a user, you may want to log on as the user and gather all encrypted files into a central location and then use Ntbackup to make a backup file of the encrypted files prior to running the system restore. Use cipher /u /n to scan for encrypted files