SideBar    What’s the Downside to EFS?, Creating a Recovery Agent

You can export certificates and private keys by using command-line tools (e.g., certmgr.exe) or, more easily, by starting Microsoft Internet Explorer (IE) 5.0 or later, selecting Tools, Internet Options, clicking the Content tab, then clicking Certificates. Select the certificate you want to export, then click Export to start the Certificate Export Wizard. Because an EFS certificate has a private key associated with it, the wizard gives you the option of exporting the private key, too. If you choose to export the private key with the EFS certificate, the only supported file format is Personal Information Exchange ­ PKCS #12 (.PFX), as Figure 2 shows. Select the Delete the private key if the export is successful check box. (This option is useful for recovery agent certificates, which I discuss in the next section.) The wizard prompts you for both a filename and a password to protect the exported certificate and private key. Click Finish.

EFS and Recovery Agents
One useful EFS feature is recovery agents. Recovery agents are users whose user accounts are authorized to decrypt a file when the user who encrypted that file can't (e.g., when the user has lost his or her private key). This feature is especially useful when you find an encrypted file belonging to a former employee whose account is no longer available or when a user's profile has been deleted or hopelessly corrupted and you can't restore it. When EFS encrypts a file, it encrypts the FEK used with the public key from a special recovery agent certificate; with the file EFS stores the symmetric key and recovery agent certificate alongside the FEK encrypted with the user's certificate in the EFS metadata. By default, in workgroup environments, the recovery agent account is the local Administrators account. In a domain environment, the default recovery agent account is the Domain Admins account.

Recovery agents can decrypt a file in three ways. They can

  • clear the Encrypt contents to secure data check box in the Advanced Attributes dialog box
  • copy the file
  • open the file in the application the user used to create it and save the file elsewhere

(When you copy or save a file to a new location, the new file inherits the compression and encryption attributes of the folder to which it's written.) For instructions about how to create a recovery agent, see the Web exclusive sidebar "Creating a Recovery Agent," which you can access at http://www.secadministrator.com, InstantDoc ID 24103.

EFS Recovery Agent Certificates
After you've created a recovery agent user account, you need to deploy the EFS Recovery Agent certificate to your systems. To do so, you use a Group Policy. For import into a Group Policy, you need to export the EFS Recovery Agent certificate to a file without its associated private key. Follow the export procedure I provided earlier, but this time, select the No, do not export the private key option in the Export Private Key dialog box and the DER encoded binary X.509 (.CER) option in the Certificate Export Wizard Export File Format dialog box.

The Group Policy setting for EFS recovery agent accounts can be domainwide or restricted to an organizational unit (OU). You can even have separate recovery agent accounts for each OU, which is useful if you group systems by the sensitivity of data stored on them and you need different recovery agents for each system. To specify recovery agents, follow these steps:

  1. Open the Microsoft Management Console (MMC) Group Policy snap-in, then navigate to the Encrypted Data Recovery container.
  2. Right-click Encrypted Data Recovery in the left pane, then select New, Encrypted Recovery Agent, as Figure 3 shows, to launch the Add Recovery Agent Wizard. Click Next.
  3. On the Select Recovery Agents page, you can specify recovery agents. If certificates are published in Active Directory (AD), you can search for them by clicking Browse Directory; otherwise, click Browse Folders and select the Distinguished Encoding Rules (DER)­encoded file in which the EFS Recovery Agent certificate resides. Click Next.
  4. Click Finish to add the recovery agent to the Group Policy.

Now, every time a user accesses an encrypted file, EFS will update the list of recovery agent accounts that can decrypt the file. This failsafe lets you change recovery agents and their certificates on an as-needed basis. Be sure to keep the EFS Recovery Agent certificates and private keys for old recovery agents in case an infrequently accessed file has old recovery agent information associated with it and a recovery agent is required to decrypt it.

Securing Recovery Agents
EFS security depends on the security of the EFS Recovery Agent certificates and their associated private keys. You should never use recovery agent accounts for anything other than recovering files. Because EFS Recovery Agent certificates and private keys are stored in user profiles, consider using local rather than roaming profiles for recovery agent accounts. Using local profiles means recovery agents can decrypt files only on the computer from which the EFS Recovery Agent certificate and private key were requested or on a computer to which an exported certificate and key were imported. You should dedicate systems for recovery agent use and physically secure them. When you need to open an encrypted file, move it to a recovery agent system. I recommend using the NT Backup utility, which can read an encrypted file as raw data and store it to tape or another file for transport.

In environments with a strict need for security, export EFS Recovery Agent certificates and private keys to a floppy disk or smart card, then delete them from the computer on which they were requested. Keep the medium onto which you exported the certificates and private keys secure until you need to restore them to decrypt files. When you no longer need the certificates and private keys, delete them again.

Leveraging EFS with your PKI provides many administrative benefits. By using roaming profiles and assigning recovery agents, you can ensure that you'll always be able to access and recover encrypted files on your systems.

End of Article

Prev. page     1 [2]     next page -->



You must log on before posting a comment.

If you don't have a username & password, please register now.

Reader Comments

<br><br> It isn’t often one catches his security hero in a little typo.<br>

The article states:<br>

"When you copy or save a file to a new location, the new file inherits the compression and encryption attributes of the folder to which it's written."<br>

When the encryption attribute is set, it is always maintained when a file is copied within an NTFS v5 volume or between NTFS v5 volumes (local machine or server) – regardless of the encryption attribute of the destination folder.<br>

Also, because an NTFS v5 file can’t be both compressed and encrypted, when an encrypted file is copied or moved into a compressed folder, the file remains encrypted.<br>

It appears that Microsoft guarantees that the only time an encrypted file will be saved in a non-encrypted state is when the destination volume is not NTFS v5.<br>

However, within an application, when a file is saved to a new location, the new file takes on the encryption state of the target folder regardless of the encryption state of the originally opened file.<br>

Keep up the great work John – when I read you I hear me.<br>

Byron W. Putman

<br><br> Great article on the Recovery Agent – I’d like to point out one additional requirement of a recovery agent account. To successfully recover a file the recovery agent must not only be able to decrypt the file, but also read/write its extended attributes. For that reason I always ensure that the same GPO that drives the recovery agent policy also specifies that the recovery agent account has the right to “take ownership of files and other objects.”<br>

I applaud your article because it doesn’t fall into the trap of 99% of W2K books and other articles. They always imply that a recovery agent account must be a member of the local administrators group. This fallacy is driven by the fact that the right to “take ownership of files and other objects”, by default, is vested in the local administrators group.<br>

Keep up the great work.<br>

Byron W. Putman

 
 

ADS BY GOOGLE