4.2 Protecting Data with the Encrypting File System

     

As I discussed in the previous section, NTFS checks the ACL for each file and folder a user accesses and compares it against her access token. Access is granted only when the appropriate permissions are held by the the requester. However, this architecture has the potential to be circumvented. If NTFS isn't used to access the hard disk, the data can be read just like any other data. Because Windows Server 2003 and Windows XP allow only NTFS to access its own partitions, this security is effective. If another operating system is used, or if special disk-reading equipment is connected to the hard disk, the data is completely unprotected .

The only way to ensure that data on the hard disk is not susceptible to this type of attack is to protect it with encryption. Storing the data on the hard drive in an encrypted state means that the requester must provide the decryption key for the data to be usable. Without the decryption key, the data is useless to the requester ”regardless of the operating system making the request. Windows XP and Windows Server 2003 allow files on the hard disk to be encrypted using the Encrypting File System, or EFS.

4.2.1 How EFS Works

To discuss the concepts and processes of EFS, I must first dispel a myth. EFS is not really a file system at all. It is a set of functions that work in conjunction with NTFS to encrypt and decrypt files that are stored on the hard drive. NTFS provides the core mechanics of fetching data from the hard drive, writing to the hard drive, checking ACLs, and so on. EFS does the added work of determining when a file must be encrypted or decrypted and performing that action.

Specifically , EFS works by generating a random symmetric key for a file, called the file encryption key (FEK), and encrypting the data portion of the file with that key. It then takes the requester's public key from the local key store and encrypts the FEK with that public key. This chunk of encrypted data that allows the requester to decrypt the file is called the data decryption field (DDF). There is always at least one DDF for an encrypted file.

EFS then checks to see if any data recovery agents (DRAs) have been defined in a recovery policy. A recovery agent is an optional user who holds a specific type of certificate private key that, when configured properly, allows him to decrypt EFS files. If recovery agents have been defined, their public key is also used to encrypt a copy of the FEK. This chunk of encrypted data that allows a recovery agent to decrypt a file is called a data recovery field (DRF). Because more than one recovery agent can be defined through a recovery policy, there may be more than one DRF per encrypted file.

In Windows 2000, EFS required at least one recovery agent to operate . When no recovery agents were available, EFS would refuse to encrypt files. In Windows XP and Windows Server 2003, EFS allows full functionality without a recovery agent in place. This allows configurations in which only one unique key can decrypt data. To disable EFS in Windows XP and Windows Server 2003, a Group Policy Object must be defined or a group of registry settings must be made.

The result of all these operations is encrypted data, one or more DDFs, and zero or more DRFs. This data is then handed back to NTFS. NTFS writes all this data as provided to the hard drive and additionally marks the file as being encrypted with EFS. This process of encrypting files with EFS is shown in Figure 4-8.

Figure 4-8. The EFS encryption process

Another common myth about EFS is that folders can be encrypted. While folders can be flagged to encrypt their contents, the folders themselves are not encrypted. Rather, new files within those folders will be automatically encrypted when they are created in that folder, and optionally , any existing files in the folder will be encrypted. This is a desired configuration for EFS, as it will ensure that new datafiles or temporary copies of encrypted files in the same directory will be protected. When individual files are marked for encryption and not the parent directory, data may unwittingly be written to the hard drive unencrypted.

When an application requests data from an encrypted file, EFS has to decrypt it. To do so, NTFS retrieves the entire file and passes the information to EFS. EFS examines the public and private keys of the requester to determine whether any of these keys can be used to decrypt a DDF or DRF associated with the file. When such a key is found, the FEK is decrypted and used to decrypt the file data. This decrypted data is then passed back to NTFS, which provides it to the original requester. Because all this is handled by NTFS and EFS, applications do not need to be aware of EFS files or take any special actions to handle them. This process of decrypting files with EFS is shown in Figure 4-9.

Figure 4-9. EFS decryption

The process of decryption with a data recovery agent's private key is the same as with the user's private key, except that the DRF is decrypted instead of the DDF.

