Professional Windows Server 1002003 Security A Technical Reference [Electronic resources] نسخه متنی

Special Operations and Issues

In addition to the basic EFS operations, there are additional operations that can extend its usefulness, protect the encrypted files, and make the EFS environment easier to work with. These operations are as follows:

Changing encryption algorithm

Placing Encrypt and Decrypt on the Windows Explorer menu

Backing up encrypted files

Working with offline files

Sharing encrypted files

Protecting password reset

Coloring encrypted file and folder names in Windows Explorer

Using third-party EFS certificates

Changing Encryption Algorithm

The default encryption algorithm for EFS is different depending on the OS. If you require them to be the same, or if you must change them for some other reason, you can do so by following these steps:

Decrypt all files before making this change. This is important, as you will not be able to decrypt the files afterward.

Add the DWORD value AlgorithmID to the registry key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WindowsNT\CurrentVersion\EFS

Set the value for the algorithm you want:

3DES for Windows XP, Windows Server 2003: 0x6603

DESX for all versions of Windows 2000 and above: 0x6604

AES for Windows XP and above: 06610

Close the Registry Editor.

Restart Windows.

Placing Encrypt/Decrypt on the Windows Explorer Menu

If you want, you can put the ability to select file/folder encryption/decryption on the Windows Explorer menu. You must create the DWORD value EncryptionContextMenu at the following location and set it to 1:


HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\Advanced

Backing Up Encrypted Files

The account used to back up or restore the encrypted files does not require special access and should not be given any. If the user has the right to back up a file, then he can back up the file if it is encrypted. Normal backup using NTBACKUP will back up encrypted files. When the files are restored to an NTFS partition, they are still encrypted and can only be decrypted by someone who has the private key associated with one of the public keys used to encrypt the FEK. If you attempt to restore a backed up encrypted file to a FAT volume, you will receive an error. Again, do not provide the user restoring the files any special access. Do not share the encrypted file with him. If you do, he will be able to decrypt the files.

Working with Offline Files

Offline files is a Windows 2000 and above IntelliMirror management technology that allows users to store a local copy of files they access on a network share. When the client computer is disconnected from the network, the files are still available for the user to work with. In Windows 2000, these offline files cannot be encrypted. Windows Server 2003 introduces the ability to encrypt the offline files on Windows XP Professional and Windows Server 2003 systems. This feature is only available if the server-side files are accessed through a standard Windows share, the server message block (SMB) share. The Web Distributed and Versioning WebDAV protocol, which presents a different way of storing EFS encrypted files on a server, cannot be used. For more information on server-side storage of EFS-encrypted files, see the section "Remote Storage" later in this chapter.

Because all offline files are stored in a common local database on the client machine, when offline files are encrypted, the entire database is encrypted using a local computer EFS certificate. Individual files or folders cannot be selected or deselected for encryption.

To encrypt offline files:

Open Windows Explorer.

Select the Tools menu, Folder Options, and select the Offline Files tab, as shown in Figure 6-18.

Figure 6-18. Use the Offline Files tab to configure encryption for offline files.

Select Enable Offline Files and Encrypt offline files to secure data.

Click OK.

Sharing Encrypted Files

Windows XP introduced the ability to share encrypted files. Once a file is encrypted, the encryptor of a file can provide access for other users by adding their EFS certificate to the file properties of the file. This is an interesting feature because it both adds security risk and provides some additional mitigation for file recovery issues. When you provide another user the ability to encrypt and decrypt files, he also has the ability to give other users this right. Thus, a sensitive file can quickly become exposed to many people. Each new encryptor can also add others to the list and can remove them. It is possible that one of these individuals may remove the original owner of the file's certificate and thus his ability to work with the file!

For each file that requires sharing, the process must be repeated. Each added user means that another new encryption key (the FEK) is created and encrypted by the new user's public key and stored with the file.

The estimated limit to the number of users who can be provided access to the same encrypted file via adding their certificate is 800. This is not due to some hard-coded stop but rather because there is only 256K of room in the file header for EFS metadata.

There is currently no way to centrally manage who can encrypt or decrypt a specific encrypted file or to provide a printed list of who has the ability on what files. You can, of course, list the approved users by displaying file properties, and the Resource Kit utility efsinfo can be used to enumerate the certificates that have been used to encrypt a file.

Only someone with the ability to encrypt and decrypt a file can share this ability with others. To share the file follow these steps:

Right-click on the file in Windows Explorer and select Properties.

Click the Advanced button.

Click the Details button.

Click the Add button.

When PKI is integrated with Active Directory, the EFS certificates of all users are stored in the Active Directory and can be added by clicking the Find User button and using the object picker to select the usernames to add to the file. If a user does not have a certificate, the username will not be added to the Select User property page. (In a standalone environment, the user certificate may have to be added to the certificate stores of the computer before this option can be used.)

