Access Denied: Using EFS with and Without AD

I installed Windows 2000 on my C drive. Using the default Administrator account, I encrypted and locked down the permissions of a directory and all its subdirectories on my D drive. When I had to reinstall Win2K, I installed it to win2k rather than to the default \winnt. Now, when I try to copy or open any of the files in the encrypted directory, I get an Access denied message. Because I can see all the files under the directory, I think it's an Encrypting File System (EFS) problem rather than a permissions problem. I haven't tried deleting the encrypted subdirectory yet, but as a last resort, I will. I can restore most of the encrypted directory, so the situation isn't critical, but the problem is intriguing. How can I address the problem this time and avoid it in the future?

You're right that the way EFS works is keeping you from restoring the encrypted directory. From your description, I can tell that you're using the local Administrator account instead of an Active Directory (AD) domain account. You can access an encrypted file only if you're the user who encrypted it or the recovery agent (the recovery agent defaults to the Administrator account). Because you installed a second copy of Win2K, the Administrator account you used to log on is different from the Administrator account you used to encrypt the file (the account name is the same, but the SID is different). Each copy of Win2K has a separate SAM with a unique set of user accounts, including the built-in Administrator account.

The restoration issue you've encountered is just one of several issues that arise when you use EFS with local user accounts instead of AD domain accounts. If your computer is a member of an AD domain and you encrypt a file as an AD domain account, you can still access that file after you reinstall the OS—if you use roaming profiles. Domain users' EFS certificates and private keys are stored in their profiles (which are in the registry's HKEY_ CURRENT_USER subtree). If you use roaming profiles, your profile is stored on a server and survives workstation reinstallations. Unfortunately, many organizations haven't yet implemented AD and are rolling out Win2K Professional without an AD domain—yet they still hope to use Win2K security features, such as EFS.

EFS works without AD, but as you can see, it doesn't work as well. In fact, EFS is much more vulnerable to attack on computers that aren't members of a domain because intruder tools such as Petter Nordahl Software's ntPassword let you reset local user account passwords stored in the computer's SAM. For more information, see "Securing Win2K Laptops with EFS" (http://www .secadministrator.com, InstantDoc ID 15741). If you can log on as that user, you can access the user's encrypted files. Regardless of whether you've implemented AD, before you implement EFS, make sure you understand and follow the best practices that Win2K's Help text recommends.