Authorizing Multi-User Access to Encrypted Files
Users can share encrypted files with other local, domain, and trusted domain users. Authorizing user access to encrypted files is a separate process from sharing files for network access by using share-level security and access control lists. Because there is no method to issue a certificate for a group, only individual user accounts can be authorized for access to an encrypted file. Groups cannot be authorized for access.
How Users Are Authorized for Access to Encrypted Files
After a file has been encrypted, additional users can be authorized to access encrypted files by using the Advanced Attributes dialog box in the file s properties. When the original encryptor or another authorized user shares the encrypted file with another user, EFS uses the following process:
-
An authorized user opens the Advanced Attributes dialog box for the encrypted file and clicks the Details button.
-
In the Encryption Details dialog box, the user clicks the Add button to open the Select User dialog box. EFS certificates stored in the user s profile in the Other People and Trusted People certificate stores are automatically displayed. To locate user certificates that are stored in Active Directory, the user can click the Find User button, and then click the Find Now button to locate the selected user(s). A dialog box will display any users that hold valid EFS certificates in the Active Directory based on the search criteria.
EFS certificates can also be imported to the user s profile. If the EFS certificate is self-signed, it is added to Trusted People. If the EFS certificate was issued by a CA, it is added to Other People. Certificates added to either container appear in the Select User dialog box.
Note If you import someone s certificate, you have the option to manually select its location. If you import a self-signed certificate, be sure to add it to Trusted People. Certificates in Trusted People are the only certificates that are not chain validated because the certificates are already trusted. Self-signed certificates will always fail chain validation because no CA was involved in certifying them, so placing them anywhere other than in Trusted People makes them unusable.
-
Before a user can be authorized to access an encrypted file and be added to the file, EFS needs to determine whether the certificate can be trusted. When a user s certificate is selected, EFS attempts to validate the certificate chain. If the chain validation fails, CryptoAPI also checks to see if the certificate is in Trusted People store. If not, the certificate cannot be used.
Imported self-signed certificates are automatically placed in Trusted People, and there is no certificate chain to validate, so the user can be added to the encrypted file.
If the certificate was signed by a CA, EFS attempts to build a certification chain and validate the certificate. If the chain ends with an untrusted root CA, EFS will not use the certificate, and the user is not added to the file. If the user s EFS certificate is signed by a CA and includes information about certificate revocation list (CRL) distribution points, EFS attempts to connect with the distribution points to check for certificate revocation. If a CRL distribution point cannot be reached, the certificate will not be used, even if the root is trusted. Finally, if the EFS certificate is signed by a CA, the CA is trusted, and the CA does not use CRL distribution points, EFS accepts the certificate and adds the user.
-
For the next part of the process, assume that Alice already has access to the encrypted file. She is either the original encryptor, or she has been authorized for access. Alice is authorizing Bob to access the file.
-
EFS obtains Alice s private key from her user profile to decrypt the FEK contained in the file s data decryption field.
-
EFS obtains Bob s public key from his certificate and uses it to encrypt the FEK.
-
Bob s encrypted FEK is stored in a new data decryption field with the file.
Note At no time in this process is the file itself decrypted, so it is not at risk directly. However, the FEK is briefly decrypted. Because EFS performs this operation in nonpaged memory, the decrypted FEK is never paged and so is never exposed.
Figure 17-7 shows what happens when Alice shares an encrypted file with Bob.
Figure 17-7: Sharing an encrypted file
Considerations for Sharing Encrypted Files
It is important that users electing to share encrypted files keep the following points in mind:
-
Shared EFS files are not file shares. If authorized users need to access shared EFS files over the network, a file share or a Web folder is required. Alternatively, users could establish remote sessions with computers that store encrypted files by using Terminal Services.
-
Any user who is authorized to decrypt a file can authorize other users to access the file. Granting access is not limited to the file owner. Caution users to share files only with trusted accounts, because those accounts can authorize other accounts. Removing the Write permission from a user or group of users can prevent this problem, but it also prevents the user or group from modifying the file.
-
EFS sharing requires that the users who will be authorized to access the encrypted file have EFS certificates. These certificates can be located in roaming profiles or in the user profiles on the computer on which the file to be shared is stored, or they can be stored in and retrieved from Active Directory.
-
EFS sharing of an encrypted file often means that the file will be accessed across the network. It is best if Web folders are used for encrypted file storage whenever possible. For more information about using Web folders to share encrypted files, see Remote EFS Operations on File Shares and Web Folders earlier in this chapter.
-
If a user chooses to remotely access an encrypted file stored on a file share and to authorize other users to access the file, the authorization process and requirements are the same as on the local computer. Additionally, EFS must impersonate the user in order to perform this operation, and all of the requirements for remote EFS operations on files stored on file shares apply. For more information about the requirements for EFS operations, see Remote EFS Operations on File Shares and Web Folders earlier in this chapter.
-
If a user chooses to remotely access an encrypted file stored on a Web folder and to authorize other users to access the file, the file is automatically transmitted to the local computer in ciphertext. The authorization process takes place on the local computer with the same requirements as for encrypted files stored locally.
Sharing Encrypted Files
You can authorize individual users to access encrypted files.
To share an encrypted file with other users
-
In My Computer, right-click the encrypted file, and then click Properties.
-
On the General tab, select Advanced.
-
In the Advanced Attributes dialog box, under Compress or Encrypt Attributes, select Details.
Note If you select an encrypted folder instead of an encrypted file, the Details button appears dimmed. You can add users to individual encrypted files but not to folders.
-
In the Encryption Details dialog box, click Add.
-
Add a user from the local computer or from Active Directory.
To add a user from the local computer
-
In the Select Users dialog box, click the user s certificate, and then click OK.
To add a user from Active Directory
-
Click Find User. In the Find Users, Contacts, and Groups dialog box, click Browse to search for users.
-
In the Browse for Container dialog box, click the folder or domain in which you want to begin your search. You can perform your search in the entire directory or start searching from a folder or domain within the directory.
-
To narrow the search, click Advanced and then click Field to search for users by using conditions and values.
-
Select the user, and then click OK.
| Caution | Any authorized user of an encrypted file can authorize other users access, so it is important to authorize access for trusted accounts only. |
