Encrypting Server-Based Files
File encryption and decryption requires the local presence of EFS keys at the machine where the files reside. This makes encrypting files on servers a little more difficult than you might first expect.
As we've seen several times, when a user encrypts a file on a local desktop or laptop, EFS works with the Microsoft Crypto Provider to create EFS keys and to place those keys in the user's local profile. If the user reaches out across the network to encrypt a file, EFS running at the server looks for the user's local profile at the server. EFS cannot access keys at a user's desktop because it does not have a security context anywhere except at the machine where it's running.
This means that the server must have a local profile for the user that contains both the EFS public key to encrypt the file and the EFS private key to open the encrypted file. To build the local private key, the Protected Storage service at the server must have a copy of the user's password hash so it can encrypt the Master key that protects the user's private key. It obtains this information by "impersonating" the user.
Impersonation and Kerberos
User impersonation by a server for purposes of EFS requires obtaining a Kerberos session ticket on behalf of the user to present when requesting the user's security credentials from a domain controller. A server has two ways of getting this session ticket:
It can ask the Kerberos client at the user's desktop (this is done transparently to the user) to obtain the session ticket and pass it over to the server. Such a ticket would be marked as forwardable, meaning that the Kerberos client obtained it for the express purpose of giving it to another machine.
The server can ask the Kerberos client for a ticket-granting ticket (TGT) that it can use to obtain its own session tickets as if the server were the user. The TGT would be flagged as proxiable.
The difference between a forwardable session ticket and a proxiable TGT is the difference between loaning a friend twenty dollars to pay for lunch and giving that friend a power of attorney and your checkbook. A server in possession of either one is in a position to do all sorts of mischief.
To prevent uncontrolled use of forwardable and proxiable Kerberos tickets and TGTs, a Windows domain controller will refuse to accept such tickets or TGTs unless the server submitting them has been Trusted For Delegation.
Trusted for Delegation
Before a server can create encrypted files for network users, it must be trusted for delegation. This option is configured in the server's Computer object in Active Directory. Figure 17.10 shows an example.
Figure 17.10. Property page for a server showing the various Trusted for Delegation options.
Windows Server 2003 has several delegation options. For the widest latitude, and to ensure that you get proper operation for EFS, select the Trust This Computer For Delegation To Any Service (Kerberos Only) option. The other options permit you to enable delegation for a tightly focused type of transaction.
After you configure a server to be trusted for delegation, it occupies a highly privileged position in your system. Be sure to physically secure the server and keep it away from possible sources of Trojan horse applications.
When you enable Windows Server 2003 to be trusted for delegation and users begin putting encrypted files on that server, the server will improve EFS performance by caching user private keys in memory. By default, the server will cache up to 15 keys. You can increase this number up to 30 using the following Registry value:
Key: HKLM | SOFTWARE | Microsoft | Windows NT |
CurrentVersion | EF
Data: 5 to 30 (REG_DWORD)