A new feature of EFS in Windows XP and Windows Server 2003 is the ability to have more than one DDF per file. This allows a user to add users to a file and give those users the ability to decrypt the file without being recovery agents. This EFS file sharing provides a highly secure way to share data between users when the data is located either on a local hard drive or on a network file share. The ability to have more than one DRF recovery agent per file has existed since EFS was first implemented in Windows 2000; it is only the ability to have multiple DDFs that's new.

This new ability of EFS has one roadblock. The public keys of all additional users must be available to the file's owner to add them as potential decryptors of the data. There are a few mechanisms to aid in locating public key certificates, such as Active Directory, but this is still largely a manual process. In most cases, the file owner must ask the desired user to identify, export, and then transfer a public key certificate. This can be time-consuming and is not a simple operation to perform for the majority of users. For more information on certificate stores and operations, see Chapter 9.

4.2.2 Benefits of the Encrypting File System

The true benefit of EFS is that the encrypted files are stored in a secure manner. Physical compromise of the computer does not necessarily compromise the data.

Consider our IT manager, Don Fink. Don uses a laptop as his primary work computer. He stores all his data on it, whether sensitive or not. He carries it to work and back home every day. When the laptop is at work, he keeps it chained to his desk there, and when at home, he chains it to his home desk. Don also happens to travel frequently by air and is no stranger to airports.

Karen Shaughnnessy, a would-be corporate espionage operative , has been hired by a rival to learn key information about Woodgrove Bank. Karen has targeted Don as a potential wealth of information. She feels Don will have enough information stored on his laptop to make overt theft worthwhile. Although Don doesn't know it yet, he's about to become a victim.

Through a process of careful observation and intelligence gathering, Karen knows what type of laptop Don has, as well as the briefcase he uses when traveling. She also learns when Don's next trip is scheduled. Karen obtains a duplicate of the briefcase and ensures she is in line directly behind Don when going through the airport security checkpoint. This allows Karen to switch briefcases and leave with Don's laptop. Don may not notice for a few minutes or even until he's on his airplane. Either way, once the laptop is out of Don's possession it's too late.

Karen knows that there may be security safeguards on the computer. To work around any potential traps or protections , she removes the laptop's hard drive. She then connects it to a computer already running another operating system, one that recognizes NTFS but doesn't interpret ACLs (there are many of them). From there, it's a simple matter for Karen to copy the contents of Don's hard drive to her computer and begin sifting through the data.

This scenario happens more often than people realize. I periodically see news articles about laptops being stolen from corporate employees during transport. Unfortunately, there is no supplemental data to cite which laptops are business-oriented versus personal, but common sense says that a majority of laptops carried while traveling are corporate laptops. In all likelihood , a majority of these laptops contained at least a small amount of sensitive data. However, most corporations simply refuse to publicly admit that this happens to them. They may put procedures in place to try to avoid future repeats of the same incident, but often these attempts fail. If you use EFS to protect the data correctly, however, the problem can be solved .

Laptop Lost and Found at Seattle-Tacoma International Airport

I read about the most alarming cases ”laptops and hard drives with secret data being lost ”in the news periodically. But the reality of data compromise due to lost laptops exists every day. Because of the frequency of business travel, the loss of laptops at major airports is far more common than you might think. Monique Reed-Jones, operations manager of lost and found at Seattle-Tacoma International Airport, was kind enough to furnish us with statistics and current trends.

Monique is not a computer person by trade. In fact, she works for the subcontractor that holds the lost and found contract ”the YWCA. She receives all items lost at the airport and is responsible for reuniting these items with their rightful owners. She speaks with a certain pride in her work: "In virtually all cases involving laptops, we're able to return them to their owners quickly." This is great news from a capital standpoint, as the individual or company won't have to purchase a new laptop to replace the loss. However, it's the frequency with which Monique has to do this task and her investigative methods that should alarm security professionals.

