Encrypting File System (EFS) allows you to secure files that are stored locally. In addition to encrypting files, you must develop a plan for recovering data in the event recovery keys are lost. Poor EFS planning can result in permanent loss of data.
After this lesson, you will be able to
Estimated lesson time: 30 minutes
Before planning an EFS deployment, it's important to understand how EFS encrypts data stored on NTFS volumes. Knowing how the EFS process takes place will help you in the following cases:
To the user, the process of encrypting a stored file is as simple as selecting the Encrypt Contents To Secure Data check box for a file or folder, as shown in Figure 6.9.
Figure 6.9 Enabling encryption of a file through the interface
Alternatively, an administrator may have configured it so that all content within a specific folder is encrypted on a laptop computer to ensure the security of confidential data.
The data encryption process takes place any time a user sets the encryption attribute on a file or folder or when the user saves a file that has the encryption attribute enabled. The process (shown in Figure 6.10) takes place as follows:
Figure 6.10 The EFS encryption process
The encrypted document now has two additional header fields, the Data Decryption Field (DDF) and the Data Recovery Field (DRF). The DDF contains an encrypted copy of the File Encryption Key that only the user who encrypted the file can decrypt. The DRF contains an encrypted copy of the File Encryption Key that only the designated EFS recovery agent can decrypt.
EFS encrypted files can't be shared between users because of the way the File Encryption Key is protected. Only the user who encrypted the file will have the private key required to decrypt the File Encryption Key. This prevents the sharing of EFS encrypted files.
It's possible to have more than one EFS recovery agent defined for a domain or Organizational Unit (OU). In this case, multiple DRFs are associated with a file. The File Encryption Key is encrypted once for each EFS recovery agent. Each recovery agent will only be able to decrypt the DRF encrypted with her EFS Recovery public key.
EFS only protects data stored on an NTFS partition. It doesn't provide network transport security. In other words, if you open an EFS-encrypted file on a remote server, the file contents are transmitted to you over the network in clear text. To protect the transmission of the file, you must use IPSec to protect the contents as they are transferred to your computer.
Once a file is encrypted, only the user who encrypted the file or a designated EFS recovery agent can open the file and view its contents. The process of decrypting the file differs based on whether it's done by the user or the EFS recovery agent.
Decryption by the Original User
When the user who encrypted the file attempts to open the file, the following process takes place, as shown in Figure 6.11.
Figure 6.11 EFS decryption by the original user
The decrypted clear text document is then opened with the application associated with the document. To the user it appears that the document "just opened." The user doesn't see any different behavior when opening an encrypted or nonencrypted file.
Decryption by an EFS Recovery Agent
When an EFS recovery agent attempts to open an EFS-encrypted file, the following process takes place, as shown in Figure 6.12.
Figure 6.12 EFS decryption by the EFS recovery agent
A major design issue when you deploy EFS is selecting the account that will be the EFS recovery agent. In other words, you must define the public/private key pair that the EFS process will use to encrypt the File Encryption Key into the DRF of each EFS encrypted file. If you don't define the EFS recovery agent, EFS recovery attempts might fail.
If a Windows 2000–based computer isn't a member of the domain, the default behavior is to configure the initial Administrator account as the EFS recovery agent.
The initial Administrator account might not be named Administrator, depending on what name is provided during setup for the initial account at the member server or workstation.
The EFS recovery certificate is self-issued, which means that it isn't acquired from a certificate authority but is created by the operating system.
If the Windows 2000–based computer is a member of a domain, the Default Domain Policy is applied to that computer. The Default Domain Policy configures the Administrator account of the domain as the EFS recovery agent. When you log on as Administrator, you may or may not have the necessary private key to perform the EFS recovery. The public key for EFS encryption is the public key associated with the Administrator account of the first domain controller (DC) installed into the domain. This DC's former Security Account Management (SAM) database is used to initially populate the Active Directory directory service domain. During this process, the Administrator's EFS recovery certificate is reconfigured as the EFS recovery agent in the Default Domain Policy.
The EFS recovery agent is defined in the following location of the Default Domain Policy: Computer Configuration\Windows Settings\Security Settings \Public Key Policies\Encrypted Data Recovery Agents.
Initially, the only computer that has the associated private key is the initial DC in the domain. Unless you export the private key to a safe location or configure the Administrator account to have a roaming profile and then populate the roaming profile with the contents of the Administrator's profile from the initial DC, you could lose the private key. Losing the private key will prevent you from recovering EFS encrypted files.
The private key is stored in the local user profile in secured storage. Only when you configure a roaming profile is information stored in the user profile shared among multiple computers.
If you configure the roaming profile for the Administrator account and populate the information for the account from a DC other than a member server or the initial DC, you will lose the initial EFS recovery agent private key permanently, which will prevent you from decrypting any files encrypted with the EFS recovery agent's public key.
A more effective method of configuring the EFS recovery agent is to define a new account as the EFS recovery agent. The newly created EFS Recovery Agent account requires an EFS Recovery certificate but doesn't have to be a member of the Administrators group in the domain. This certificate template is available from a Windows 2000 Enterprise Certification Authority (CA).
For more information on deploying Certificate Services in Windows 2000, see Chapter 10, "Planning a Public Key Infrastructure."
You can import the EFS recovery certificate into the Default Domain Policy as the domain's encrypted data recovery agent. The imported public key is used to encrypt the File Encryption Key stored in the DRF. In fact, you can import multiple EFS recovery certificates into Group Policy so that you have multiple EFS recovery agents.
You may also choose to prevent EFS encryption on your network by deleting all current EFS recovery agent certificates in the Encrypted Data Recovery Agent policy. Without defined encrypted data recovery agents, it's impossible to use EFS encryption.
When the Encrypted Data Recovery Agent policy exists, but there are no recovery agents included in the policy, this is known as an empty policy. The policy exists and is applied, but no values are assigned from it. This differs from the case where no Encrypted Data Recovery Agent policy exists. If there's no policy applied within the site, domain, or OU, then the local policy defined at each computer would take precedence. The creation of an empty policy ensures that local policy doesn't take precedence.
Use the decision matrix shown in Table 6.5 when planning EFS recovery agents for a domain.
Table 6.5 Decision Factors for EFS Recovery Agents
|To||Do the Following|
|Ensure the recoverability of all EFS-encrypted files in a domain||Define an encrypted data recovery agent in the default domain policy.|
|Prevent EFS encryption from being used||Delete all existing recovery agent certificates in the Encrypted Data Recovery Agent policy.|
|Prevent specific computers from using EFS encryption||Place all computers that can't use EFS encryption in a separate OU or OU structure. At the OU or the parent OU, define a Group Policy object that has an empty policy. This is accomplished by initializing an empty policy from encrypted data recovery agents in the Group Policy object.|
|Restrict EFS encryption to specific users||You can't do this unless all users have only one computer where they log on to the network. EFS recovery agents are a property of the computer, not the user.|
Wide World Importers wants to prevent the use of EFS encryption. You can do this by deleting the default EFS recovery agent from the Default Domain Policy. By removing all entries from the Default Domain Policy, but not deleting the policy, Wide World Importers can prevent users from using EFS to encrypt files. If there's no defined EFS recovery agent, EFS encryption is disabled on the domain member computers.
When you develop your security plan for encrypted files, you must set up a process for recovering encrypted files. The process must include the use of the EFS recovery private keys and defining where EFS recovery operations can take place on the network.
To decrypt an encrypted file, you must be the user who encrypted the file or be a designated recovery agent. In other words, you must hold the private key for the EFS encryption public key of the user who encrypted the File Encryption Key or you must hold the private key for the EFS recovery public key used to encrypt the File Encryption Key.
The best way to deploy an EFS recovery solution is to complete the following steps:
Changing the permissions for a certificate template requires that the Services node is exposed in the Active Directory Sites And Services console. This is done by selecting Show Services Node from the View menu. The certificate templates can be found in the Active Directory Sites And Services\Public Key Services \Certificate Templates folder.
When you perform an EFS recovery, determine the private key that can perform the EFS recovery and then import the private key into the certificate store of any user account. The user can decrypt the file because the user account now holds the corresponding private key to the public key used to encrypt the File Encryption Key.
Determining the Required Private Keys
Use the Efsinfo utility from the Microsoft Windows 2000 Server Resource Kit to determine which private key is required to decrypt an EFS encrypted file. Efsinfo has the following parameters:
EFSINFO [/U] [/R] [/C] [/I] [/Y] [/S:dir] [pathname [...]]
- /U displays user information (Default option).
- /R displays Recovery Agent information.
- /C displays certificate thumbprint information.
Don't confuse the certificate thumbprint with the certificate serial number. You can view the certificate thumbprint by viewing the properties of the certificate and inspecting the details page. You access the properties of a certificate by double-clicking an issued certificate in the Certificates MMC.
- /I continues performing the specified operation even after errors have occurred. By default, Efsinfo stops when an error is encountered.
- /Y displays your current EFS certificate thumbprint on the local PC. The files you specified might not be on this PC.
- /S performs the specified operation on directories in the given directory and all subdirectories.
For example, to recover the file c:\license.txt, you could type EFSINFO LICENSE.TXT /R /U /C. The output from the command shows the thumbprint of the user private key and the recovery private key that you can use to decrypt the License.txt file.
The Cipher.exe command allows the launching of bulk encryption and decryption processes.
Use the decision matrix shown in Table 6.6 when planning recovery of encrypted files.
Table 6.6 Planning EFS Recovery
|To||Do the Following|
|Restrict the ability to recover encrypted files||Export the private key of the defined recovery agent to a PKCS#12 file. Import the file only when it's necessary to recover an encrypted file.|
|Restrict recovery to a specific workstation||Create a new account to perform the recovery and restrict the account to the desired workstation. Import the PKCS#12 file to restore the private key for recovery.|
|Allow more than one private key to perform EFS recovery||Designate more than one certificate in the encrypted data recovery agent policy.|
|Determine which users can decrypt a file||Use Efsinfo /U /C to determine which private key is required to decrypt the DDF and decrypt the File Encryption Key.|
|Determine which recovery agents can decrypt a file||Use Efsinfo /R /C to determine which private key is required to decrypt the DRF and decrypt the File Encryption Key.|
The files that were encrypted before the computers were rebuilt may still be recoverable. A network administrator should run the Efsinfo utility from the Microsoft Windows 2000 Server Resource Kit to determine the thumbprint of the private key that can decrypt the DRF of the encrypted files.
Because Wide World Importers hasn't configured the EFS recovery agent, chances are the default EFS recovery agent was previously configured. In this case, the holder of the EFS recovery agent private key is probably the Administrator account from the first DC installed in the wideworldimporters.tld domain. As long as a roaming profile hasn't been implemented for the Administrator account, the private key for EFS recovery of this account might be able to decrypt the data recovery field and decrypt the encrypted data files.
While the process of performing EFS encryption is relatively easy, when you draw up your design you must be careful to ensure the recoverability of EFS encrypted files. Your security design must contain provisions for the designation of an EFS recovery agent and outline the preferred process for performing EFS recovery.