EFS for System Admins

Saturday Mar 24th 2001 by ServerWatch Staff
Share:

Although the idea behind the Encrypting File System (EFS) in Windows 2000 seems pretty straightforward, there is a great deal more to it than first meets the eye. The purpose of this article is to explain how EFS actually works, and to provide practical configuration advice for system admins.

by Dan DiNicolo
http://www.win2000trainer.com

EFS, I hardly knew ye. 

Although the idea behind the Encrypting File System (EFS) in Windows 2000 seems pretty straightforward, there is a great deal more to it than first meets the eye. The purpose of this article is to explain how EFS actually works, and to provide practical configuration advice for system admins.

Why use EFS? The simple answer is that relying on NTFS permissions alone is sometimes not enough. There are simply too many utilities that will allow a user to bypass NTFS security on the market, such as NTFSDOS. Beyond the utilities, imagine the scenario with a mobile user. If the users laptop were stolen, the thief would only need to either remove the hard drive and place it into another W2K system, or reinstall W2K and take ownership of the folder as the new administrator account. In either scenario, highly confidential data is not safe. If youre looking for more security EFS may be the answer youre looking for, and you cant beat the price.

I'm going to try not to bore you with the details of what you probably already know. Here's the useful beginner stuff, just to get it out of the way:

- EFS can only be used on NTFS formatted volumes. 
- EFS cannot encrypt files if any of the following attributes are set: Read-only, System or Compressed.
- If you have 'write' permissions to a file, you can encrypt it.
- If the user who encrypted the file moves it to a FAT volume, the file is no longer encrypted.
- EFS encryption is relatively transparent to the user. To encrypt a file, the user need only set the encryption attribute on the file, or save it to an encrypted folder.
- EFS is file-system encryption. That means that when an EFS-encrypted file moves over the network, it is NOT encrypted.
- EFS does not prevent a user with the appropriate NTFS permissions from deleting a file. 
- To encrypt many files at once, use Cipher.exe from the command line.
- When an encrypted file is opened, so are temporary copies if they exist.
- Users cannot share encrypted files.
- Only the user who encrypted a file can open it (with exceptions, of course!)


The last item on the list is important. Although the only person who can open an EFS-encrypted file is officially the person who encrypted it, there is still a back door of sorts - the recovery agent. The recovery agent is by default the domain Administrator account (more on this later, but there can be more than one), and can open files that were EFS-encrypted by another user. The reason for this is simple. If a user somehow loses their private key, or snaps and go encryption-crazy on their last day on the job, we have a way to recover their files.

Before I get into the configuration details, I first want to explore how EFS encryption works. EFS uses public-key cryptography in order to secure files. This means that both a public key and private key exist for the purpose of encryption and decryption. However, what the public key encrypts is not the files themselves. Instead, every file is encrypted with a unique key, called a FEK (file encryption key), and this FEK is stored in the header of the encrypted file, in a field called the Data Decryption Field (DDF). The FEK isn't just left there all open and exposed, however. It is encrypted with the user's public key. When the user wants to open the file, their private key is used to decrypt the FEK, and then the FEK is used to decrypt the file. The beauty of this arrangement is that even if a hacker were able to decrypt the FEK, they still only get into a single file, since every file has a unique FEK.

Having said this, how is it that the recovery agent is also able open the file? Well, the FEK is also separately encrypted by the public key of each recovery agent, and stored in different header fields in the encrypted file, called Data Recovery Fields (yes, if there is more than one recovery agent, there will be more than one DRF for the file). For a recovery agent to decrypt the file, the private key of the agent is used to decrypt the FEK, which in turn decrypts the file. So who generates the FEK? The system itself, by way of the CryptoAPI.

