In most situations, you want the capability to recover encrypted data when a user leaves the organization or loses her encryption certificate and keys. EFS ensures recoverability of encrypted files by administrators by requiring that at least one data-recovery key be present on the system. These recovery keys enable a recovery agent who has the necessary public key to decrypt a file's FEK, thereby decrypting the file. The recovery key doesn't enable the recovery agent to retrieve any other information, such as the user's private key, ensuring continued security for an employed user while still enabling the agent to recover data.
On Windows 2000/Windows Server 2003 domains, the Domain Administrators account is configured automatically as the recovery agent in a domain. The local Administrator account is defined as the recovery agent on standalone computers and those participating in a workgroup. The recovery process is identical to the decryption process shown in Figure 27-28, except that the EFS uses the recovery agent's private key instead of the user's private key to decrypt the data.
You can define an encryption recovery policy at the domain level and enforce that policy on all computers in the domain through domain/group policies. Administrators can delegate recovery policies to specific security-administration accounts through the delegation features inherent in Active Directory (AD). This capability enables administrators to delegate authority for encrypted data recovery to one or more security administrators. EFS also enables multiple recovery-key configurations, which provides redundancy and greater flexibility in configuring and implementing the encryption policy.
If you have no domain (such as in a standalone, workgroup, or home-office environment), EFS automatically creates recovery keys and saves them as machine keys, enabling the local Administrator account to perform encryption recovery.
The EFS recovery policy is part of the domain security policy for computers participating in a domain and part of the local security policy for computers in a workgroup or for standalone computers. In each case, the security policy is applied through Security Settings\Public Key Policies\Encrypted Data Recovery Agents. You can use the Local Security Policy or Domain Security Policy MMC consoles, as appropriate, to add and configure recovery agents and their certificates. This includes importing and exporting certificates. By implementing the recovery policy in the system security policy, Windows Server 2003 provides centralized replication, enforcement, and caching of the policy. Because the user's security credentials are cached, the user can continue to work with encrypted files even if his system is not currently connected to the network.
Note See the section "Configuring and using a recovery policy," later in this chapter, for informa tion on configuring the security policy and performing recovery operations.
Windows Server 2003 no longer requires that the recovery be in effect on the domain to decrypt files. Although the policy is configured for standalone computers as part of local policy, recovery on a Windows Server 2003 domain is configured as needed at the site, domain, and OU level; it can also be configured at the individual computer level. The policy applies to all Windows 2000, XP, and Windows Server 2003 computers that are within a defined scope of the policy. The recovery certificates are issued by a Certificate Authority (CA) using the Certificates console.
Because EFS is integrated with NTFS 5.0 and installed automatically, no installation or configuration is required for a user to begin encrypting folders and files. As long as a recovery agent is defined, the user can encrypt files. If no recovery agent is defined, EFS is disabled. Because Windows Server 2003 by default creates the recovery certificate and installs it in the domain or local security policy, as appropriate to the system, users can begin using encryption with Windows Server 2003 right out of the box.
Although you can encrypt individual files, applying encryption on a folder-by-folder basis is best (or in cases requiring extreme security, on a volume-by-volume basis). The main reason for not applying encryption to individual files is that many programs, such as Microsoft Word, create temporary files as you work, and EFS does not automatically encrypt these temporary files. To do so, the application would need to be EFS-aware and notify the operating system that the temporary file needs to be encrypted. By encrypting a folder, you effectively encrypt the contents of the folder. As you create new files in the folder (including automatically created temporary files), they are encrypted and enjoy the same security as the other files in the folder.
Tip When you encrypt a folder, you aren't actually encrypting the NTFS field that defines the folder. Instead, you are setting the folder's encryption attribute. EFS uses this attribute to / determine how to handle file creation and modification operations in the folder.
Was this article helpful?