During 2002, Monique had 697 laptops come through her lost and found department. Of those laptops, every single one was reunited with its owner. Monique has developed a very basic flow for identifying the owner of each laptop. First, she visually scans the outside of the laptop and any containers it came in for identification. Wise business travelers, Monique says, keep some basic contact information outside the computer, such as a laminated business card. She also looks for any corporate property tags.

Next, she boots the computer. "Very few computers need a password," says Monique. Once she reaches the desktop, she looks for recently used documents or scans the My Documents folder. More often than not she can find a document with identifying information there and quickly make contact with the owner. The most common document found? A resume.

If she fails to locate a resume or other suitable document, Monique starts the laptop's email program and scans the inbox and address book. She's looking for easily identified parties such as correspondence with family members or coworkers.

Monique's last resort is to call the laptop manufacturer and provide the serial number of the laptop. Some manufacturers are able to associate registered laptops with their owners and either provide contact information or initiate the contact themselves.

The fact that Monique gets information from computer manufacturers shouldn't alarm you. Neither should the fact that one of her investigative tools is to attempt to boot the operating system. What should make your jaw drop open is the fact that this is her most successful method. The vast majority of the laptops Monique sees are completely unprotected ”both the operating system and the data on the hard drive. If there is any sensitive data on the computer, she now has unfettered access to it. She could easily sell this information on the black market, snipe patent filings, or commit insider trading depending on the laptop. Although this behavior is illegal (and Monique certainly never does it), it's quite profitable and happens frequently.

There is some good news. Monique says lost laptop instances have signifigantly dropped off since the Transportation Security Administration (TSA) took over airport security screening procedures. This is primarily due to the TSA's security screening procedures. They now ensure that at least one TSA employee is responsible for ensuring that each screened passenger leaves the area with exactly what she arrived with. When individuals are screened with greater scrutiny or taken aside, the employee ensures her items follow. In the long run, this may reduce the number of all items left in the screening area and help prevent data compromise.

And that would be fine by Monique.

