Microsoft Windows XP Professional Resource Kit 2003
ISBN: N/A
EAN: N/A
EAN: N/A
Year: 2005
Pages: 338
Pages: 338
Users can encrypt and decrypt files that are stored on network file shares or on Web Distributed Authoring and Versioning (WebDAV) Web folders. Web folders have many advantages compared to file shares, and Microsoft recommends the use of Web folders whenever possible for remote storage of encrypted files. Web folders require less administrative effort and are more secure than file shares. Web folders can also securely store and deliver encrypted files over the Internet by using standard HTTP file transfers. Using file shares for remote EFS operations requires a Windows 2000 or later domain environment because EFS must impersonate the user by using Kerberos delegation to encrypt or decrypt files for the user.
The primary difference between remote EFS operations on files stored on file shares and files stored on Web folders is where the operations occur. When files are stored on file shares, all EFS operations occur on the computer on which the files are stored. For example, if a user connects to a network file share and chooses to open a file that he or she previously encrypted, the file is decrypted on the computer on which the file is stored and then transmitted in plaintext over the network to the user s computer. When files are stored on Web folders, all EFS operations occur on the user s local computer. For example, if a user connects to a Web folder and chooses to open a file that he or she previously encrypted, the file remains encrypted during transmission to the user s computer and is decrypted by EFS on the user s computer. This difference in where EFS operations occur also explains why file shares require more administrative configuration than Web folders.
Remote EFS operations on files stored on network file shares are possible in Windows 2000 or later domain environments only. Domain users can remotely encrypt or decrypt files, but this capability is not enabled by default. The following are requirements for successful remote EFS operations in a file share environment:
The files to be encrypted must be available to the user through a network share. Normal share-level security applies.
The user must have Write or Modify permissions to encrypt or decrypt a file.
The user must have either a local profile on the computer where EFS operations will occur or a roaming profile. If the user does not have a local profile on the remote computer or a roaming profile, EFS creates a local profile for the user on the remote computer.
If the remote computer is a server in a cluster, the user must have a roaming profile.
To encrypt a file, the user must have a valid EFS certificate. If EFS cannot locate a pre-existing certificate, EFS contacts a trusted enterprise certification authority for a certificate. If no trusted enterprise certification authorities are known, a self-signed certificate is created and used. The certificate and keys are stored in the user s profile on the remote computer or in the user s roaming profile if available.
| Note | In order to verify a certificate s authenticity, a certification authority signs the certificates that it issues with its private key. EFS creates and uses a self-signed certificate if no file encryption certificate is available from a certification authority. A self-signed certificate indicates that the issuer and subject in the certificate are identical, and that no certification authority has signed the certificate. |
To decrypt a file, the user s profile must contain the private key associated with the public key used to encrypt the FEK.
EFS must impersonate the user to obtain access to the necessary public or private key. This requires the following:
The computer must be a domain member in a domain that uses Kerberos authentication because impersonation relies on Kerberos authentication and delegation.
The computer must be trusted for delegation.
The user must be logged on with a domain account that can be delegated.
| Note | Use the Active Directory Users and Computers snap-in to configure delegation options for both users and computers. To trust a computer for delegation, open the computer s Properties sheet, and select Trusted for delegation. To allow a user account to be delegated, open the user s Properties sheet. On the Account tab, under Account Options, clear the The account is sensitive and cannot be delegated check box. Do not select The account is trusted for delegation. This property is not used with EFS. |
Remote decryption is a potential security risk because files are decrypted prior to transmission and are transmitted unencrypted. EFS decrypts the file on the computer that stores the encrypted file, and the data is then transmitted over the network in plaintext. Organizations need to consider whether this level of risk is acceptable. You can greatly reduce or eliminate this risk by enabling IP Security to use Encapsulating Security Payload (ESP), which will encrypt transmitted data, enabling another network layer security protocol, or by using Web folders. For more information about configuring IP Security, see Internet Protocol Security in the TCP/IP Core Networking Guide of the Microsoft Windows 2000 Server Resource Kit.
Encrypting files and then encrypting the user s FEK by using the user s public key requires access to the user s EFS certificate. If the user is encrypting a file stored on the computer at which he or she is logged on, EFS uses the existing EFS certificate, obtains a certificate from an enterprise certification authority (CA), or creates a self-signed certificate.
If the user is encrypting a file on a remote computer, EFS must first impersonate the user by using Kerberos delegation. If this impersonation is successful, EFS determines whether the user has a roaming profile and/or a local profile. If the user has a roaming profile, EFS loads it. If not, EFS loads the local profile, if one is available. If no profile can be located, EFS creates one for the user.
EFS looks for a valid EFS certificate and its associated private key in the user s profile. If no certificate exists, or if the profile contains a certificate but not the associated private key, EFS attempts to locate a trusted enterprise CA and obtain an EFS certificate for the user. As part of this attempt, EFS generates a public-private key pair. If a trusted enterprise CA can be contacted, EFS requests a certificate. If a certificate cannot be obtained from a CA, EFS self-signs a certificate.
After EFS has a user profile and a valid certificate, an FEK is created and used to encrypt the file s data. The public key is then used to encrypt the FEK, and the encrypted FEK is stored in the file header.
If EFS creates a public-private key pair, both keys are stored in the user s profile on the remote computer.
To decrypt a file, EFS must first obtain the user s private key. More specifically, EFS needs the private key associated with the public key used to encrypt the file s FEK. EFS uses the private key to decrypt the FEK and then uses the FEK to decrypt the file. The private key is stored in the user s profile. Before decrypting the file, EFS must:
Locate the user s profile. The user is not currently logged on at the remote computer where the decrypting is taking place, so EFS impersonates the user. The user might have a local profile or a roaming profile.
Find the appropriate private key. When a profile is located, EFS checks any private keys contained in the profile for a match with the public key that encrypted the FEK.
| Note | Public-private key pairs share a thumbprint value, a unique hash value stored with each key. |
Decrypt the FEK. If the user profile contains the correct private key, EFS uses it to decrypt the FEK.
When EFS decrypts a file on the computer at which the user is logged on, the user is already accessing his or her user profile. When the user attempts to decrypt a remote file, however, EFS needs to impersonate the user in order to get access to the user s profile, in which the user s private keys are stored. This requires the computer to be trusted for delegation.
In a remote decryption scenario, then, EFS determines if the computer has been trusted for delegation. If not, the decryption process fails.
The user account must also not be designated as a sensitive account that cannot be delegated. Domain administrator accounts, for example, are flagged as non-forwardable (identity cannot be delegated). Any account that cannot be delegated cannot use EFS remotely.
If the computer is trusted for delegation and the user account that EFS needs to impersonate can be delegated, EFS can next locate the user s profile. The process is similar to that used after a new key pair has been generated and the private key needs storage. EFS looks for a local profile and a roaming profile, and uses the roaming profile if it exists. If the user does not have a local or a roaming profile, the decryption process fails. EFS cannot create a user profile in this situation because it needs the existing private key (and thus the profile in which it is stored) to decrypt the FEK.
If a user profile is located, EFS looks for a private key to match the public key used to encrypt the FEK. If found, the private key is used to decrypt the FEK, and file decryption can begin. If the private key is not found, the decryption process fails.
When the FEK is decrypted and used to decrypt the file, the data is ready to be transmitted in plaintext across the network.
Note that an attacker can use network monitoring software to access the plaintext data as it is transmitted over the network. You can prevent this by using IP Security with ESP and encryption to secure data as it is transmitted, or by storing encrypted files on Web folders.
Encrypted files and folders can be renamed, copied, or moved. Renaming an encrypted file or folder either locally or remotely does not cause decryption. However, moving or copying a file or folder can result in decryption. The effects of moving or copying encrypted files and folders vary according to whether the files or folders are moved or copied locally or remotely.
For more information about renaming, copying, or moving encrypted files and folders, see WindowsXP Professional Help and Support Center.
Encrypted files or folders retain their encryption after being either copied or moved, either by using My Computer or by using command-line tools, to local volumes, provided that the target volume uses the version of NTFS used in Windows 2000 or later. Otherwise, encrypted files are stored as plaintext, and encrypted folders lose the encryption attribute.
| Note | Most floppy disk drives are FAT volumes, so encryption is lost when files are copied to disk unless the files are backed up by using the Backup tool before they are copied. Encrypted files that are copied or moved to servers or workstations running Microsoft Windows NT 4.0 also lose their encryption. |
When plaintext files are copied or moved in My Computer to an encrypted folder on a local NTFS volume, they are encrypted. Plaintext files are also encrypted if they are copied to an encrypted folder on a local volume by using the copy or xcopy commands.
The move command produces different results if the plaintext file is moved to an encrypted folder on the same volume or on a different local volume. If the move command is used to move a plaintext file to an encrypted folder on the same volume, the file remains in plaintext. This is because the move command simply renames the file, unless the file is moved to a different volume. If the file is moved to an encrypted folder on a different local volume, it is encrypted.
Renaming plaintext files that are in encrypted folders produces different results at the command line and in My Computer. If a plaintext file in an encrypted folder is renamed in My Computer, the resulting file is encrypted. If the file is renamed by using the ren command, it remains in plaintext.
When encrypted files or folders are copied or moved to or from a network file share on a remote computer, the files are decrypted locally, transmitted in plaintext, and then re-encrypted on the target volume if possible. Encrypted files transmitted to or from Web folders remain encrypted during transmission. With remote file operations, EFS must impersonate the encryptor, so the encryptor s account must be configured to enable delegation, and the remote computer must be trusted for delegation. EFS makes use of either an existing EFS certificate for the encryptor if one is available, a certificate obtained from a trusted enterprise CA, or a self-signed certificate.
Encrypted files or folders retain their encryption after being either copied or moved from a local to a remote computer, provided that the remote computer is trusted for delegation and the target volume uses the version of NTFS used in Windows 2000 or later. A moved or copied file is re-encrypted on the target volume, so it has a new FEK, and the FEK is encrypted by using the user s public key if it is available or by using a new public key EFS generates if the profile is unavailable. In the latter case, a new user profile is generated for the user on the remote computer to store the new private key.
If all of the conditions necessary for remote encryption are not met, the transfer might fail. If the computer is not trusted for delegation, EFS cannot impersonate the user. When this occurs, the user receives an Access is denied message. If EFS can successfully impersonate the user, but the target volume does not use the version of NTFS used in Windows 2000 or later, the transfer will succeed, but the file or folder loses its encrypted status.
Encrypted files might need to be decrypted before the files can be copied or moved to volumes that are not EFS-capable. For any file operation in My Computer, if the destination volume is not capable of re-encrypting the file, the following message is displayed to the user: The file filename cannot be copied or moved without losing its encryption. You can choose to ignore this error and continue, or cancel. If the user chooses to ignore the message, the file is copied or moved, but is stored in plaintext on the destination volume.
Attempts to copy encrypted files by using either the copy or xcopy commands to non-EFS capable volumes fail. In both cases an error message informs the user that the operation failed because the file could not be encrypted. If used with appropriate parameters, however, the copy and xcopy commands can be used to copy encrypted files to non-EFS capable volumes.
| Note | The copy and xcopy command-line parameters that enable copying of encrypted files to non-EFS capable volumes are available in Windows XP Professional, but are not available in earlier versions of Windows. |
Table 17-4 lists the parameters for the tasks that you can perform by using the copy and xcopy commands.
| Task | Parameter |
|---|---|
| Copy encrypted files to non-EFS capable volumes by using the copy command. | copy /d |
| Copy encrypted files to non-EFS capable volumes by using the xcopy command. | xcopy /g |
When users open encrypted files stored on Web folders, the files remain encrypted during the file transfer, and EFS decrypts them locally. Both uploads to and downloads from Web folders are raw data transfers, so even if an attacker could access the data during the transmission of an encrypted file, the captured data would be encrypted and unusable.
EFS with Web folders eliminates the need for specialized software to securely share encrypted files between users, businesses, or organizations. Files can be stored on common intranet or Internet file servers for easy access while strong security is maintained by EFS.
The WebDAV redirector is a mini-redirector that supports the WebDAV protocol, an extension to the HTTP 1.1 standard, for remote document sharing over HTTP. The WebDAV redirector supports the use of existing applications, and it allows file sharing across the Internet (for example, using firewalls, routers) to HTTP servers. Internet Information Services (IIS) version 5.0 (Windows 2000) supports Web folders.
Users access Web folders in the same way that they access file shares. Users can map a network drive to a Web folder by using the net use command or by using My Computer. Upon connecting to the Web folder, the user can choose to copy, encrypt, or decrypt files exactly as they would by using files on file shares.
| Note | Web folders are not included in browse lists. To connect to a Web folder, the user must specify the full path (for example, \\ServerName\WebShareName). |
You can create a Web folder on a server that is running Internet Information Services 5.0 or later. WebDAV is an Internet standard protocol, and WebDAV implementations are possible with other third-party Internet servers.
To create a Web folder
Right-click a folder on the server, and then select Properties.
On the Web Sharing tab, click the Share this folder button.
On the Edit Alias screen, enter an alias (equivalent of a share name) and appropriate permissions.
For more information about configuring WebDAV folders, see Internet Information Services 5.0 Help.
When a user chooses to encrypt a file on a Web folder, the file is automatically copied from the Web folder to the user s computer, encrypted on the user s computer, and then returned to the Web folder. The advantage to this is that the computer hosting the Web folder does not need to be trusted for delegation and does not require roaming or remote user profiles. No other administrative tasks beyond creating the Web folder and assigning user permissions are required. The disadvantage is that the file must be transmitted from the Web folder to the local computer in order to be encrypted. Organizations need to consider whether the bandwidth requirements for Web folders outweigh the administrative effort necessary to maintain file shares for encrypted file storage. It must also be considered that Web folders are not recommended for files over 60 MB in size.
| Note | Bandwidth requirements are reduced if the user encrypts the file locally and then stores the file on the Web folder. The encrypted file is also transmitted in ciphertext when it is transmitted to a Web folder. |
When a user chooses to decrypt a file on a Web folder, the file is automatically copied from the Web folder to the user s computer in ciphertext. EFS then decrypts the file on the user s computer. If the user opens the encrypted file for use in an application, the file is never decrypted anywhere except on the user s computer. If the user chooses to decrypt a file on the Web folder rather than on the local computer, the file is transmitted in plaintext and stored in plaintext on the Web folder after it is decrypted on the user s computer. The computer hosting the Web folder does not require any configuration except for the creation of the Web folder and the assigning of user permissions in order for remote decryption to function.
Encrypted files are copied from Web folders in the same way that plaintext files are copied from file shares. The copy and xcopy commands do not require any special parameters. The file is transmitted in ciphertext and remains encrypted on the local computer if possible. The encryption status for files copied from Web folders is the same as that for files copied locally. For more information about encryption status for files copied locally and about the copy and xcopy commands, see Local and Remote File Operations in a File Share Environment earlier in this chapter.