By Karl Koehler

By now, most of you have probably heard something about EFS, Microsoft’s Encrypting File System that is included in Windows 2000 and Windows XP Professional. This file system allows users to easily encrypt files or folders on Windows 2000 and XP systems running NTFS partitions. A great deal has been written on both the good and bad aspects of using this new feature. In this Daily Drill Down, I’ll address both sides and take things one step further by looking at what happens when EFS is actually used in the real world by the end users for whom it was designed—not by administrators who understand the technology behind it and when and why it should be used. I’ll also cover the steps necessary to disable EFS on both Windows 2000 and XP systems.

EFS basics
EFS is included in Windows 2000 and XP to allow users to add an additional layer of security on top of the NTFS security that has been used for years with NT. EFS does not work on data stored on FAT or FAT32 partitions.

EFS is designed to be easy to use, even transparent to the end user, so that it’s possible for someone to use it and not even be aware of it. EFS uses 128-bit DESX encryption to protect the data stored in encrypted files and folders; it associates a file with the user who encrypted it using PKI, not the username and password. This allows for passwords to be changed on user accounts without making encrypted data unreadable. EFS is enabled on Windows 2000 and XP Professional systems by default and allows any user with modify permissions to encrypt a file or folder by simply checking a box under that file’s or folder’s advanced properties, as shown in Figure A.

Figure A

When used properly, EFS can prevent sensitive data from being read by someone who has managed to circumvent NTFS security. While the potential for increased security does exist with EFS, and that’s a good thing, it can also provide a false sense of security, which is bad. There are quite a few things that can go wrong, some of which can get quite ugly. It’s important to understand not only what EFS can do, but what it doesn’t do. There are quite a few false assumptions about the security provided by EFS, so let’s dispel those now.

What EFS doesn’t do
EFS protects data from being read, not deleted. Because attempts to copy an EFS-encrypted file fail, many assume that an unauthorized user cannot delete the file either; however, it can be deleted.

EFS protects data stored on a local NTFS partition. It does not protect data when it is sent across a network. This is a big issue. Because EFS was designed to be transparent to end users, when the user who encrypted the file copies it across the network or sends it via e-mail, the file is automatically decrypted before it is sent across the network so that it can be readable on the target system. For a user who does not understand this, and believes that his or her sensitive data is secure, the mistake can be costly.

EFS is not usable across the network on mapped drives unless the server and client operate within the same Active Directory forest and the server has been trusted for delegation. Only domain controllers in an ADS environment are trusted for delegation by default. Understanding these limitations is important for EFS to be used effectively. As Microsoft had intended, EFS is easy to use, but using it still requires proper end-user training. How many users on your network understand these concepts? Or possibly more important: How many users on your network have access to the use of EFS, yet do not understand it?

Bad things can happen when EFS is misused
So much about what has been written about EFS, especially from Microsoft, seems to take the view that end users always do things properly and never accidentally or, worse yet, intentionally use technology like EFS to mess things up. But if you have to support computer systems for a living, you know end users do not always do things properly. If EFS is being used in your environment (remember, it is enabled by default), then it’s imperative to understand what can go wrong and what you can do about it.

One of the first things that should concern any support tech or network admin is the fact that any users with modify permission (the ability to write) to a file or folder can encrypt it. This can certainly be applied to files they did not create. Could this cause a problem in your environment? Do multiple users share the same system? If so, problems can certainly arise. Do you have domain controllers that also act as file servers in your Active Directory environment? If so, a user could encrypt a file that a large group of people is allowed to modify and accidentally make it inaccessible to everyone else. Having EFS enabled by default gives end users the roundabout ability to make such a problematic change.

Note

If users have full control to a file, they can also change the NTFS permissions to deny someone access. This is why you should always modify permissions for nonadministrative users and groups. Certainly, few admins want the end users dictating who can access data on the network.

EFS problems can be difficult to recognize
The problems with EFS can be greatly compounded if you’re not looking for it as a possible culprit. When a user tries to access a file that has been encrypted by someone else, depending on the type of access attempted or the application being used, the user will generally get one of two messages: Access Denied or This File Appears To Be Corrupted.

If the Access Denied message appears, most end users assume that an admin has improperly locked them out, so they contact the help desk. If the person troubleshooting the problem just looks at the permissions on the file or folder, there’s no indication that a user has been denied access. Only bringing up the file’s advanced properties will reveal the problem. Many man-hours can be wasted pursuing other potential problems, such as group permission conflicts.

Of the two common messages users receive when they are not allowed to read the file due to EFS, the Access Denied message is the good one. Users receiving a message indicating that the file appears corrupted may go so far as to delete the file. Since EFS will not stop the deletion, users will be able to do so. If the person troubleshooting the situation is not looking for EFS as the potential problem, things can get far worse when the message This File Appears To Be Corrupted occurs. There are quite a few horror stories already being attributed to this scenario. Take the following example:

Two users working different shifts share the same Windows XP Professional system. The user working the evening shift has a fair amount of downtime and uses it to explore different aspects of the system. Upon discovering the Encrypt Contents To Secure Data setting, he decides to activate this feature. “What’s wrong with securing the data?” he says to himself.

He has selected a file in a folder shared by both users, and the default EFS setting indicates that not only should the file be encrypted, but the parent folder as well. The user accepts this and clicks OK. Now every file created in this folder will be encrypted to the user who created it and unreadable by the other user. The user in the evening modifies these files without issue and believes everything is working fine.