Let's assume Karen stole Don's laptop as mentioned earlier. If Don has encrypted his sensitive data with EFS, Karen must obtain Don's private key to decrypt the data. As long as Don's password is sufficiently complex, this will take Karen a very long time. If Don were carrying particularly sensitive data, he may have removed the private key entirely from the computer and stored it on a floppy that he kept separate from his laptop. In that case, Karen must use a brute force attack to try to decrypt the data. Assuming Don is using AES encryption for his file (Don can configure the encryption EFS uses, though it's not advisable), there are 2 ²⁵⁶ , or about 1.158 x 10 ⁷⁷ , possible keys. Considering current technology, this type of attack would take so long to break that the data would be useless long before the attack succeeded. Also, remember that each EFS file has its own unique FEK. This means that the number of possible keys applies to each encrypted file individually.

Karen might use an attack commonly referred to as the Nordahl attack to gain access to Don's files. In this attack, Karen installs another operating system or boots to another operating system with the compromised hard drive attached. Karen then uses tools to reset or overwrite the security information in Don's SAM database. Very often, the attacker can overwrite the administrator password with her own. It's then a simple matter of booting to the target OS and logging in. The two mitigations to this type of attack ”removing the DRA's key from the local computer and using Syskey to protect the operating system's account database integrity ”are both discussed in this chapter.

4.2.3 Drawbacks of the Encrypting File System

As you can see, EFS is a strong and effective way to protect data. Although it has enormous benefits, it does have some drawbacks. For example, encrypting a large amount of data with a strong key can take a noticeable amount of time. With the computing power available today to most users, this isn't usually a problem. However, when used inappropriately, EFS can degrade a system's performance. Consider the suggestions in the next section to ensure that it is used to maximum benefit while avoiding potential performance pitfalls.

Another feature that's often considered a drawback is EFS' reliance on private keys. Now that you know how EFS works, you can see that it requires the private key of a configured user or DRA to decrypt the data in a file. Without an appropriate private key, the data is lost. This makes the private key very valuable ”without it, your data is lost! Sadly, most users and administrators do not realize this and reformat or reinstall their computers without backing up their private key stores. This often results in lost data.

You can avoid lost data in many ways. Simply backing up the private key is a very effective preventative measure. You can also configure a DRA in your domain and ensure that the DRA's private key is kept safe. Both of these measures prevent EFS data loss, and both are discussed in this book.

4.2.4 Using the Encrypting File System Correctly

EFS is simple to use and is only slightly more difficult to use correctly. Remember these few basic guidelines when using and deploying EFS:

• Encrypt at the folder level instead of at the file level. This marks the folder so that new files created in the folder are encrypted at creation and continue to be encrypted.

• Remove the private key of both the user and recovery agent when not in use. If a valid private key exists on the hard drive when it is compromised, it may be easier to attack that private key storage than to attack the EFS-protected files. Although this is cumbersome and temporarily prevents authorized users from reading files, it's necessary to separate the key from the data to maximize the effectiveness of any encrypted data. For detailed guidance on this, see Chapter 9.

• Encrypt only data that must be protected. Judicious use of EFS helps ensure system performace remains as high as possible.

• Wipe the hard drive free of unencrypted data remnants after encrypting sensitive data. The process for doing this is covered later in this chapter.

• Ensure an appropriate data recovery strategy is deployed throughout your organization before EFS is used. Clients lose their private keys more often than you might think. If there's no way for you or a designated recovery agent to decrypt the files, the protected data may be lost. Either back up each user's private key or establish a DRA to prevent against data loss.

Security Showdown: EFS Data Recovery Strategies

Most security policies recognize that recovery of protected data is important. EFS has two distinct approaches to providing that data recovery. In this segment of Security Showdown, Don and Mike will debate the benefits of each.

Mike : My preference in this technology is to implement a PKI-based key recovery agent and provide for centralized key distribution and archival. The EFS recovery agent configuration is more work than it's worth. Every time any of my users encrypts a file, he must use that RA's certificate to create the DRF. When you add up the number of files and users in an enterprise, it adds up to an unacceptable level of waste.

This does require that a PKI is established. But even creating a single certification authority (CA) in its own hierarchy will allow you to provide for this type of certificate issuance. Then you get the benefits of an enterprise CA ”including autoenrollment , customizable templates, and so on ”as well as a single private key repository. How can you go wrong? And if you already have a PKI, you need do nothing more than issue EFS certificates from that existing hierarchy.

In addition, if I'm already archiving keys in my PKI, I can leverage that for EFS. I don't have to establish a new set of recovery agents, establish trust in them, obtain senior-level buyoff on the configuration, and so forth. I can simply tack on the EFS-specific needs and hit the ground running.

Finally, the Windows Server 2003 enterprise CAs provide a highly functional key recovery technology. The CA database stores the private keys, which are cryptographically protected. You can even configure it to require more than one party to recover a key ”which is great for accountability and auditing. EFS RAs have no such requirement, as any RA can recover the files single-handedly and without scrutiny.

Don : Good points, but a centralized recovery isn't always the right answer. In smaller organizations, for example, implementing the PKI necessary to support a key recovery agent is overkill ”something like building a dedicated highway from your house to the convenience store. Might be nice, but it's expensive and a lot of work.

On the other hand, you could just distribute the RA's certificate via Group Policy. Group Policy is definitely the thousand- pound gorilla of centralized control, so you can't argue that it's too much work ”even in a large organization. Instead of distributing certificates to each and every user manually, you just have Group Policy configure their client computers to have the certificate. It's automatic and transparent and requires very little effort. At the same time, you don't have to fuss with a PKI, worry about revocation lists, and so forth. Heck, with PKI, you'll still have to use Group Policy to configure client computers to trust your CA; why not use Group Policy to solve the problem directly by distributing the RA certificate?

Mike : I've got to admit you have a point. A full PKI solution just for EFS is a bit of overkill. Using Group Policy to distribute the RA's certificate is elegant and well distributed. I still prefer a full PKI, because I think most organizations could benefit from deploying PKI. But in some cases, an EFS RA might be acceptable.

4.2.5 Example: Ensuring New Files are Encrypted

Don Fink knows that his laptop is susceptible to theft. Unfortunately, he cannot avoid storing sensitive and proprietary data on it when traveling between offices. Don wants to store data securely so that, no matter what the situation, his data will remain confidential and only he can retrieve it. He would rather lose the data entirely than have the data fall into the hands of his competitors .

Don's Windows Server 2003 infrastructure does not yet include a centralized certification authority (CA). He knows very little about public key cryptography and certificates. He only knows that he must keep his data confidential. Here are the steps that Don would take to create a new directory and ensure that its contents are encrypted:

1. Create a new folder on the hard drive to store his sensitive files. The path to Don's folder is C:\Secrets , although this name could be anything.

2. Right-click on the folder and choose Properties.

3. Click Advanced.

4. Select the Encrypt Contents to Protect Data checkbox.

5. Click OK, then click OK. If the Confirm Attribute Changes dialog box appears, choose "Apply changes to this folder, subfolders and files."

The folder and all its contents, including files and subfolders, are now encrypted. Because Don did not already have a certificate and private key that EFS could use, EFS generated one before encrypting the contents.

A public key certificate and associated private key may already exist for Don. This depends on whether a certification authority has been installed and configured within Woodgrove Bank and, if so, whether it is configured to issue EFS-usable certificates. In many cases, Don will have such a certificate and not know he has one. The only way Don can determine what certificate is used for EFS is to use the Certificates MMC snap-in as described later to identify the certificate with the Encrypting File System listed as its Intended Purpose.

4.2.6 Example: Managing the Private Key to Ensure Maximum Protection

Don knows that retaining the private key on the hard disk is inadvisable and that he must export the certificate and private key to a floppy disk for safekeeping. He can do this by completing the following steps whenever he is finished working with his encrypted data:

1. Click Start, click Run, type mmc.exe , then press Enter.

2. Click File, then click Add/Remove Snap-in.

3. Click Add.

4. Click Certificates, then click Add.

5. Select My User Account and then click Finish.

6. Click Close, then click OK.

7. Expand the Certificates ”Current User container, expand the Personal container, then click Certificates.

8. Click the certificate that lists Encrypting File System under the Intended Purposes column. This is shown in Figure 4-10.

9. Click Action, click All tasks , then click Export.

10. Within the Certificate Export Wizard:

    1. Select "Yes, export the private key."

    2. Select "Delete the private key if the export is successful."

    3. Enter a strong password that is difficult to guess.

    4. Enter a save path to a floppy disk and click OK.

Figure 4-10. Selecting the EFS certificate based on the Intended Purposes field

Now the private key is removed from Don's saved private keys. EFS can continue to operate using the private key it has cached, but once Don logs off the computer, this cache will be erased. Don must import the private key from the floppy disk before he can decrypt any files encrypted with that private key. Importing a private key from a saved file is extremely simple:

1. Insert the floppy disk in the disk drive.

2. Click Start, click My Computer, then double-click the floppy drive.

3. Double-click the file saved earlier to import the private key.

4. Enter the password when prompted.

I frequently refer to the use of a floppy disk throughout the book. This is because the floppy drive is the most universal removable media device available and has been installed in computers as standard equipment for decades. However, floppy disks can go bad over time or with minimal abuse. Many other portable storage solutions ”such as USB key drives, memory cards, and rewritable CDs ”are available. In many cases, these removable solutions will work exactly the same as a floppy disk. When a floppy disk is specifically required, a note will be added to indicate that fact.

4.2.7 Example: Using cipher.exe to Remove Old Unencrypted Data

In our example, Don creates the folder for his encrypted data and marks it for encryption before any data is actually created. However, this may not always be possible. He may want the same level of protection for the data that he has already saved on his hard disk. He can follow the previous steps to mark a folder as encrypted and remove the private key. He would then drag files into the folder and they would become encrypted. However, because the files were previously stored as unencrypted on the hard disk, portions of those files may still exist unencrypted on the disk. Those file portions are often called data remnants . And although this data would not be easy to retrieve, a dedicated attacker with sophisticated equipment could do so.

To avoid data remnants on the disk for an indeterminant period, the disk should be wiped clean of unused data. This process, while fairly lengthy, can ensure that current technology cannot recover the old unencrypted data remnants. The procedure can be done by following these steps:

1. Click Start All Programs Accessories Command Prompt.

2. 1. Right-click on an encrypted file in his encrypted folder and choose Properties.

   2. Click Advanced.

   3. Click Details.

   4. The data recovery agents are identified in the list labeled "Data recovery agents for this file as defined by recovery policy," as shown in Figure 4-11.

   Figure 4-11. Administrator is the data recovery agent for this file

   
   

   If any of the private keys for the listed recovery agent(s) are on the local computer, they should be removed using the procedure described earlier in this chapter.

   How cipher /w Works

   The cipher /w command, also known as the wipe command, is one of the most powerful security features in Windows Server 2003. In many cases, it can mean the difference between an unsuccessful attack and having otherwise -well-protected data compromised.

   When the wipe command is called, cipher obtains a list of unused hard drive sectors from NTFS. It then goes to the first sector in the list and performs the following actions:

   1. Writes all zeros

   2. Writes all ones

   3. Requests a pseudorandom number from the Cryptographic API (CAPI)

   4. Writes the pseudorandom number

   cipher then moves to the next sector in the list and repeats the set of wipe actions. Once all sectors on the list are written in such a fashion, cipher requests a list of unused NTFS metadata sectors ( metadata is the set of files that NTFS uses internally to manage the file system). The wipe operation is then performed on each unused NTFS metadata sector.

   Because of the extensive amount of work done by the wipe operation, it takes a very long time to complete. Unfortunately, NTFS is operating the entire time the wipe operation is being performed. During this time, sectors can be used or released by NTFS, thereby changing the list without informing cipher . In addition, some small files may reside entirely within NTFS metadata sectors and therefore may not be entirely eradicated by the wipe operation.

   The best solution to this situation is to ensure that files are created in an encrypted state and are never written to the hard drive as plain text. Wiping the hard drive will almost certainly remove plain text slack from previously encrypted files, but it is not guaranteed .

   
   

   4.2.8 Example: Storing Shared Encrypted Files on a Windows Server 2003 File Server

   EFS is primarily designed to encrypt local files. However, files stored on a file server can also be encrypted. Windows Server 2003 supports two methods of file sharing that can be used with EFS ”the classic SMB file sharing and WebDAV file sharing. This complements file permissions on the remotely stored files and ensures that even with server compromise, only individuals with the appropriate private key can decrypt the files.

   

   Remember that EFS works in conjunction with NTFS. When using a normal file share to save or open files, the NTFS operations are done at the file server. This means that all encryption and decryption of EFS files is done by the file server. The data on the network between your computer and the file server is not protected by EFS. To ensure true end-to-end security of your data, you must protect the data as it travels on the network. IP Security (IPSec) is a great way to do that and is the topic of discussion in Chapter 8.

   
   

   David wants to save some files in a place where both he and Don can access them. He applies NTFS file permissions to these files and their parent directory. However, David is aware that many administrators have access to the file server. Because the data is extremely sensitive, David wants to ensure that even in the event of compromise of the file server, only he and Don can access the files. David also wants to ensure the availability and redundancy of the data, both of which are provided by a well-managed and - maintained file server.

   To configure EFS to allow only himself and Don to access the files on a file share, David can take the following steps:

   1. Contact the file server administrator and request access to a file share.

   2. Map a drive letter to the file share.

   3. Create a new subfolder on the file share or identify an existing folder to contain the protected data.

   4. Apply file permissions to the folder as described earlier in this chapter. Ensure that only he and Don have access to the folder and files.

   5. Right-click on each file and choose Properties.

   6. Click Advanced.

   7. Click Details.

   8. Because David is the creator of the folder and file, he already exists as a valid user. To add Don to the list of users able to decrypt this file, click Add.

   9. Select Don's EFS certificate from the list, or click Find User to browse Active Directory for Don's certificate. The former requires that Don's certificate was imported to this computer, and the latter requires a CA configured to publish issued certificates to Active Directory.

   Because of the way EFS encrypts the FEK with the user's public key, Don does not share his private key with David. David can add any user whose public key certificate he can access, as long as that public key is configured to support EFS. When a user attempts to access the file, she must provide her private key, securely, to the file server. This is because the decryption occurs at the file server. Because this obviously assumes a high level of trust for the file server, any file server that will work with EFS must be configured within Active Directory as trusted for delegation. For more information about trusting a computer for delegation, see Chapter 7.

   4.2.9 Configuring EFS with Group Policy

   As discussed earlier, EFS works well without any administrative control. EFS can request a self-signed certificate and private key and is configured to work well with default settings. However, to provide centralized management and configuration, a number of settings can be configured. These settings determine whether EFS is enabled on the computer as well as identify the EFS recovery agent and the encryption algorithm used by EFS. All these settings are configured by Group Policy.

   Don wants to ensure that a specific certificate is used as the recovery agent and that EFS uses the AES algorithm for file encryption. He also requires that users in the Interns organizational unit be unable to use EFS to encrypt their data. To stop the Interns users from using EFS, he configures a Group Policy Object (GPO) on the Interns OU, using the following steps:

   1. Log on to a domain controller or a computer that has the Windows Server 2003 Administration Tools Pack installed as a Domain Admin.

   2. Click Start All Programs Administration Tools Active Directory Users and Computers.

   3. Right-click the Interns OU and click Properties.

   4. Click the Group Policy tab.

   5. Click New and name the new policy EFS Lockout.

   6. Click Edit to edit the EFS Lockout GPO.

   7. Expand Computer Configuration Windows Settings Security Settings Public Key Policies Encrypting File System.

   8. Clear the checkbox for "Allow users to encrypt files using Encrypting File System (EFS)."

   This policy will be applied to all interns and ensure that they do not encrypt files on their local hard drive. Because it is applied at the OU that contains the actual user and computer accounts, these policies will be enforced. For more information on how Group Policy applies to users and computers, see Chapter 5.

   For the rest of the users in the domain, Don wants to configure them to use EFS properly as discussed earlier. He modifies the Default Domain Policy to correctly configure EFS using the following steps:

   1. Log on to a domain controller or a computer that has the Administrative Tools Pack installed as a Domain Admin.

   2. Click Start All Programs Administrative Tools Active Directory Users and Computers.

   3. Right-click the domain name and click Properties.

   4. Click the Group Policy tab.

   5. Click New and name the new policy EFS Configuration.

   6. Click Edit to edit the EFS Configuration GPO.

   7. Expand Computer Configuration Windows Settings Security Settings Public Key Policies Encrypting File System.

   8. Provide the public key certificate of the desired recovery agent.

   9. Expand Computer Configuration Windows Settings Security Settings Local Policies Security Options.

   10. Check Define This Policy Setting and choose Disabled.

   These two policy settings will configure EFS with the desired recovery agent and configure it to use the AES encryption algorithm. Note that the algorithm policy setting may seem a bit backward in that you disable FIPS-compliant algorithms. In this case, the FIPS-compliant algorithm included with Windows XP and Windows Server 2003 is triple-DES. When the non-FIPS algorithm is selected, the strongest algorithm EFS supports is used. In Windows Server 2003 and Windows XP Service Pack 1 or later, that is the AES algorithm.

   Don has now configured EFS for proper use within Woodgrove Bank. For some users, EFS is disabled entirely. For others, EFS is configured to use the strong AES algorithm and use a specific certificate as a recovery agent. This allows Don to be confident that EFS is being used consistently and securely, and that he can recover sensitive files when required.