When users have been added to the Select User page, as shown in Figure 6-19, select a user certificate and click OK to give users the right to access the file. On a standalone system, each certificate must be manually added to the user's certificates store. If the certificate is part of a trusted chain (signed by a CA), the certificate itself is added to your "Other People" certificate store. If the certificate is self-signed, it is stored in the "Trusted People" certificate store. If the user has a local private key on the computer, his certificate is added to the "Trusted People Store" in addition to the "Other People" store.

Figure 6-19. The available EFS certificates in the domain are displayed.

The EFS private key is used to decrypt the FEK, and a copy of the FEK is made. The current user's public key encrypts the FEK and stores it in the file properties. The new user's public key (the public key on the certificate selected) is used to encrypt the copy of the FEK, and then it is added to the file properties. The certificate information is added to the properties, as shown in Figure 6-20.

Figure 6-20. A list of certificates that have encrypted the FEK is displayed.

Click OK twice to close the file properties.

If the computer is not joined to a domain, you can still share encrypted files. You simply must be able to provide a copy of the user's certificate when sharing the file. To do so, ask the user to export a copy of their certificate (without the private key) to a file and provide you with the file. During the sharing process, you can browse to the location of the file and import it.

Password Reset

To prevent a rogue administrator from logging on to a standalone computer, changing the user password, and then logging on as the user to view his encrypted files, Windows XP and Windows Server 2003 disassociate the user's certificate and keys from the user account if the password is reset by the local administrator. (If the user uses the change password utility, this will not happen.) If the administrator resets the user's password and logs on as the user, she will not be able to decrypt the user's files. However, neither will the user. To return this ability to the legitimate user, the user can use her password reset disk made before the incident to return her password to the original. Then she can decrypt the files.

Because users do forget their passwords, and the passwords thus need to be administratively reset, make sure users of standalone systems make themselves password reset disks and store them in a safe place. The password reset function cannot distinguish between a rogue administrator's play for power and a necessary password reset due to the user forgetting his password. It does, however, warn both types of administrators what will occur if the password is reset with the message shown in Figure 6-21.

Figure 6-21. An attempt to reset the password results in a warning that the user may not be able to access files.

Coloring Encrypted Files and Folder Names in Windows Explorer

Encrypted files and folders are shown in green in Windows Server 2003 automatically. To turn on this feature for Windows XP clients or to turn it off for Windows Server 2003, follow these steps:

Select the Folder Options, View tab in Windows Explorer.

Check or uncheck the box for Show encrypted or compressed NTFS files in color, as shown in Figure 6-22.

Figure 6-22. You can modify the color of encrypted folders and files in Windows Explorer.

To apply the setting to all folders on the computer, select the Apply to All Folders button and choose Yes when prompted.

Use of Third-Party EFS Certificates

Third-party EFS certificates can be used with EFS. They must, however, meet stringent requirements. This list is an example of the items that must be checked before considering the use of third-party certificates. You should also test certificates and third-party certificate services such as enrollment to ensure compatibility.

Two Key Usage extensions are required: Key Encipherment and Data Encipherment.

The Enhanced Key Usage extension must contain the EFS identifier number 1.3.6.1.4.1.311.10.3.4.

Certificates that do not contain a Certificate Revocation List Distribution Point (CDP) will not be validated (so they cannot be used).

File Recovery Certificates must include the File Recovery identifier 1.3.6.1.4.1.311.10.3.4.1.

To read more on the use of third-party certificates, see the Knowledge Base Article "Third Party Certification Authority Support for Encrypting File System" at http://support.microsoft.com/default.aspx?scid=kb%3Ben-us%3B273856.

EFS and System Restore

On a Windows XP Professional system, the System Restore function allows the return of system state to some previously recorded status. By default, System Restore monitors all disks but does not monitor redirected folders or data excluded from monitoring. System Restore has little effect on EFS-encrypted files, with two exceptions. First, if a system is restored to a point before a file was encrypted, then the file will not be encrypted after the restore. Also, if multiple users are enabled on the monitored file, after performing System Restore, you may find that only the original encryptor of the file can decrypt it.

Discovering and Viewing the Certificate

The certificates used for encrypting the FEK, including the recovery agent certificate, can be viewed from the File Properties, Advanced, Details page. To see them, click the View certificate button. This can be a useful troubleshooting technique. When multiple recovery agents are or have been used, it may be difficult to recover a file until the recovery agent certificate can be viewed to determine which recovery agent's certificate was used. Once this is known, it can be used to decrypt the file. This information is available by viewing the certificate or by using the efsinfo.exe utility.