Removing EFS from Win2K/XP clients

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.