January 04, 2006 () -- Microsoft's Encrypting File System, which is used to encrypt data on Windows 2000, XP and Server 2003 computers, relies on a public key certificate. If you don't have a public-key infrastructure, EFS can use a self-signed certificate. This is the default for using EFS on a standalone or workgroup computer. Implementing EFS within a domain with a PKI presents more complexity. In this article, we'll look at how to manage and use EFS in a Windows 2000 or Server 2003 domain. EFS and digital certificates
In order to encrypt files and folders with EFS, a user must have a valid X.509 certificate. When a user attempts to encrypt data, EFS looks in the user's personal certificate store for an EFS certificate. If it doesn't find one, it attempts to enroll you for an EFS certificate with a Windows certification authority. If you're not using a domain account or if it is unable to request a certificate through a certification authority, EFS generates a self-signed certificate. However, there are problems inherent in using self-signed certificates:
Unlike a certificate issued by a trusted third party like a CA, a self-signed certificate signifies only self-trust. It's sort of like relying on an ID card created by its bearer, rather than a government-issued card. Since encrypted files aren't shared with anyone else, this isn't really as much of a problem as it might at first appear, but it's not the only problem.
If the self-signed certificate's key becomes corrupted or gets deleted, the files that have been encrypted with it can't be decrypted. The user can't request a new certificate as he could do with a CA.
Note: Because of the danger of data loss in the wake of a lost or corrupted key, you should ensure that all users export their private keys and maintain a copy offline (password protected for security). For better security, you can delete the key from the local system after exporting it. When the key is maintained on the system, an attacker who cracks the user's password will be able to decrypt the user's encrypted files. If the key is kept offline, the encrypted files will still be safe in this scenario, although it may present some inconvenience to users to have to import the key each time they want to decrypt their data. EFS and the PKI
Although self-signed certificates can be used in a domain, the best practice is to only use EFS in a PKI environment. A Windows 2000 or 2003 server can be configured as a certification authority with the certificate services built into the operating system. You can integrate the CA with Active Directory to automate the process of requesting certificates.
Enterprise CAs issue certificates that are based on certificate templates. The templates are stored in Active Directory. They define the attributes of certificates to be issued to users or computers. You can set permissions on certificate templates if you want to prevent some users from obtaining EFS certificates. You may have certain groups of users whom you don't want to be able to encrypt their data. In that case, you can deny those users Enroll permission on the template and they'll be unable to obtain an EFS certificate. Users who have enroll permission can request an EFS certificate from the CA using the Certificates MMC snap-in.
It is also possible to use third-party certificates (issued by a CA other than a Windows certificate server) for EFS. The certificates must be compliant with Personal Information Exchange (PKCS #12) and must meet several requirements. The third-party CA may have to be configured to issue certificates that meet these requirements. For more information about using third-party certificates, see KB article 273856 . 'Moving on up' to a PKI
If you have implemented EFS in an environment that doesn't have a CA, and then you deploy a PKI, you will need to explicitly replace the self-signed certificates that users had been using with CA-issued certificates. Even if the CA issues them a new certificate, by default the self-signed certificate will continue to be used until the user archives the self-signed certificate and requests a new CA-issued certificate by using the cipher command with the /k switch. EFS in a Domain
Within a Windows forest, users can store encrypted files on remote servers. The remote files must be stored in either network shares or WebDAV folders. To encrypt remote files in a share, the remote server must be trusted for delegation before users can encrypt files on the remote server. This is done via the Active Directory Users and Computers tool. See this article from Microsoft TechNet for instructions. Then, to encrypt a file on the remote server, you need to map a network drive. Remotely encrypting files using a share can only be done in a domain because EFS must use Kerberos delegation to impersonate the user.
It's important to note that EFS only encrypts data when it's stored on the disk. It does not encrypt data during transmission over the network. For that purpose, you can use IPsec. Also, if you encrypt a file and then copy or move it to a WebDAV folder, it stays encrypted while in transit. Problems with EFS in a domain
There are some potential problems you should be aware of before implementing EFS in a domain. For example, a user only has to have NTFS modify (write) permission to a file to be able to encrypt it. This means that if multiple users have permission to access a file, one of them could encrypt it and make it inaccessible to the others. Note: One change in EFS for Windows XP/2003, as compared to Windows 2000, is that encrypted files can be shared among multiple users. All users who share the encrypted file must have an EFS certificate on the computer on which it's stored.
The EFS domain recovery agent certificate is stored by default on the first domain controller in the domain. It's important to remember this if you're considering demoting the DC or if it is in danger of crashing. You should export the private key to avoid a situation where you are unable to decrypt the files if a user's account is deleted.
The Data Protection API (DPAPI) protects EFS private keys, along with other private credentials in Windows 2000/XP/2003. If a user changes the domain password over a remote access dial-up or VPN connection, the DPAPI master key may not be replicated immediately to all domain controllers. This can cause the user to get an Access Denied message when trying to access local encrypted files after making the password change. You can solve this problem by creating a registry value named ProtectionPolicy in
HKLM\SOFTWARE\Microsoft\Cryptography\Protect\Providers\df9d8cd0-1501-11d1-8c7a-00c04fc297eb.
Set the value to 1. Warning: This registry modification will allow the user to access encrypted files after a remote access password change, but it can also expose the user's account to the threat of attack.
When implementing EFS in a domain, by default the Administrator of the first domain controller is the recovery agent. You should create new recovery agent accounts and remove the recovery agent role from the Administrator account. The recovery agent account(s) should be used only for that purpose.
If a computer was previously a standalone system and then joins a domain that uses a CA to issue EFS certificates, you might not be able to open files that were encrypted with a self-signed certificate prior to joining the domain. You can access these files by logging off the domain and logging back onto the local computer. Increasing EFS security
You can make EFS more secure on Windows XP and Server 2003 systems by configuring EFS to use the 3DES encryption algorithm instead of DESX, the default. You can enable 3DES using Group Policy; this will cause both EFS and IPsec to use 3DES. If you want to use 3DES only for EFS, you have to edit the registry and create a new DWORD value named AlgorithmID in
Set the value data to 0x6603 (hex) to enable 3DES for EFS and restart the computer to make the setting take effect.
Note: Windows 2000 does not support using 3DES for EFS out of the box. However, you can use 3DES with Windows 2000 if you have installed the High Encryption Pack. You can download the High Encryption Pack from the Microsoft Web site.
You should also be aware of EFS security issues. For example, many applications create temporary files when you're working. These temp files may not be encrypted. You can fix this by encrypting the folder in which the application stores its temp files; then files placed in that folder will automatically be encrypted.
Also be aware that an application may copy the contents of an encrypted file to the paging file during use. The paging file can't be encrypted because it's a system file. Data can remain in the paging file even after the application closes the file, and an unauthorized person could start the computer with a different operating system and read the contents of the paging file. To prevent this, you can configure the local Group Policy to clear the contents of the paging file at shutdown. This is done by enabling the Shutdown: Clear Virtual Memory Pagefile policy under Computer Configuration | Windows Settings | Security Settings | Local Policies | Security Options.
Debra Littlejohn Shinder, MCSE, MVP (Security) is a technology consultant, trainer and writer who has authored a number of books on computer operating systems, networking, and security. She is also a tech editor, developmental editor and contributor to more than 20 additional books. Her articles are regularly published on TechRepublic's TechProGuild Web site and Windowsecurity.com, and have appeared in print magazines such as Windows IT Pro (formerly Windows & .NET) magazine. She has authored training materials, corporate white papers, marketing material and product documentation for Microsoft Corp., Hewlett-Packard, DigitalThink, GFI Software, Sunbelt Software, CNET and other technology companies. She lives and works in the Dallas-Fort Worth area and can be reached at deb@shinder.net or at www.shinder.net.
"This company's infrastructure group is running a disaster recovery exercise with a reluctant participant: an IT manager who's notorious as..."
Read more...
"It's IT Blogwatch: in which Mozilla's Firefox Web browser continues to gain market share, smashing records as it does so...."
Read more... Read more Security posts or See all Blogs
Is Microsoft's Golden Age over? What are Gates' most memorable quotes? Find out in Computerworld's complete coverage of the end of the Bill Gates era at Microsoft.
Why SaaS is Vital to Email and Web Security
Download this webcast, free, compilments of Webroot Software
Go to the webcast
Computerworld Executive Bulletin: Building a Robust Antivirus Defense
Download this Executive Bulletin (a $49.95 value) for free, compliments of MessageLabs. (Source: MessageLabs) Antivirus software alone isn't enough to prevent today's speedy, sophisticated virus attacks. Security managers should consider multitiered approaches that include behavior scanning, appliances that check e-mail for worms, and restricting user access to dangerous Web sites. Download this Executive Bulletin (a $49.95 value) for free, compliments of MessageLabs, to learn more.
Download this executive briefing
Eliminate SPAM, Gain Productivity
Get this white paper now! (Source: MessageLabs) Learn all about the dangers and the costs of spam in all its forms - from stock-touting to spreadsheet. Also, understand the drawbacks of traditional hardware- and software-based defenses - and the unique benefits of MessageLabs multi-layered, managed Anti-Spam solution; as illustrated by a real-world case study where MessageLabs stopped spam cold.
Download this white paper
White Papers
Read up on the latest ideas and technologies from companies that sell hardware, software and services.
Security Management Zone
Security management is the process of developing a comprehensive data protection plan. It takes into account all potential threats, the existing network environment, the future needs of the organization, and lays out a multi-tiered blueprint to integrate the security technology needed to combat these threats. CDW can help keep your network and data secure.
Visit the CDW Security Management Zone nowSee All Zones
Fired up about IT?Join Sharkbait and share your true tales of IT. SharkBait is the place for you to sound off about everything IT the good, the bad, and the rest of the weird stuff you deal with every day.
New baits
"Security Directions" virtual trade show
2008's Code-Red Security Issues for Protecting the Enterprise
Webcasts, white papers, demos, and more. Presented in a unique 3-d environment.