Enhance infrastructure security by using EFS

Microsoft first introduced EFS in Windows 2000. But with Windows Server 2003, Microsoft has strengthened and improved EFS. Learn more about how to set up an EFS system in Windows Server 2003 with WinXP Pro clients.

Windows Server 2003 provides a number of changes and improvements to the Encrypting File System (EFS), which was introduced in Windows 2000. Many of these improvements are also included in Windows XP Professional, and the use of XP Pro enhances the use of EFS at the server level. Let's take a look at how to set up an EFS system under Windows Server 2003 Enterprise Edition when using Windows XP Professional clients.

More about EFS
EFS is a technology by which the files on the NTFS partition are encrypted to protect against unauthorized access. While share and NTFS permissions can be used to handle this task over the network, these permissions don't protect the data in the event that someone has physical access to the server. In such an instance, an intruder could boot the machine from a floppy or CD-ROM, bypass the share and NTFS permissions that are on the file, and directly access the files on the machine. The only way to prevent this type of unauthorized access is by encrypting the files on the disk. It should be noted that only NTFS supports EFS. If you are using a FAT or FAT32 partition, you will need to convert it to NTFS before you can use EFS services.

EFS can be particularly useful in environments where laptops are used and moved around frequently, because the use of EFS will make the data useless in the event the unit is stolen or in situations where there is relatively little physical security for the data center. (This is a very common situation in smaller work environments.)

Things to know about EFS in Windows Server 2003
When EFS files are stored on the NTFS volume, they are secured against unauthorized use. This isn't true of the same file while it is being transmitted across the network, though, unless you are using IPSec or Web Distributed Authoring and Versioning (WebDAV) on the network. Additionally, if you move an encrypted file to a non-NTFS partition, the file is unencrypted before it is moved. If you move an encrypted file to a different server, it is only encrypted if it is put into an NTFS partition.

In Windows 2003, EFS also supports offline file encryption, which allows files to be encrypted while they are stored offline. In addition, multiple individual users can share an encrypted file. However, a group cannot be given access to the file. Multiple users must be granted access to the encrypted file individually.

EFS in Windows Server 2003 is based on 3DES and AES, unlike the DESX encryption method in Windows 2000. This provides a more secure and standard encryption scheme.

User profile location matters
When considering an EFS implementation as a part of your overall security infrastructure, also consider implementing roaming profiles. EFS works by using sets of public and private certificates. The certificate for the currently logged in user is used to encrypt the file and access to this certificate is required for successful decryption.

When running in an environment without roaming profiles, if a user encrypts files using different client computers, he or she will be unable to access the files from other systems. For example, if the user encrypts a file on the server named file1 from the system XP1, and he encrypts a file named file2 from XP2, the user will be unable to access file2 from XP1 and vice versa. This could quickly become a significant problem for an organization.

When roaming profiles are used, users don't experience such problems. Because the certificate is stored with the central profile, the same certificate will always be used for encryption regardless of which machine the user accesses.

Basic EFS operation
Getting started with a basic EFS setup is as easy as a few mouse clicks for a simple configuration. For these steps, I will assume that you're using roaming profiles to avoid the certificate confusion. From the client, browse to the file that you would like to encrypt. Right-click it and choose Properties from the shortcut menu. On the General tab, click Advanced. You'll then see the screen shown in Figure A.

Figure A
You can encrypt this file using the current user's certificate.

On the Advanced Attributes screen, select the box marked Encrypt Contents To Secure Data, and click OK. When you're done, the file name will appear in green, which indicates that it has been encrypted. In Figure B, I've also added the Attributes column to the folder listing so you can see that the file's attributes mark it as encrypted.

Figure B
This shows the file's directory listing and attributes.

To see who has access to an encrypted file, you can view the file's encryption details by right-clicking it, choosing Properties, clicking the Advanced tab, and clicking Details on the Advanced Options window. The encryption details for the file I just encrypted are shown in Figure C.

Figure C
This screen shows the details of the encrypted file.

As you can see, the user slowe@example has access to the file. In addition, the administrator user is granted rights as a Data Recovery Agent (DRA). EFS creates a DRA automatically so that this step is not skipped, which would result in inaccessible files. To change the user whose certificate is used by default, you need to change the EFS group policy by going to Active Directory Users And Computers | Domain Properties | Group Policy | Edit | Computer Configuration | Windows Settings | Security Settings | Public Key Policies | Encrypting File System.

From there, you can either add or create a DRA. If you already have a user certificate you would like to use, you can add it. If not, you can create a new DRA. To do either, right-click anywhere in the window and choose the appropriate option.

DRAs obviously also have access to the files, which means that they can open it just like the person who encrypted the file in the first place.

Did it work?
The easiest way to make sure the file is inaccessible to other users is by trying to access it. For proper testing, make sure that another user has the share and NTFS permissions necessary to access the file. For this example, the location that I have shared in my lab allows anyone to access the file. When I log in as a different user and try to access the encrypted file, I get the message shown in Figure D.

Figure D
Access to this file is denied.

As you can see, this user is unable to access the file. However, this user can delete the file. You might be confused as to how this is possible. Here's the answer: The user has full share and NTFS permissions to the file. These permissions include reading, modifying, and deleting the file. If the user doesn't try to open the file, the EFS subsystem isn't required. If the user tries to open the file, the EFS subsystem intervenes and denies access. But users can simply delete the file, which they have rights to do as defined by the NTFS permissions. Remember, file encryption is used to protect the contents of a file from prying eyes. It is not designed to protect the file itself. That's why a properly designed share and NTFS structure is still critical even when using EFS.

Adding users
In Windows Server 2003, multiple users can be granted rights to read and modify encrypted files. On the file's encryption details screen, click the Add button to add additional users. Select the users to whom you would like to grant access. They will show up in the list of users allowed to access the encrypted file, as shown in Figure E.

Figure E
These additional users have been allowed access to encrypted files.

Note that if you aren't using roaming profiles, you won't have much luck with this feature, because it is dependent on a central location for certificates.

Other points
When an encrypted file is moved or copied from its source location to a new location, it is first decrypted. But this isn't a hole in the security scheme. To copy or move an encrypted file, you must have the ability to open the encrypted file. In fact, even if a user has NTFS rights but doesn't have rights to decrypt the file, he or she will be greeted with the error message shown in Figure F.

Figure F
Without rights, the file can't be moved or copied.

EFS: Extremely flexible security
With a little advance planning, EFS can be added to your security infrastructure. It's not difficult to implement as a stand-alone security service and can be useful in protecting the information assets of your organization.

Editor's Picks