2.8.5. EFS – Part 3
By Val Bakh
Previously, in Parts 1 and 2 of the blog series about Encrypting File System (EFS), we introduced the main concepts and described how EFS encrypts and decrypts files, how you can share those files with your trusted colleagues, and how a data recovery agent (DRA) can recover your files if something happens to you or to your private key. In this final installment of the series about EFS, we’ll look at several typical scenarios.
By default, the built-in domain Administrator account is automatically designated as a DRA in the Default Domain Policy Group Policy object (GPO) when the first domain controller is installed in the domain. There’s a good chance that no enterprise certificate authorities (CAs) were around when this happened, especially if the domain was the first one in the forest. In that case, the DRA certificate is self-signed, which means no one automatically trusts it. But, more importantly, the private key for that certificate is sitting on that domain controller in the Administrator account’s local profile. When the domain administrator needs to recover someone’s encrypted files, he or she cannot just connect to the target computer over the network and effortlessly open the files. Nor would it help much if the administrator logged on locally to the computer containing the encrypted files. The DRA’s private key must be available locally on the computer where the encrypted files are stored. The administrator needs to export the DRA certificate along with the private key to a file, transfer the file to the target computer, log on locally, and import the certificate before he or she can recover the files.
Suppose, at some point, the same administrator installs an enterprise CA and requests a new, trusted DRA certificate from that CA. The CA issues a certificate with the Extended Key Usage attribute that is set to File Recovery. Everything looks copacetic, but when the administrator clicks Browse Directory and selects the built-in domain Administrator account (the most powerful account in the domain, with a brand new, properly issued certificate) in an attempt to specify the new certificate in Default Domain Policy, the certificate doesn’t show up. Instead, a message appears that reads, “No certificate available. No certificates meet the application criteria.”
This message appears because the new DRA certificate is based on the certificate template named EFS Recovery Agent. It is an ancient, Windows 2000–based, version 1 template, which does not have any configurable options except security permissions. The Publish certificate in Active Directory option in that template is not selected. Any certificates based on that template are not published to Active Directory Domain Services (AD DS) automatically and, therefore, are not visible in GPOs unless the administrator exports the certificate to a file, clicks Browse Folders, and selects that file (rather than clicking Browse Directory and selecting his or her user account).
If EFS DRAs are going to be designated often, a better solution would be to create a newer-version copy of the old certificate template, select the option to publish certificates to AD DS automatically, and configure the CA to use that template. Consequently, other DRAs will request certificates based on the new template and will not have to export their certificates to files in order to make them available to a GPO. Alternatively, one might still be able to hunt down a good, old-fashioned command-line tool (in this case, Certutil) to perform the work manually.
And one more detail. Once the administrator has replaced his or her DRA certificate in Default Domain Policy, the policy doesn’t take effect right away. The GPO refresh must first occur on the target computers either automatically, within an hour or two, or manually through the gpupdate command. In some situations, all encrypted files on the target computers are updated with the new DRA certificate automatically, and sometimes users might need to run the cipher /u command or simply open and close each of their encrypted files.
Now, assume that you are a user who needs to encrypt some files remotely. On your client computer, you navigate to a shared folder on a file server and try to copy an encrypted file from your computer to the file server. In your user profile on your computer, EFS finds the private key that matches your public key that was used to encrypt the file encryption key (FEK). EFS decrypts the FEK and then decrypts the file. The file is transferred across the network to the file server in clear text, and then EFS on the server attempts to re-encrypt it.
Two things must happen for the encryption to succeed: (1) a suitable certificate issued to you must be available on the server, and (2) EFS on the server must be able to act on your behalf. By default, neither one is true. As a result, you receive a message saying that the location you are trying to copy files to does not support encryption. Unless you happened to log on to the server locally in the past and encrypt files on it, no EFS certificate exists in your local profile on the server. You might not have a profile on the server at all if this is the first time you are connecting to a shared folder on the server. Absence of a profile is not a problem; the server can always create one for you. But, unlike EFS on your local computer, EFS on the server cannot act on your behalf unless a domain administrator configures the server to be trusted for delegation. In the Active Directory Users and Computers console, the administrator should open the server’s computer account and select Trust this computer for delegation to any service (Kerberos only) on the Delegation tab. This configuration enables the server to act on your behalf, provided your user account allows that. By default, it does, but the administrator should look at the Account is sensitive and cannot be delegated option on the Account tab in your domain user account’s properties and make sure that it is not selected. And finally, the last step before you can copy your encrypted files to the server: on your computer, you need to log off and then log back on.
Now EFS on the server will request and receive a certificate for you, will generate a FEK for each of your files, and will encrypt the FEKs by using your new certificate’s public key. The private key for that certificate will be stored in your local profile on the server. Note that it’s a new certificate, not the same one that you already have on your workstation and that was used to encrypt your files there. So, if you encrypt files on several file servers, EFS on each server will get a separate certificate for you. Because each server will hold your corresponding private key, you can access your encrypted files on any of the servers from any client computer. Thus, to be able to roam, you don’t always need a roaming profile or roaming credentials, but you will likely need quite a few certificates.
Scenarios where EFS is used are so numerous and diverse that no one can describe them all. However, knowing every possible scenario isn’t necessary, because as long as you understand the main principles, you can always figure out what happens when you try to encrypt a new file or to open an encrypted one. This series of blog posts was intended to help you gain that understanding.