One of the changes that Steve Jobs briefly mentioned in the course of the WWDC 2011 keynote address was that Apple had revamped its FileVault encryption solution for Mac OS X 10.7.x, changing it from encryption that primarily protected your accounts home folder to encryption that protects your whole boot volume. Since that initial announcement, FileVault 2 has evolved into an encryption solution that can be easily managed by both home users and enterprises alike.
That said, almost every technology solution has details and parts that aren’t generally well known and FileVault 2 is not different in that regard. To help Mac admins who are managing FileVault 2 in their own environment, I’ve put together a list of 10 things I’ve run across in my work with FileVault 2 that I’ve either been asked about frequently or which seem to be completely undocumented by Apple. Most of these I’ve previously documented in one form or another, so some of these may seem familiar. See below the jump for the list.
1. Password Changes And FileVault 2
FileVault 2 has a nifty password update procedure for its enabled accounts (i.e. the accounts that show up at the pre-boot login screen) If you change your accounts password, the OS will automatically and invisibly update your FileVault 2 pre-boot login. This helps ensure that your account is consistently using the same password across the board. For local accounts, this password update is triggered when changing the local accounts password via the Users & Groups preference pane in System Preferences.
If a FileVault 2-enabled account is an Active Directory or Open Directory mobile account (where the accounts password is being managed by the Active Directory or Open Directory directory service), it’s possible to change your password for your account without your Macs OS being aware of it. For example, many worksites have a policy that you must change your password on a scheduled interval and also provide a website where you can change your password. If your encrypted Mac was offline at the time that your password was changed, it may not receive that password change until the next time you start up.
In a case like this, here’s how the password update process should work:
1. The mobile account’s password gets changed outside the Mac.
2. You boot your encrypted Mac while connected to a network that allows connections between your Mac and the directory service that manages the account’s password.
3. The pre-boot login screen would accept the account’s old password.
The pre-boot login is taking the old password here because the OS is not running at this point in the boot process, and the Mac is unable to communicate with the directory service that manages the accounts password.
4. Next, you get the OS’s login window and type the accounts new password there. Since the OS is running at this point, it can communicate with the directory service and learn that the account has a new password. Once the new password has been accepted, the OS will allow the login process to complete and it will also update the FileVault 2 pre-boot login to use the new password.
5. After the new password has been accepted, the Mac should provide the option to update the login keychains password.
Once updated, the login keychain should be using the account’s new password as well.
2. The Guest User And FileVault 2
One unusual feature of FileVault 2 is that sometimes a Guest User icon will appear at the pre-boot login screen.
When you log in as that guest user, you don’t get access to your hard drive. The only thing you get access to is Safari and a network connection. Quitting out of Safari will return you to the FileVault 2 pre-boot login screen.
To my knowledge, Apple has never commented specifically about this guest user but it appears the guest user is an anti-theft measure. The guest user’s appearance at the pre-boot login screen is a feature tied to signing into iCloud and enabling the Find My Mac option.
One consequence of logging into the guest user is that, as soon as the Mac gets a network connection, it will immediately connect back to Apple and report its location information.
If you don’t sign in with iCloud and then enable Find My Mac from that machine, the Guest User icon will not appear on the FileVault pre-boot login screen. That said, mobile device management solutions that track a machine’s location may also trigger the Guest User icon to appear.
3. Enabling Non-Enabled Admin Users For FileVault 2 Via System Preferences
One challenge for Mac admins is figuring out ways to enable users for FileVault 2. One approach to enable non-enabled accounts that have administrative privileges is the following:
1. Log in at the OS login window as the non-enabled admin account.
2. Open System Preferences and go to the FileVault preference pane
3. Click the lock to unlock the FileVault preference pane and authenticate when prompted.
4. Click the Enable Users button in the FileVault preference pane
5. The previously non-enabled admin user account will appear with a green checkbox to show that the account has been enabled for FileVault 2.
This approach to allow admin users to enable themselves for FileVault 2 has worked since FileVault 2 was first introduced in Lion and it continues to work in Yosemite.
4. Creating An Institutional Recovery Key
If you want to use an institutional recovery key on FileVault 2 encrypted Macs, you will need to create and configure a FileVaultMaster keychain. Apple has provided a way to create this keychain by using the security command’s create-filevaultmaster-keychain function. To create a FileVaultMaster.keychain file, run the following command in the Terminal:
security create-filevaultmaster-keychain /path/to/FileVaultMaster.keychain
You’ll be prompted for a password for the keychain. When provided, the keychain will be created and will contain both the private and public keys needed for recovering a FileVault 2-encrypted drive that uses this institutional recovery key.
Make copies of the keychain and store them in a safe place. Also make sure to securely store copies of the password you used to create the keychain.
If you want to create the FileVaultMaster keychain in its proper place, run the security command with root privileges and use /Library/Keychains for the destination path.
Once you’ve made your copies, make another copy and remove the private key from that copy of the keychain. Once the private key is removed, the FileVaultMaster.keychain file is ready to be used for encrypting Macs with FileVault 2 with the institutional recovery key.
It doesn’t appear that the security man page includes information about the create-filevaultmaster-keychain function, but you can see what it does by running the security help command in the Terminal and checking at the bottom of the list that appears.
A way to modify /Library/Keychains/FileVaultMaster.keychain so that it only has the public key inside would be to do the following:
1. Create the FileVaultMaster.keychain file using the security command.
2. Next, make several copies of the FileVaultMaster.keychain file that you just created and store the copies separately in secure locations. A locked safe would be a good place, or in an encrypted disk image that is on an access-restricted file share.
3. Next, unlock the newly-created FileVaultMaster.keychain file by running the following command and entering the keychain’s password when prompted for the password:
security unlock-keychain /Library/Keychains/FileVaultMaster.keychain
Note: The FileVaultMaster keychain will need to be unlocked from the command-line as the keychain will not unlock in Keychain Access by clicking on the lock.
4. If it succeeds, you’ll get the next system prompt. If not, get another copy of the FileVaultMaster.keychain file and try again. A FileVaultMaster.keychain file with an unknown password should not be used because there is no way to use it for recovery purposes without first knowing the keychains current password.
5. Once you’ve unlocked the FileVaultMaster.keychain file, open the Keychain Access application from /Applications/Utilities/.
6. In Keychain Access, go to File: Add Keychain and add /Library/Keychains/FileVaultMaster.keychain.
7. Assuming you previously unlocked the FileVaultMaster.keychain file using the security command, it should show up as unlocked in Keychain Access.
8. Go into the FileVaultMaster keychain and remove the private key. (It should be called FileVault Master Password Key and its kind should be listed as private key.)
9. Relock the FileVaultMaster keychain
10. Copy the modified FileVaultMaster.keychain file (now with only the public key inside) to the /Library/Keychains directory of the Macs you want to encrypt with FileVault 2. For ease of deployment, you can package the FileVaultMaster.keychain file into an installer package. That installer package can then be deployed ahead of encryption to multiple machines using the system management tools used in your environment.
When deployed to /Library/Keychains on the Macs you want to encrypt with FileVault 2, the FileVaultMaster.keychain file should have the following permissions set:
Owner: root
Permissions: read and write
Group: wheel
Permissions: read only
Everyone
Permissions: read-only
Once the institutional recovery key is deployed to an unencrypted machine, enabling FileVault 2 via System Preferences should produce a message stating that A recovery key has been set by your company, school or institution instead of displaying the personal recovery key.
5. Erasing A FileVault 2-Encrypted Volume From The Command Line
On occasion, it’s necessary to erase a FileVault 2-encrypted volume. However, sometimes Disk Utility won’t let you erase or repartition an encrypted drive until you unlock or decrypt. This can be an issue for a malfunctioning FileVault 2-encrypted volume that will not let you either unlock or decrypt.
To help with this, the diskutil tool provides a way to quickly delete CoreStorage volumes from the command line. This includes the ability to erase encrypted CoreStorage volumes (aka FileVault 2-encrypted volumes) without first deleting them.
To do this, first run the following command in the Terminal:
diskutil cs list
This will give you with a list of the CoreStorage volumes on your system. Unless you have a Fusion drive or multiple encrypted drives, your FileVault 2-encrypted drive should be the only one listed.
In the listing, you will want to select and copy the Logical Volume Group (LVG) alphanumeric UUID for your CoreStorage volume. The LVG should be the first UUID listed and its the one we want to delete.
Next, run the following command in the Terminal:
diskutil cs delete UUID_here
This command will delete the encrypted CoreStorage volume and reformat it as an unencrypted HFS+ volume.
6. Setting A Text-Only Login Banner For The FileVault 2 Pre-Boot Login Screen From The Command Line
It is possible to set a text-only banner message that appears in the following locations:
1. The FileVault 2 pre-boot login screen
2. The OS login window
3. The screensaver lock window
Brevity is best, as staying within a maximum of three lines will permit the banner text to be consistently displayed in all three locations. Exceeding the three-line limit may result in the text being cut off and not fully displayed.
You can set this banner text from the command line using the following defaults command, which should be run with root privileges:
defaults write /Library/Preferences/com.apple.loginwindow LoginwindowText "My Login Window Text Goes Here"
However, if these functions were enabled from the command using the defaults command, they may show up at the OS login window and the screensaver lock window, but not the FileVault 2 pre-boot login screen.
The answer seems to be that, in addition to running the defaults commands, you also need to manually update the /System/Library/PrivateFrameworks/EFILogin.framework using the touch command. By running the touch command on the right part of the EFILogin framework, the OS will force the system to update the FileVault 2 pre-boot login screen to use the banner text.
For example, running the following commands with root privileges updates the FileVault 2 pre-boot login screen with a login banner:
defaults write /Library/Preferences/com.apple.loginwindow LoginwindowText "My Login Window Text Goes Here"
touch /System/Library/PrivateFrameworks/EFILogin.framework/Resources/EFIResourceBuilder.bundle/Contents/Resources
On restart, the FileVault 2 pre-boot login screen should look like this, with the banner text now showing.
To remove these, you would need to boot back into the OS and run the following commands in the Terminal with root privileges:
defaults delete /Library/Preferences/com.apple.loginwindow LoginwindowText
touch /System/Library/PrivateFrameworks/EFILogin.framework/Resources/EFIResourceBuilder.bundle/Contents/Resources
On restart, the text should no longer appear at the FileVault 2 pre-boot login screen, the OS login window or the screensaver lock window.
7. Booting Into Single-User Mode On A FileVault 2-Encrypted Mac
A while back, I communicated with a Mac admin who was concerned about using FileVault 2 in his environment because he didnt want to lose access to tools like single-user mode. Like a number of Mac admins, hed found single-user mode valuable in helping to diagnose and fix issues on troublesome Macs.
Fortunately, Apple makes it reasonably easy to boot into single-user mode on a FileVault 2-encrypted system. here’s how to boot into single-user on a FileVault 2-encrypted system:
1. Hold down Command-S after powering the system.
2. The Mac will be begin booting into single user, then the FileVault 2 pre-boot login screen will appear.
3. Authenticate at the FileVault 2 pre-boot login screen by selecting an account and providing the accounts password.
4. The Mac will then unlock and continue booting into single-user mode.
8. Using Apple’s Internet Recovery To Unlock Or Decrypt Your FileVault 2-Encrypted Boot Drive
One of the new features that appeared with Macs that shipped with Mac OS X 10.7.x and later versions of OS X was Apple’s Internet Recovery. If you encounter a situation in which you cannot start from the Mac’s Recovery HD partition, such as where the internal hard drive has failed or when you’ve installed a new disk without an OS on it, Mac models that were released after July 2011 can use Internet Recovery. Internet Recovery lets you start your Mac directly from Apple’s servers using a NetBoot-like process and gives you the same functionality that Recovery HD does.
Because Internet Recovery has the same capabilities as your Macs Recovery HD partition, it can be used to unlock or decrypt a FileVault 2-encrypted Mac. This is potentially valuable in case of emergency, as it means that you can do recovery of a FileVault-encrypted drive even in a situation where the Macs Recovery HD partition has been damaged or corrupted in some way.
To force your Mac to boot to Internet Recovery, start up your Mac and hold down Command-Option-R on your keyboard. You should see a gray screen with an animated globe appear and display a message similar to Starting Internet Recovery. This may take a while.
Depending on your connection speed, it may also switch to a countdown clock to show you how long until its fully booted.
Once booted to Internet Recovery, you should see the Recovery interface and the available tools.
From there, you should be able to use Disk Utility or the Terminal applications to unlock or decrypt your FileVault 2-encrypted Mac.
9. FileVault 2 And UUIDs
A little-known fact about FileVault 2 is that it uses the GeneratedUID user attribute (also known as a UUID) of an account to help identify enabled accounts. For example, when you run the fdesetup list command in the Terminal, you’ll see the user information for FileVault 2-enabled accounts appear with both the username and UUID information.
For local accounts, the OS will properly generate a GeneratedUID user attribute to provide a UUID for the local account. Active Directory also generally handles this correctly on Macs, so I haven’t seen UUID problems occur for AD mobile users.
Where I’ve heard of problems have been with Macs bound to non-Apple LDAP servers. If the LDAP server doesn’t provide the GeneratedUID user attribute for its accounts, or it does not provide the UUID in the way that FileVault 2 is expecting, you may see one or more of the following behaviors:
- The LDAP account’s icon disappearing from the FileVault 2 pre-boot login screen – This behavior is generally caused by the GeneratedUID attribute not being set for the LDAP account.
- The account icon being present, but the password not matching the current password on the LDAP server – This behavior has been observed when the GeneratedUID does not match what FileVault 2 is expecting.
A good example of the latter behavior comes from a Mac admin who asked me about the issue he was seeing with passwords not updating. His shop was running an LDAP server as its directory service for its Macs and he had recently added the GeneratedUID user attribute to the accounts on the LDAP server as a fix for accounts disappearing from the FileVault 2 pre-boot login screen. Now, accounts were staying at the FileVault pre-boot login screen, but their passwords were not updating to match what was set on the LDAP server.
In discussing the problem, he mentioned that the UUIDs were using lower-case letters; did that matter? When I followed up on this, he confirmed that instead of his UUIDs looking like this:
7C9AFB0E-E06E-43FA-8E9F-1D410344D2AA
Instead they looked like this:
7c9afb0e-e06e-43fa-8e9f-1d410344d2aa
After confirming that Mac account UUIDs needed to use upper-case alphabetical characters and were case-sensitive, my colleague changed a test account’s UUID to use all upper-case for the alphabetical characters. At that point, FileVault 2 logins for that account began working properly.
If you have an LDAP server and your mobile LDAP accounts aren’t working properly with FileVault 2, here’s what should make FileVault 2 start working properly:
A. On your LDAP server(s), make sure that there’s an apple-generateduid value for your LDAP accounts – If an apple-generateduid value exists in LDAP for a user and is mapped properly to the GeneratedUID attribute on your Macs, FileVault 2 will use the apple-generateduid value stored in LDAP for its UUID.
B. Ensure that all alphabetical characters listed in the apple-generateduid value are using upper-case characters – It’s very important that the locally-set UUID value and the value stored in LDAP match exactly. Otherwise, you may see a recurrence of one or both of the undesired behaviors described above.
10. Automating fdesetup authrestart in 10.9.x or later
One of the more interesting functions in Apple’s fdesetup tool is the authrestart verb, which allows a FileVault 2-encrypted Mac to restart and bypass the FileVault 2 pre-boot login screen. Instead, the Mac reboots as an unlocked system and goes straight to the regular login window.
When you run the fdesetup authrestart command, it asks for a password or a personal recovery key. If using a password, the password must be an account that has been enabled for FileVault 2. After that, it puts an unlock key in system memory and reboots. On reboot, the reboot process automatically clears the unlock key from memory.
For those who want to automate this process, Apple added some functionality to fdesetup authrestart in OS X 10.9.x to support importing the authentication via a properly formatted plist. The plist needs to follow the format shown below:
<?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"><plist version="1.0"> <dict> <key>Password</key> <string>password</string> </dict> </plist>
You would store either the password of an existing FileVault 2-enabled user or the existing personal recovery key in the Password key in the plist file.
Once the plist file has been set up and properly formatted, run the following command with root privileges to run the authrestart process and reference the password or recovery key in the plist file for authentication.
fdesetup authrestart -inputplist < /path/to/filename.plist
Once the command runs, it puts an unlock key in system memory and reboots the Mac to the OS login window. As part of the Mac’s restart, the reboot process will automatically clear the unlock key from memory.
