[转载]Implementing EFS in a Windows Server 2003 Domain
原始连接：[url]http://www.windowsecurity.com/articles/Implementing-EFS-Windows-Server-2003-Domain.html[/url]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抯 personal certificate store for an EFS certificate. If it doesn抰 find one, it attempts to enroll you for an EFS certificate with a Windows certification authority. If you抮e not using a domain account or if it is unable to request a certificate through a CA, 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 (CA), a self-signed certificate signifies only self-trust. It抯 sort of like relying on an ID card created by its bearer, rather than a government-issued card. Since encrypted files aren抰 shared with anyone else, this isn抰 really as much of a problem as it might at first appear, but it抯 not the only problem.
If the self-signed certificate抯 key becomes corrupted or gets deleted, the files that have been encrypted with it can抰 be decrypted. The user can抰 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抯 password will be able to decrypt the user抯 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抰 want to be able to encrypt their data. In that case, you can deny those users Enroll permission on the template and they抣l 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 Personal Information Exchange (PKCS #12) compliant 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 at [url]http://support.microsoft.com/default.aspx?scid=kb;en-us;273856&sd=tech.[/url]
揗oving on up?to a PKI
If you have implemented EFS in an environment that doesn抰 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 [url]http://www.microsoft.com/technet/prodtechnol/windowsserver2003/library/ServerHelp/b742ce99-e53a-4bce-8bc5-f3f3fa89af9d.mspx[/url] 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抯 important to note that EFS only encrypts data when it抯 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抯 stored.
The EFS domain recovery agent certificate is stored by default on the first domain controller in the domain. It抯 important to remember this if you抮e 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抯 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 dialup 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抯 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
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\EFS
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 at [url]http://www.microsoft.com/windows2000/downloads/recommended/encryption/[/url]
You should also be aware of EFS security issues. For example, many applications create temporary files when you抮e 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抰 be encrypted because it抯 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.
About Deb Shinder
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 over 20 additional books. Her articles are regularly published on TechRepublic抯 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 material, corporate whitepapers, marketing material, and product documentation for Microsoft Corporation, Hewlett-Packard, DigitalThink, GFI Software, Sunbelt Software, CNET and other technology companies. Deb lives and works in the Dallas-Ft Worth area and can be contacted at [email]deb@shinder.net[/email] or via the website at [url]www.shinder.net[/url]
Click here for Deb Shinder's section.
页:
[1]