Microsoft Windows' Encrypting File System (EFS) allows you to encrypt files on a remote server, helping to prevent sensitive data from being disclosed. EFS tends to be pretty straightforward when it is used to encrypt files on a local hard drive, but it can behave a bit unexpectedly when you attempt to encrypt files residing on a shared network volume.
The most common problems with decrypting remote files stem from the inability to locate the user's profile and the private keys that it contains. Problems can also result if the server that's hosting the encrypted files does not support delegation.
Symptoms of decryption problems
The biggest problem regarding the use of encrypted files on shared network volumes is that users may have trouble decrypting the files once they have encrypted them. When Windows fails to decrypt remotely stored files, users won't typically see an error message citing decryption problems. Instead, a user will receive a simple Access Denied message.
Why did decryption fail?
In order to understand the possible causes of a decryption failure, you need to understand what's going on when EFS decrypts files that are stored on a network volume. Here are the basic steps taken:
- EFS locates the user's profile
- EFS locates the user's private keys
- Since the user is not logged on locally to the server, EFS must impersonate the user, and presents the server with the necessary private key on the user's behalf.
- When EFS uses the correct private key, the file is decrypted.
That's the process in a nutshell. With this in mind, you can see that there are two basic areas in which the decryption process can break down. EFS can have trouble locating the user's profile (which contains the user's private key), or it can have problems impersonating the user.
User profile problems
Assuming that the user's private keys have not been deleted, profile-related problems usually revolve around a user logging in from a different computer. If a user logs on to a computer other than the one he normally uses, his profile is left behind. Microsoft Windows will create a profile for the user when he logs on to the new machine, but the profile will not contain the user's private keys.
The solution to this problem is to use roaming profiles. This ensures that the user's private keys follow the user from computer to computer.
Delegation problems
As mentioned earlier, EFS must impersonate the user because the user is not logged on locally to the server that contains the encrypted files. If a user has access to the correct profile, but decryption still fails, then the problem may be delegation related.
To find out whether this is the case, follow these steps:
- Open the Active Directory Users and Computers console.
- Right click on the computer that contains the encrypted files, and choose the Properties command from the resulting shortcut menu.
- When the computer's Properties sheet appears, select the Delegation tab.
- Verify that the Trust this Computer for Delegation to Any Service option is selected, as shown in Figure A.
Figure A
The server that's hosting the encrypted files must support delegation.
About the author: Brien M. Posey, MCSE, is a Microsoft Most Valuable Professional for his work with Windows 2000 Server and IIS. He has served as CIO for a nationwide chain of hospitals and was once in charge of IT security for Fort Knox. As a freelance technical writer, he has written for Microsoft, TechTarget, CNET, ZDNet, MSD2D, Relevant Technologies and other technology companies.
