Tip

Prevent data loss with Encrypting File System (EFS)

Having written thousands of articles over the last 13 years or so, I tend to get a lot of mail from readers asking a lot of diverse questions. The one question I get asked more than any other is how to recover encrypted files. Typically what happens is that either Windows crashes or someone decides to reformat the hard drive and reinstall Windows, forgetting that the machine contains another volume that is full of encrypted files.

Unfortunately, there isn't an easy answer for regaining access to encrypted files after the operating system is destroyed. While there are a few utilities available on the Internet that claim to be able to perform a brute force crack on encrypted files, I have never actually used any of these utilities and am therefore hesitant to recommend one.

    Requires Free Membership to View

Encrypting File System (EFS)
Troubleshooting generic error messages related to EFS

Problems accessing encrypted files on remote servers

The real key to trying to salvage your data in a situation like this is to plan ahead. Having full system state backups is nice, but in corporate environments it is usually impractical to backup each workstation. Therefore, the best way to protect yourself against future data loss resulting from key loss is to have a good key management plan in place.

I've picked up a few tricks over the years I'd like to share with you that will help prevent data loss. We'll start with how to recover Encrypting File System (EFS) keys.

Designate multiple recovery agents

A common key-related problem that results in data loss involves losing EFS keys. For example, suppose that an employee encrypted some files using EFS. Let's say this user later becomes disgruntled and reformats the hard disk containing Windows. In a situation like this, you could easily reinstall Windows, but the files would remain encrypted because the encryption keys were stored as a part of the original Windows installation. Although the encrypted files have not been deleted, data loss still occurs because it is no longer possible to decrypt the files.

The first thing you need to understand about EFS is that encrypted files do not necessarily have to be encrypted in such a way that they are only accessible to one user. EFS uses symmetrically encrypted data blocks, and the symmetric key is encrypted by one or more public/private key pairs. There is a separate public/private key pair for each user who has access to decrypt the files.

Designate multiple recover alerts

I have seen a lot of publications that indicate that the local administrator account is automatically designated to act as a recovery agent in Windows XP. However, this is only true in certain situations. If the system is not a part of a domain, then it will only have a built-in recovery agent if it was originally upgraded from Windows 2000 Professional.

In Windows 2000 Professional, the local administrator account always acts as a designated recovery agent. When Microsoft created Windows XP, it decided to remove this capability in order to prevent the administrator account from being used as a mechanism for cracking encrypted files. The rules change, though, if the workstation is a member of a Windows 2000 or a Windows Server 2003 domain. In such cases, the built-in domain administrator account (not just someone with domain admin rights) is designated as the recovery agent.

If a Windows XP machine is acting as a part of a workgroup and does not have a designated recovery agent, then you can and should take the time to designate a recovery agent on your own. This is as simple as designating additional users who have permission to decrypt the encrypted files.

Begin the process by encrypting the files in the usual manner. After doing so, right click on an encrypted folder and choose the Properties command from the resulting shortcut menu. When you do, Windows will display the folder's properties sheet. Now, click the Advanced button found on the properties sheet's General tab, and then click the Details button. You should now be presented with the opportunity to add users to the list of users who are allowed to decrypt the folder's contents.

When it comes to adding users, you can add any user who has a certificate cached in the local machine's "Other People" certificate store. You also have the option of adding Active Directory users, but any domain user that you add must have a valid EFS certificate in Active Directory.

Once you have given other users access to encrypted folders, the recovery process is usually simple. If a user who owns the encrypted files loses his certificate for whatever reason, other users who have been given access to the files can log in and decrypt them.

Although this sounds simple, it isn't always practical. For instance, if a hard drive failure destroys the Windows operating system, then the certificate cache may also be destroyed. In such a situation, file recovery becomes impossible without the aid of third-party tools unless you have external copies of the certificates. So, keeping an external copy of the recovery certificate Is probably a good idea. Reinstall Windows if necessary, and then import the certificate as a way of gaining access to the encrypted files.

How to create an external copy of a certificate

The process of creating an external copy of the certificate varies depending on whether the machine is acting as part of a domain. To export a certificate from a workstation that is acting as a member of a workgroup, follow these steps:

  1. Log on to the workstation using the recovery agent's account.
  2. Enter the MMC command at the Run prompt.
  3. Choose the Add/Remove Snap-in option from the console's File menu.
  4. Choose the Certificates option from the list of available snap-ins and click Add.
  5. When prompted, choose the My User Account option, and then click Finish.
  6. Click Close, followed by OK.
  7. Navigate through the console tree to Certificates | Current User | Personal | Certificates.
  8. Look for a certificate that has the Intended Purposes column set to File Recovery.
  9. Right click on the certificate and choose the All Tasks | Export commands from the resulting shortcut menus.
  10. When the Certificate Export Wizard starts, click Next.
  11. Choose the Yes, Export the Private Key option and click Next.
  12. Choose the Personal Information Exchange -- PKCS #12 (.PFX) option and choose the Enable Strong Protection option.
  13. Make sure that the option to delete the private key is not selected.
  14. Click Next.
  15. Provide a password and click Next.
  16. Specify a file name for the exported certificate and private key and click Next.
  17. Click Finish to complete the wizard.

The process is basically the same if you want to export a key from a domain account. The biggest difference is that you must log on locally to a domain controller, rather than logging onto a workstation.

In either case, I recommend exporting the certificate in the key to a form of removable media that can be closely safeguarded. This makes it easy to transport the certificate and the key to the machine you are performing the recovery on. I probably don't have to say this, but it is very important that you do not lose the disk or flash drive containing the certificate and the key.

If you ever need to recover an encrypted file using the certificate that you exported, follow these steps:

  1. Log onto the workstation as an administrator.
  2. Enter the GPEDIT.MSC command at the Run prompt.
  3. Navigate through the Group Policy Object Editor tree to Local Computer Policy | Computer Configuration | Windows Settings | Security Settings | Public Key Policies.
  4. Right click on the Encrypting File System container and choose the Add Data Recovery Agent command from the shortcut menu.
  5. When the wizard starts, click Next, and then choose the Browse Folders option.
  6. Locate the file that you created earlier and click Open.
  7. Click Next, followed by Finish.

About the author: Brien M. Posey, MCSE, has received Microsoft's Most Valuable Professional Award four times for his work with Windows Server, IIS and Exchange Server. He has served as CIO for a nationwide chain of hospitals and healthcare facilities, and was once a network administrator for Fort Knox.


This was first published in March 2008

There are Comments. Add yours.

 
TIP: Want to include a code block in your comment? Use <pre> or <code> tags around the desired text. Ex: <code>insert code</code>

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
Sort by: OldestNewest

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

Disclaimer: Our Tips Exchange is a forum for you to share technical advice and expertise with your peers and to learn from other enterprise IT professionals. TechTarget provides the infrastructure to facilitate this sharing of information. However, we cannot guarantee the accuracy or validity of the material submitted. You agree that your use of the Ask The Expert services and your reliance on any questions, answers, information or other materials received through this Web site is at your own risk.