Tag: fdesetup

Difficulties in automating FileVault

FileVault encryption is unfortunately one of the things for Mac admins that is extremely difficult to automate.

Crypt

There's a project called Crypt that involves a login hook that checks whether encryption is enabled or not and then prompts the user to enable encryption. Once that's done, the individual recovery key is sent to a Django webapp.

fdesetup

You can create text files with usernames and plain text passwords to import in to automate FileVault encryption: Managing El Capitan’s FileVault 2 with fdesetup.

addCurrentUser script

You can use a script that prompts the current user to enable FileVault encryption.

My sort-of version of Crypt

I did a slight modification of the Crypt approach by creating a logout script that checks whether encryption is enabled or not. If it's not, the user will see the FileVault tab of System Preferences when she logs in:
FileVaultCheck.sh

No perfect solution

At the end of the day, though, someone has to be prompted to manually enter passwords or you have to store passwords in plain text somewhere. If you are a Mac admin who wants a local admin account to be enabled as a FileVault user but also want your individual laptop users' accounts also enabled, it's not feasible (or a good idea) to collect all of their passwords and store them in plain text in a file somewhere or several files.

The safest but still troublesome way to enable FileVault encryption is to enable it for the local admin account, enable it for the primary user, and then grab her to enter her password right away.

You can also defer enablement (which will prompt the user at login or logout to enable FileVault), but, according to Rich Trouton, this can be done for only a single user and not multiple users.

Details on enabling users

Here's a bit of a weird thing that I didn't see documented anywhere.

If you have accounts that already exist—say, Constance, Randall, and Hudson—and Constance enabled FileVault encryption, then Randall and Hudson will not be able to decrypt the machine unless Constance knows their passwords and manually enables their accounts to be able to use FileVault.

If, however, Constance is the only user of the machine, and she enables FileVault, and then she decides to add Randall and Hudson as new users afterwards, Randall and Hudson will automatically be able to decrypt the computer. This generally works, but I've also seen situations in which it doesn't (for example, if you delete a user account and then re-add one with the exact same name—the "new" account will not be able to decrypt the computer until you enable the user manually to do so).

Creating the institutional recovery key

If you want to use an institutional recovery key (instead of collecting automatically-generated individual recovery keys), I found this PeachPit tutorial (by Rich Trouton) to be the clearest. I'll boil down the steps here with minimal explanation.

Create the FileVault master keychain:

Copy it somewhere:

Unlock the keychain:

Click FileVaultMaster from the left pane and then select the private key and delete it.

Then right-click FileVaultMaster and lock it.

Then distribute a .pkg whose payload will be that keychain (sans private key) to /Library/Keychains on your client machines.

Using the institutional recovery key in recovery mode

In theory, you probably have a local admin account that can decrypt the computer, but if you give a user admin privileges and the user accidentally deletes the local admin account or changes its password and then forgets what the new password is (along with the user's own password), that's when your institutional recovery key can come in handy to decrypt the drive. In other words, you should probably never need it, but it's nice to have as a failsafe. I mean, you're backing up the user's data with CrashPlan (or some other backup solution) anyway, but you may still want to decrypt the drive.

For more details, check out Using a FileVault institutional recovery key to unlock an encrypted disk