When the daytime user tries to open a file in this folder, she receives a message indicating that the file’s data appears to be corrupted. She calls the help desk and indicates that there’s a problem. The files in this folder need to be written to everyday as part of their jobs, so the problem needs to be solved quickly. A help desk tech shows up and begins troubleshooting the problem. The tech tries deleting and restoring the file from the nightly backup, but unfortunately EFS files back up encrypted. So the restored file also comes up corrupted. The tech believes this signals a problem with the application used to edit the file. The tech reinstalls the application, but the problem persists. Needing to solve the problem quickly, the tech decides to reload the operating system, since there’s a backup of the data. The reload of the OS erases the keys used to encrypt the data, and it’s now completely unreadable!

Of course, even without making the above mistake, data loss due to EFS is still possible. With encrypted data getting backed up encrypted, what happens when a system has to be reloaded simply due to it crashing and not rebooting? There are many ways to avoid these potential pitfalls, but the ease of use that EFS is supposed to have goes out the window. The system state or EFS keys can be backed up and restored on the reloaded system to regain access to the data. If you’re using EFS on your network, these are no longer merely “best practices”—they are necessities. (Note that you can take quite a few steps in an Active Directory environment to avoid these pitfalls, making it safer to use. But they’re not part of the default configuration of EFS.)

Laptops make the best EFS candidates
The last question I want to look at is whether you should be using EFS. EFS does not help secure data as it is transmitted on a network or across the Internet where it is most vulnerable. And it doesn’t work on the most commonly used removable media, floppies, which can be easily lost. Where, then, should it be used? Microsoft’s own white paper on EFS is very telling. According to the white paper, EFS was intended to be used on systems where the NTFS permissions of locally stored data could be circumvented by having physical control over a machine. Hopefully, your network environment is not one where most of your desktop clients’ systems are easily vulnerable to theft. (If that’s the case, you shouldn’t store sensitive data on those systems.)

This leaves one particular system as the prime candidate for the use of EFS: laptops. If laptop users on your network must store sensitive data on those systems, the data should be encrypted. If you’re going to use EFS, though, make sure you follow Microsoft’s best practices and remove the private key for the user from the OS and store it on a floppy or, better yet, on a smart card. Also, it’s best to use Windows XP if you need this feature, as hacking EFS on a system you physically control is relatively simple, and the steps to prevent it render EFS unusable on a Windows 2000 system. I’ll explain this in a moment.

Removing EFS from Windows 2000 and XP workstations
If you decide that EFS is not right for your environment, you’ll need to disable EFS on Windows 2000 or Windows XP. I’ll look at this process on Windows 2000 first.

Windows 2000
Microsoft wanted to ensure that recovering encrypted data was possible, even if you accidentally deleted the user who encrypted it. To do this, a user is assigned as a recovery agent on each Windows 2000 system. By default, this user is the administrator. This means that, by default, the administrator can decrypt any files encrypted on the local system. This also opens up Windows 2000 systems to an easy EFS hack. If a laptop is stolen and contains encrypted data, simply logging on as the admin could provide that thief with access. Obtaining admin access is as simple as booting the system with a floppy containing the NTFSDOS utility from Winternals and deleting the SAM file, making the admin password null. Even if a different account is used as the recovery agent, the thief who is now the admin can change that account’s password and log on as that account. Not only would the private keys for the user using EFS on the laptop need to be stored on a floppy or smart card, but so would the recovery agents, making EFS highly impractical to use.

Why not just delete the recovery agent then? Because that disables EFS on Windows 2000 systems. And that, of course, is how you also intentionally disable EFS. Simply bring up the local system security policy and remove the administrator certificate from the folder marked Encrypted Data Recovery Agents, as shown in Figure B.

Figure B

Windows XP
Windows XP is designed to allow for the deletion of the recovery agent to address Windows 2000’s weakness and, while that’s good news for those wanting to put EFS to use on their laptops, it means that you must find a different way to disable it on Windows XP. Group Policy is still used to disable EFS on XP systems in an Active Directory network, but an admin template must be imported into the Domain Group Policy first. If you’ve never created an .adm file before, don’t worry; it’s a simple process. First, cut and paste the text found in Listing A into a text file in Notepad.

Now save the file with the name efs-diable.adm. Bring up the Group Policy for the domain. (If you’re not familiar with this, right-click on the domain inside the AD Users And Computers tool, and choose Properties. Click on the Group Policy tab and then click Edit.) After bringing up the Group Policy for the domain, open the computer configuration section. Right-click on the Administrative Templates folder. You should have the option to Add/Remove Templates. Choose that option and then click on the Add button. Browse to the .adm file you just created and click on Open. Now click on Close. You’re all set. You’ll now find a folder under Administrative Templates called Special EFS Handling.

Figure C

Enable the Disable XP and .NET EFS (as shown in Figure C), and all XP systems in the domain will have their EFS disabled. This process works on the local system Group Policy for Windows XP Professional systems that are not running in an ADS environment if they’re running SP1. You should now get the error shown in Figure D.

Figure D

If you test it and find it not working on your local XP system, you can hack the registry manually using the following text as the .reg file:
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\
CurrentVersion\Efs]”EfsConfiguration”=dword:00000001

Just double-click on the .reg file and choose to import it into the registry. I’ve had better success with this method on XP systems not running SP1.

Used properly and with the right preparation, EFS can add the additional security you may need on your network. Hopefully, making that decision is easier after reading this article. If you do decide that EFS is needed, definitely take a look at Microsoft’s white papers on the subject and review its best practices. Microsoft makes EFS sound easy in its ads, but the white papers will give you a much better idea on what’s needed for proper implementation.