Ten Things You Might Not Know About FileVault 2
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 account’s 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 account’s 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 account’s 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 account’s password.
4. Next, you get the OS’s login window and type the account’s 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 keychain’s 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 account’s 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 Mac’s 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 Mac’s 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 attribute 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.
Leave a comment
Recent Comments
 | Dark on Creating root-level directorie… |
 | Ben LeRoy on Losing a giant |
 | Peter-Erik on Downloading installer packages… |
 | nathanhaggard on Losing a giant |
 | andras0602 on Disabling login window clock d… |
Der Flounder 
Thanks for these great tips, Der Flounder! It’s been a while since I’ve last checked in with FV2, saddened to see that Yosemite FV2 has not added uname field/passwd field functionality. Any insights here?
The username / password blanks issue is a tough problem, since the FV 2 pre-boot login is running in EFI before the OS comes up. The last time I had an opportunity to directly ask the relevant engineers at Apple about it was during WWDC 2013 and the response I received at that point was that providing username and password blanks, in place of the current arrangement , was impossible. We’ll just have to see if it stays impossible.
There is a way to disable the automatic login between the FileVault 2 login and the user’s account though, so that the user gets stopped at the OS’s login window. At that point, you can get username and password blanks due to the fact that the OS is up and running at that point. Apple has a KBase article on disabling the automatic login available here: http://support.apple.com/en-us/HT202842
The guest account presence is linked to the activation of this specific account in the users preference pane (at least on my mac). If it’s disabled, it doesn’t show up anymore in the preboot environnement.
The following question concerns an odd event that occurs on my 10.10.x system where I have enabled FileVault. As soon as I enter credentials to unlock FileVault, there is a momentary flash of ERROR messages before that is replaced with the standard boot log (e.g., “sudo dmesg” to review the contents)
My goal is to find the log file that holds these ERROR messages so that I can decide if there is a problem that needs further attention or not.
I managed to use an iPhone 6Plus’s burst mode to get pictures of the errors. What follows is a partial list of the text that I’m seeing in that flash of the display (each line is incomplete):
“**** ERROR ArchiveCreateFromRootWithPatch”
“**** ERROR LWCreateLocalizedArchiveAdv”
“**** ERROR _CreateMenuWithWithIdentifier”
“**** ERROR _LW__PositionUsersCarouselViews”
“**** ERROR LWOpenFileAtPathWithRootFile”
“**** ERROR ArchiveViewCreateWithOptions”
“sudo dmesg | grep ArchiveCreateFromRootWithPatch” returns nothing. Casual use of ‘grep’ on all files in /var/log to match any of the strings above is not resulting in a hit.
QUESTION :
I’m pretty confident the ERRORs are while the FileVault is preparing its handoff of the filesystem. Where does FileVault write its log files?
act8chase,
To the best of my knowledge, the kind of logs you’re looking for don’t exist. When you log in at the FileVault 2 pre-boot login screen, it’s unlocking the encrypted volume which allows the OS to boot. That unlocking is taking place while the Mac is booted into the EFI environment, so the normal logging tools aren’t up and running. Once the disk is unlocked, the OS takes over and starts logging, but anything from before that time isn’t going to be logged because the OS’s logging tools themselves need to start before they can start recording anything.
Were you ever able to solve this problem? I’m having the same error message and I’m totally clueless due to missing logs.
Look to rtrouton’s response of February 25, 2015 — his answer made sense to me.
Thank you, Rich for an excellent write-up. We’re currently using AD with Filevault 2. We’re stumped at one problem — when an AD user forgets his/her password, the Recovery Key will only take them as far as the OS X login window — and they can’t reset their password or go any further (when not on the network). With a truly local account, the Recovery Key would allow them to change their password. Do you have any knowledge of how to get an AD user to their desktop if they a) forgot their password, and b) have their recover key, and, c) are not connect to the network — disconnected from AD)?
-David
David,
The answer in this case is going to be the same for both an encrypted and unencrypted laptop. If the person in question can’t remember what their AD password is at the login screen, they won’t be able to log in until a) they remember it or b) it’s changed in AD at a time when the Mac is able to communicate with AD.
Thanks, Rich. If this is not technically a bug, there’s some strange behavior. One is that the loginwindow *does* prompt to change the password, but the dialog box doesn’t respond, even if the computer is connected to AD. I think it should be smart enough to know that it’s a mobile account and a) should either change the password, or b) not present the ‘change password’ box at all — since it’s broken. The fact that it works for a completely local user made me think it might also work for a mobile user. Too bad.
I should have added that these AD accounts are set up as Mobile accounts on the computer.
Unfortunately, that does not make a difference.
Hi! Great article. Just a note: I’m unable to run the above “touch” command on El Capitan to set the login text. Any hints on how to set the message on the pre-boot screen on the new OS X version? TIA!
I’m also having issues with setting the FileVault 2 pre-boot login screen text… We’re updating to OS X 10.11 and need to change both the ‘regular’ login screen text and the pre-boot/ EFI-defined text, which now are different. Any ideas on how to do this, since ‘touch’-ing the EFILogin.framework is now denied? Thanks as always, Rich!
SIP put the kibosh on the “touch” method for El Capitan, but there is another method which I’ve tested and I’ve verified still works. I have a post on it here:
Hi Rich,
Thank you so much… you are correct — removing the /EFILoginLocalizations/*.efires files caused the pre-boot FV login screen to update to the more-recent settings. As always, your help is invaluable.
Hi there, sorry for resurrecting an old post – I thought this might be the most appropriate place for my question.
I want to have different passwords for FileVault and admin account. I’ve encrypted the boot drive of my OS X 10.11.1 Macbook Pro with fdesetup – I’ve added some additional users too. The machine is operating fine.
When I try to change the password using diskutil cs I’m asked to enter the current password and the new password twice. I get an error -69886 though.
Any help is much appreciated as the internet is not very knowledgeable for this problem. Thanks again
How have you made all those screenshots without being logged in?
I am under a company directive to change the admin passwords on all our macs AAP. I’m trying to build a policy to change the local admin password that also includes that user’s filevault2 password. I see there is a built-in Casper option to change the local account password. The part I’m having difficulty is changing the FV2 password to match. We are using an Institution FV2 key that is installed on all Macs. The closest I’ve been able to get to changing the FV2 password for a given user is to remove the user from FV2 via:
fdesetup remove -user (this works)
then to add them back in with the new PW I can use:
fdesetup add -usertoadd
This works, but this requires me to enter an existing FV password then enter the password for the user I’m adding. The fdesetup man page says:
add -usertoadd added_username … | -inputplist [-verbose]
Adds additional FileVault users. A FileVault user password or
recovery key must be used to authenticate.
Is it possible to include the passwords in a text file or pass the info to the command some other way that doesn’t require it to be interactive? The man page says -inputlist. How do I built such a list? Would it still be interactive? I need to figure out how to push this out through Casper. I tried using
fdesetup enable -usertoadd -keychain
but it tells me that FileVault is already on.
Any help would be greatly appreciated.
I’ve just enabled Filevault 2 on Sierra, and the thing that is puzzling me is that after the required restart, FV2 seems do be enabled immediately, i.e. in system preferences, there is no progress, just finished (although my SSD is nearly full). Also no higher CPU or disk activity. Anybody else noticing this? Is this normal? Thanks.
This is a really interesting post. I came across it when searching for a way to prevent a filevault enabled mac from shutting down after 5 minutes of no activity at the login screen. Unfortunately, I have gone through all the pmset options in the terminal with nothing that appears to do this. I hope there is a configuration setting for this somewhere, and if anyone knows about it, I think you might. Any ideas?