- 1 VMware Takes the Wraps Off vRealize Automation and vRealize Business
- 2 Microsoft Previews Hyper-V Containers for Windows Server 2016
- 3 Mirantis Led FUEL Project Gets Installed Under OpenStack Big Tent
- 4 Red Hat Enterprise Linux 7.2 Adds Security, DR Features
- 5 Docker Reaches Across Universes at Dockercon EU
EFS for System Admins Page 2
Having said this, how is it that the recovery agent is also able open the file? Well, the FEK is also separately encrypted by the public key of each recovery agent, and stored in different header fields in the encrypted file, called Data Recovery Fields (yes, if there is more than one recovery agent, there will be more than one DRF for the file). For a recovery agent to decrypt the file, the private key of the agent is used to decrypt the FEK, which in turn decrypts the file. So who generates the FEK? The system itself, by way of the CryptoAPI.
Now that we're all cryptography experts (don't I wish!), lets take a look at how all this gets dealt with from the system admin point of view. First of all, you do not need a Certificate server in order to use EFS, though EFS will contact the configured certificate authority for certification is one exists. If a CA for a user is not present, EFS will create a key-pair and will self-sign the certificate, which allows a user to begin using EFS without any further configuration. So, right from the get-go, users can begin encrypting files and folders as necessary. For the sake of simplicity, folders should have the encryption attribute set, and users should be taught to save files into the encrypted folder. Just remember - for the user to be able to open the existing files saved there, the folder must be encrypted while logged on with their own account! As for private key storage, this is stored encrypted by system keys as part of the user's profile. So, if you're using roaming profiles, EFS capabilities follow the user. Otherwise, files encrypted by a user on a given machine can only be opened on that machine, since their key-pair is stored as part of their local profile.
The most important thing you need to understand about EFS as a System Admin is how to recover an encrypted file if necessary. This ability does not have to be limited to the Administrator, although this account is the only recovery agent by default. Before going in to too much detail, you should first understand that on a non-domain system, the local Administrator account is the recovery agent. However, once a system is joined to a domain, the domain Administrator account is then the default recovery agent (with settings found in the default domain policy). Recovery agents are configured via Group policy, in the following location:
Computer Configuration - Windows Settings - Security Settings - Public Key Policies - Encrypted Data Recovery Agents.
You can add or delete recovery agents as necessary, as long as they have a valid certificate. The certificate for the administrator account is created automatically, but you would need to create (or already have in Active Directory) ones for other users you wish to add as recovery agents.
But as a recovery agent, how do I actually open a file I need to recover? Well, if the user sends you the file, or you're using roaming profiles and log on to their machine, then all you need to do is double-click the file and it will open normally. However, if you are not using roaming profiles, and the user cannot send you the file because of security concerns, then you will need to transfer your certificate and private key to the target machine in order to decrypt the FEK and ultimately the file. What you'll first need to so is export your recovery certificate and private key to a file, probably on a floppy disk. If you export your private key, it must be password protected. To do this, you need to use the 'Certificates' snap-in in the MMC, then find your recovery certificate under Personal Certificates, and choose Export from the shortcut menu. To install the certificate on the target system, simply double click the file, and follow the instructions provided by the Certificate Import Wizard. Finally, for security reasons you should choose to export and your certificate and delete your private key from the target machine once you have decrypted the necessary files. This ensures that should your account be compromised, the user would not be able to decrypt files on the system using the recovery agent private key.