Congratulations to last month's winners of the Windows 2000 Pro UPDATE Reader Challenge. Joe Morris of Virginia, United States, wins a copy of "Admin911:Group Policy" by best-selling Win2K expert Roger Jennings. Oliver O'Boyle of Northwest Territory, Canada, wins a copy of my own book, "Admin911: Windows 2000 Registry." Both books are published by Osborne/McGraw-Hill and are supported with files and articles at this Web site.
Some answers I received were delightfully creative, and, unfortunately, some of the best answers didn't contain a name and address (as instructed in the Challenge). The winners were selected at random from a group of great answers.
The Problem
Patti Paranoia does everything right when protecting the files on her Windows 2000 Professional workstation. She saves her business data files on file servers throughout the network and saves her personal files locally. Every night, before she leaves the office, she backs up all her local data files to a company server, which in turn is backed up to tape. The folder that holds her local files is configured for Encrypting File System (EFS) so nobody can pry into her business.
Patti's company runs a Windows NT 4.0 domain. The file servers that Patti has access to are running Win2K Server with NTFS. The company has upgraded all the workstations to Win2K Pro running NTFS. Only the domain controllers (DCs) are still running NT 4.0 (but as soon as everyone's happy with the design for Active Directory—AD—, the company will migrate to a Win2K domain).
Yesterday, Patti's hard disk died. The IT team installed a new disk, installed Win2K Pro running NTFS, and installed all the applications she previously had on the disk. She launched the company database system and word processor, and everything worked perfectly. Hooray for well-designed systems.
Then Patti copied the folders that held her personal files from the server to her workstation. Uh oh. She couldn't open her files. She called the Help Desk and explained her predicament. Here's the short (and polite) version of the IT pro's response: "You did what? Why? Why didn't you ask us before you did that so we could prepare for disaster. Sorry, too late, we can't help you." Poor Patti. All those resumes, letters to head hunters, letters to Mom, and other personal epistles are out of reach.
Your challenge is to tell me why Patti can't open her files. You must also tell me what the IT professional meant when he hinted that the disaster could have been prevented. How could Patti have prepared for the eventuality of a new installation that would let her recover her EFS-protected folders? You have all the clues you need within this article.
The Solution
Patti Paranoia couldn't open her encrypted files after the administrator restored those files to a new hard disk because the new disk didn't contain the private key half of the Encrypting File System (EFS) public key/private key encryption algorithm. The EFS public key performs the encryption, and the EFS private key performs the decryption. If the private key isn't available, you can't open the file.
Because Patti's Win2K Pro computer wasn't part of a Win2K domain, the administrator couldn't designate EFS recovery agents for the domain. Therefore, Win2K Pro automatically named the Administrator account on Patti's computer the recovery agent.
As soon as Patti decided to use EFS, she should have exported the private key to a removable disk or a network sharepoint, so she could import it back to her computer in case of a hard disk disaster.
To export the private key, log on to the local computer with the Administrator account. (Logging on to the local computer with a user account that has administrative rights doesn't work). An IT professional will most likely have to perform this task because it's unusual to give users the password to the computer's Administrator account.
Open the Run command and type secpol.msc, and click OK. The Microsoft Management Console (MMC) Local Security Settings snap-in opens. Expand the Public Key Policies object in the left pane. Then select the Encrypted Data Recovery Agents object in the left pane, which displays its contents in the right pane. The contents are certificates, and the right pane displays the certificate that was issued to the computer's Administrator account for the purpose of recovering encrypted files.
Right-click the Administrator's certificate listing, and choose All Tasks, Export from the shortcut menu. The Certificate Export Wizard appears to walk you through the steps. Click Next on the Welcome window to begin.
Make certain you've selected the option Yes, export the private key, and click Next to move to the Export File Format window. Select Personal Information Exchange as the format, and make sure the Enable strong protection check box has a check mark.
In the next window, enter and confirm a password for this file. In the Save As dialog box, name the file (it needs the file extension .pfx). It's best to export the file to a disk, and put the disk in a safe place.
The wizard displays the settings you've selected. Click Finish if everything seems correct (click Back to make any necessary changes). The system copies the file and displays a success message.
To import the key onto the new hard disk, the user must get the password for the export file, and log on to the local computer. If the administrator who knows the password doesn't want to give it out, that administrator must log on to the computer to restore the key.
Put the disk containing the export file into the drive and open My Computer or Windows Explorer. Right-click the file listing and choose Install PFX from the shortcut menu.
The Certificate Import Wizard opens and walks you through the steps for importing the key. Accept the default settings and enter the password when prompted.