Now that we're all cryptography experts (don't I wish!), lets take a look at how all this gets dealt with from the system admin point of view. First of all, you do not need a Certificate server in order to use EFS, though EFS will contact the configured certificate authority for certification is one exists. If a CA for a user is not present, EFS will create a key-pair and will self-sign the certificate, which allows a user to begin using EFS without any further configuration. So, right from the get-go, users can begin encrypting files and folders as necessary. For the sake of simplicity, folders should have the encryption attribute set, and users should be taught to save files into the encrypted folder. Just remember - for the user to be able to open the existing files saved there, the folder must be encrypted while logged on with their own account! As for private key storage, this is stored encrypted by system keys as part of the user's profile. So, if you're using roaming profiles, EFS capabilities follow the user. Otherwise, files encrypted by a user on a given machine can only be opened on that machine, since their key-pair is stored as part of their local profile.

The most important thing you need to understand about EFS as a System Admin is how to recover an encrypted file if necessary. This ability does not have to be limited to the Administrator, although this account is the only recovery agent by default. Before going in to too much detail, you should first understand that on a non-domain system, the local Administrator account is the recovery agent. However, once a system is joined to a domain, the domain Administrator account is then the default recovery agent (with settings found in the default domain policy). Recovery agents are configured via Group policy, in the following location:

Computer Configuration - Windows Settings - Security Settings - Public Key Policies - Encrypted Data Recovery Agents.

You can add or delete recovery agents as necessary, as long as they have a valid certificate. The certificate for the administrator account is created automatically, but you would need to create (or already have in Active Directory) ones for other users you wish to add as recovery agents. 

But as a recovery agent, how do I actually open a file I need to recover? Well, if the user sends you the file, or you're using roaming profiles and log on to their machine, then all you need to do is double-click the file and it will open normally. However, if you are not using roaming profiles, and the user cannot send you the file because of security concerns, then you will need to transfer your certificate and private key to the target machine in order to decrypt the FEK and ultimately the file. What you'll first need to so is export your recovery certificate and private key to a file, probably on a floppy disk. If you export your private key, it must be password protected. To do this, you need to use the 'Certificates' snap-in in the MMC, then find your recovery certificate under Personal Certificates, and choose Export from the shortcut menu. To install the certificate on the target system, simply double click the file, and follow the instructions provided by the Certificate Import Wizard. Finally, for security reasons you should choose to export and your certificate and delete your private key from the target machine once you have decrypted the necessary files. This ensures that should your account be compromised, the user would not be able to decrypt files on the system using the recovery agent private key.
One last area we need to investigate is how to disable EFS. Quite simply, if not managed properly, EFS could become more of a headache than anything else. Though you might think it would be as simple as changing a checkbox somewhere, unfortunately that's not the case. It isn't that hard anyhow, but you need to understand the repercussions of what you're doing. The way that EFS is disabled is by either removing the recovery agents (which is considered having an empty policy), or by applying no policy at all. Although the two look similar, they are actually different in how they behave. Recovery agent policy settings can be set at the domain, OU and local levels. The table below outlines what happens when you have no policy or an empty policy locally, depending upon whether or not the system is a member of a domain. 

  No Policy Empty Policy
System without domain membership Disables EFS Disables EFS
System with domain membership  Depends on OU and domain settings Depends on OU and domain settings

As far as OU and domain recovery policies are concerned, both 'no policy' and an 'empty policy' will have different outcomes because of how recovery policy settings are inherited. 

7 Having no policy applied disables policy at whichever level it were set. For example, if you had no policy applied at the domain level, it would only apply to computers at that level, and any lower level policies (such as OU or local policies) would still take effect.
7 Applying an empty policy at any level disables EFS at that level and all lower levels as well. 

As such, if you wanted to disable EFS throughout an entire domain, the easiest way would be to simply remove all recovery agents from the domain-level policy, leaving it empty. 

And there it is. EFS, while easy to configure for the user, certainly involves a little more consideration from the System Admin. I hope this article has provided you with a solid overview of EFS, a better understanding of how it actually works, and some important details about how it might impact you in your day-to-day dealings with Windows 2000. If you have any questions or comments about this article, or ideas about a topic you would like me to write about in the future, please email me at dan@win2000trainer.com

Until next time,
Dan
http://www.win2000trainer.com

Share:
Mobile Site | Full Site
Copyright 2017 © QuinStreet Inc. All Rights Reserved