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:
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 p
To continue reading for free, register below or login
To read more you must become a member of SearchEnterpriseDesktop.com
roblems 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:
Figure A
[IMAGE]
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.
