JAMF Software has posted the session video for my Managing FileVault 2 on OS X Mountain Lion with the Casper Suite session from JAMF Nation User Conference 2012. For those interested, there’s a streaming version of the video available here on the JAMF News site.
For offline viewing, a high-res version is also available.
Credant has added support for managing FileVault 2-encrypted Macs to Credant Enterprise Edition for Mac 7.5.x. Based on my working with it over the past couple of weeks, it looks like a solid solution for managing FileVault 2 encryption on both 10.7.x and 10.8.x. For more details, see below the jump.
Enterprise console
On the enterprise console’s end, you will need to set the Shield for Mac security policy so that the Encrypt Using FileVault for Mac setting is set to True. The Volumes Targeted for Encryption setting should also be set to System Volume Only. (Both settings are outlined below in red).
Once both changes have been made, commit the policy so that it applies. In my case, I set this on the Default Security Settings, since all the Mac clients I was testing would be encrypted with FileVault 2.
Client encryption
On both 10.7.x and 10.8.x, Credant leverages Apple’s native tools for enabling FileVault 2, which can affect how the encryption is enabled.
On 10.7.x, Credant leverages Universal Access‘ access for assistive devices to open System Preferences and walk the user through enabling FileVault 2 though the FileVault preference pane. This means that the user account that is logged in will need to have admin rights, as the FileVault preference pane requires an admin account’s password to unlock.
On 10.8.x, Credant is using fdesetup to enable FileVault 2. That removes the need for the logged-in user to have admin rights, as the Credant client software can launch fdesetup with root privileges. All the logged-in user will need to provide when prompted is their account’s password.
To show how the process works, I’ve made a video showing the client installation on 10.8.2, registration with the Credant enterprise server using an Active Directory login, and subsequent encryption.
Note: The video has been edited to artificially reduce the amount of time needed for the process and to also remove an installer screen showing the addresses of the Credant server and AD domain.
Run time of the pre-edited video was 12 minutes, 5 seconds.
FileVault 2 Recovery
On both 10.7 and 10.8, Credant’s recovery key solution utilizes the institutional recovery key. Based on my testing, it appears that Credant is generating a FileVaultMaster keychain for each individual machine, rather than setting up one key and sharing it across multiple machines.
From what I’m seeing, it appears that the Credant software does the following to the client Macs:
1. Builds a FileVaultMaster.keychain institutional recovery key for each machine and stores it on the server.
2. Puts a copy of the FileVaultMaster.keychain file with only the public key in the client Mac’s /Library/Keychains directory
3. Initializes encryption on the Mac
4. Restarts the Mac
5. Deletes the FileVaultMaster.keychain file from the Mac’s /Library/Keychains directory
When you need to do recovery on the machine, you would login to the Credant console and access the endpoint listing for the FileVault 2-encrypted Mac. In the endpoint listing, there is a Device Recovery Keys link (outlined below in red).
When you click the Device Recovery Keys link, it will download a .csv file from the Credant console.
To do the recovery, you would run the .csv file through the CREDANT Recovery Utility application (provided with the Credant install media.)
The CREDANT Recovery Utility will then use the information in the .csv file to pull down a couple of scripts, the correct recovery keychain and text files containing the UUID of the encrypted drive and the password for the recovery keychain. These should be stored on an external USB drive.
At that point, you would boot to the Mac’s Recovery HD partition with the USB drive connected to the Mac and run the applicable script (one script is for unlocking the encrypted volume and the other script is for decrypting the encrypted volume.)
The chosen script will run the appropriate action, using the unlock / decrypt procedure that I’ve described in my earlier post on unlocking / decrypting a FileVault 2 encrypted Mac from the command line.
Since the release of Google’s Cauliflower Vest, one of the wishlist items that a number of Mac admins have wanted is to use Cauliflower Vest’s capabilities without needing to use Google App Engine as the server backend. Crypt, a new open-source project being developed by Graham Gilbert, looks like a step in the right direction. See below the jump for details.
Like Cauliflower Vest, Crypt is designed to:
Crypt comes in two parts. Crypt is a client application that would be installed on your Mac(s). Crypt-Server is a Django web app that receives and stores the escrowed FileVault 2 recovery keys.
Prep work
Before starting with anything else, I set up an Ubuntu 12.0.4 LTS server to act as the Crypt-Server key escrow server. Crypt should be able to run on anything that supports Python and Django, but the Crypt-Server setup instructions assume that the host OS is Ubuntu 12.0.x LTS.
Setting up the Crypt-Server software
Installing the foundation software
1. Log into the Ubuntu server using an account that has sudo privileges
2. Check to see if git is installed on the Ubuntu server by running the following command.
which git
3. If git is not installed, install it by running the following command:
sudo apt-get install git
4. Following the installation of git, install the Python setup tools
sudo apt-get install python-setuptools
5. After installing the Python setup tools, check to see if virtualenv is installed. virtualenv is a tool to create isolated Python environments and it’s used by Crypt-Server.
To check for virtualenv, run the following command:
virtualenv –version
6. If virtualenv is not installed, install it using the following command:
sudo easy_install virtualenv
7. Once installed, verify that virtualenv is now installed by running the following command:
virtualenv –version
Creating a non-admin service account and group for Crypt-Server
8. Create the Crypt cryptuser service account by running the following command:
sudo useradd cryptuser
9. Create the Crypt cryptgroup group by running the following command:
sudo groupadd cryptgroup
10. Add the cryptuser service account to the cryptgroup group by running the following command:
sudo usermod -g cryptgroup cryptuser
11. Verify that the cryptuser service account is now a member of the cryptgroup group by running the following command:
id cryptuser
The gid and groups values should both report cryptgroup.
Create the Python virtual environment
Next, we’ll be using virtualenv to create a Python virtual environment for Crypt-Server. This will allow the Django software to be installed in a contained environment that won’t interfere with the system Python installation’s packages.
12. Change directories to /usr/local, as that’s where we’ll be installing the virtual environment, by running the following command:
cd /usr/local
13. Create the Python virtual environment for Crypt-Server by running the following command:
sudo virtualenv crypt_env
14. Give the cryptuser service account read and write access to the crypt_env virtual environment by running the following command:
sudo chown -R cryptuser crypt_env
15. Verify that the cryptuser service account is set as the owner of the crypt_env directory by running the following command:
ls -al
At this point, because we’ll be switching into the cryptuser service account and running it with a bash shell, it’s a good idea to use sudo to drop into a root shell first. That will simplify the various account and shell switching we’ll need to do because the root user has total access to the system.
16. To switch to a root shell, run the following command:
sudo -s
17. Switch to the cryptuser service account by running the following command:
su cryptuser
18. The virtualenv tool is expecting to be run from bash, so switch to a bash shell by running the following command:
bash
19. Change directories to the crypt_env directory by running the following command:
cd crypt_env
20. Activate the virtual environment by running the following command:
source bin/activate
21. Install Django in the virtual environment by running the following command:
pip install django
22. Install South in the virtual environment by running the following command:
pip install south
23. Install the Django Bootstrap Toolkit in the virtual environment by running the following command:
pip install django-bootstrap_toolkit
Installing Crypt-Server from Github and configuring it
At this point, all the software that Crypt-Server runs on has been installed, so it’s time to install the actual Crypt-Server software and configure it.
24. While still inside the crypt_env virtual environment, use git to clone the current version of Crypt-Server by running the following command:
git clone https://github.com/grahamgilbert/Crypt-Server.git crypt
25. Change directories to the fvserver directory inside of the newly-cloned crypt directory by running the following command:
cd crypt/fvserver
26. Copy the example_settings.py sample configuration file to a new settings.py file by running the following command:
cp example_settings.py settings.py
The settings.py file is used by Crypt-Server to store its config settings.
27. Open settings.py for editing by using the following command:
nano settings.py
While in settings.py, edit the following settings:
Set ADMINS to an administrative name and email
Set TIME_ZONE to the appropriate timezone
See the screenshots below for how I edited mine.
Initializing the Django database and creating an admin user
28. Change directories to the crypt directory by running the following command:
cd /usr/local/crypt_env/crypt
29. Initialize the the Django database by running the following command:
python manage.py syncdb
When prompted, create an admin user.
I used cryptuser for mine.
29. Migrate the database by running the following command:
python manage.py migrate
30. Stage the static files by running the following command:
python manage.py collectstatic
When prompted about overwriting existing files, type yes.
31. Exit out of the virtual environment. To do this, type exit at the prompts until you’re back at the root@servername prompt.
Web Server setup
To run Crypt in a production environment, a webserver needs to be setup and configured. Ubuntu uses Apache, so we’ll be using that. The Apache libapache2-mod-wsgi module will need to be installed in order to allow Django to communicate correctly with Apache.
32. Install libapache2-mod-wsgi by running the following command:
apt-get install libapache2-mod-wsgi
Creating an Apache virtualhost
The term “Virtual Host” refers to the practice of running more than one web site on a single machine. Since Crypt-Server may not be running on a dedicated server, it’s a good idea to set up an Apache virtualhost for Crypt-Server.
To set up a new virtualhost for Crypt-Server on Ubuntu, make a new file called crypt.conf at /etc/apache2/sites-available. You can do this by running the following command:
nano /etc/apache2/sites-available/crypt.conf
Here’s an example virtualhost that accepts connections from any IP on port 80:
<VirtualHost *:80>
ServerName crypt.yourdomain.com
WSGIScriptAlias / /usr/local/crypt_env/crypt/crypt.wsgi
WSGIDaemonProcess crypt user=cryptuser group=cryptgroup
Alias /static/ /usr/local/crypt_env/crypt/static/
<Directory /usr/local/crypt_env/crypt>
WSGIProcessGroup crypt
WSGIApplicationGroup %{GLOBAL}
Order deny,allow
Allow from all
</Directory>
</VirtualHost>
Final stretch
Once the virtualhost file has been created, the last part will be configuring a .wsgi file to to get our Django-powered Crypt-Server site running under Apache.
33. Switch back to the cryptuser service account by running the following command:
su cryptuser
34. Switch to a bash shell by running the following command:
bash
35. Running the following command to create a new crypt.wsgi file inside /usr/local/crypt_env/crypt/:
nano /usr/local/crypt_env/crypt/crypt.wsgi
The crypt.wsgi file should have the following contents:
import os, sys
import site
CRYPT_ENV_DIR = '/usr/local/crypt_env'
# Use site to load the site-packages directory of our virtualenv
site.addsitedir(os.path.join(CRYPT_ENV_DIR, 'lib/python2.7/site-packages'))
# Make sure we have the virtualenv and the Django app itself added to our path
sys.path.append(CRYPT_ENV_DIR)
sys.path.append(os.path.join(CRYPT_ENV_DIR, 'crypt'))
os.environ.setdefault("DJANGO_SETTINGS_MODULE", "fvserver.settings")
import django.core.handlers.wsgi
application = django.core.handlers.wsgi.WSGIHandler()
36. Enable the crypt.conf virtualhost configuration by running the following command:
a2ensite crypt.conf
37. Restart Apache and have it re-read its configuration settings by running the following command:
service apache2 reload
38. Verify that you can access the Crypt server website by going to your server’s DNS address in a web browser.
Setting up the Crypt client
Once the server end is set up, it’s time to set up the client end. The Crypt project folks have a pre-made Crypt_Client.pkg installer available at the following location:
https://github.com/grahamgilbert/Crypt/raw/master/Build/Crypt_Client.pkg
The Crypt client will need to be launched by some outside source. The Crypt project folks recommend using a loginhook for this. I used their pre-written loginhook script and it worked well for my test setup.
Encrypting the Mac using Crypt
To set up your Mac to be encrypted, you’ll need to install the Crypt installer package, set the location of your Crypt server and also set up your loginhook.
To set the location of the Crypt server for the Crypt client, I ran the following command:
sudo defaults write /Library/Preferences/FVServer ServerURL "http://crypt.domain.com"
Once the server location was set, I stored my loginhook script in /Library/Scripts and named it filevault.sh.
Next, I ran the following command to set my loginhook:
sudo defaults write com.apple.loginwindow LoginHook /Library/Scripts/filevault.sh
Last, but not least, I installed the Crypt client software in my test VM.
Once the software was installed, I restarted my VM and then logged in with my rtrouton account at the login screen. This triggered the loginhook to run /Library/Scripts/filevault.sh.
The script detected that my Mac was not encrypted, so the Crypt warning came up and I was then prompted to authenticate
After authenticating, Crypt initialized FileVault 2 encryption on my Mac and automatically restarted it.
On restart, my rtrouton account was enabled and showed up at the FileVault 2 pre-boot login screen
I logged in at the pre-boot login screen with my account credentials and the boot process continued.
Once my desktop came up, I checked the FileVault preference pane and saw that encryption was proceeding normally.
Getting my recovery key
Since encryption is only half of what I want to accomplish here, I went next to my Crypt website to get my Mac’s recovery key.
After authenticating with the cryptuser account’s username and password, I was given access to a listing for my encrypted Mac with the recovery key displayed.
Wrap up
Overall, I’m happy with what I’m seeing so far with Crypt. It’s not ready for production as it stands, but it works as advertised and I was able to get it running by following the directions on the wiki. As a work in progress, the project itself shows a lot of promise.
One of the new features that appeared with Macs that shipped with Lion and Mountain Lion 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 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. It should say something like “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 it’s fully booted.
Once booted to Internet Recovery, you should see the Recovery interface.
From there, you use the methods described in the links below to unlock or decrypt your FileVault 2 encrypted Mac:
Using Disk Utility to unlock or decrypt your FileVault 2-encrypted boot drive
Unlock or decrypt your FileVault 2-encrypted boot drive from the command line
I’ve updated the FileVault 2 status check scripts so that they’re now able to correctly handle unencrypted Fusion drives. The scripts should now report accurately on 10.8.x Macs that use Fusion drives, as well as other 10.7.x and 10.8.x Macs.
The changes are now available as part of my regular script. They have also been rolled into both the Casper Extension Attribute and the Absolute Manage Custom Info Item scripts. Use them in good health and please let me know if you find any problems with them.
For those who wanted a copy of my FileVault 2 talk at MacIT 2013, here are links to the slides in PDF and Keynote format.
PDF: http://tinyurl.com/MacIT2013PDF
Keynote slides: http://tinyurl.com/MacIT2013key
I recently communicated with a Mac admin who was concerned about using FileVault 2 in his environment because he didn’t want to lose access to tools like single-user mode. Like a number of Mac admins, he’d 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.
To show what this looks like, I’ve made a short video showing the process. In this instance, I booted into single-user mode and performed a disk check using fsck, then continued with the rest of the boot process.
I was recently asked to help test a new utility called FileVault Setup for setting up and enforcing FileVault 2 encryption. It’s designed to be a user-friendly interface for Apple’s fdesetup tool on OS X 10.8.x which supports turning on FileVault 2 encryption and enabling a single user account.
One nice thing about this tool from my perspective is that it’s designed to be independent of any server-based resources. To the best of my knowledge, this is the first tool I’ve seen that allows FileVault encryption to be enforced on a machine entirely from the machine’s own resources. See below the jump for the details.
Building
You can build the latest version of the application using the Xcode project files available from the GitHub repository. There’s also a already-built application available for download from the GitHub repo.
Installation
This application can be installed anywhere on the Mac, though the GitHub project page recommends either /Applications or /Applications/Utilities. For the purposes of my testing, I put it into /Applications.
If you want to hide the application from your users, I’d recommend putting it into a location like /var/root.
Operation
The application was designed to be run by a Mac OS X loginhook. This allows it to be launched when a user logs in, but also runs the application with root privileges. Running this application with root privileges is important because fdesetup requires root privileges to run.
Since this is a process that’s more easily shown than explained, I’ve made a video showing the process from the user’s perspective.
Note: The video has been edited to artificially reduce the amount of time it took to encrypt. Run time of the pre-edited video was 9 minutes.
Management
The application has four command line switches that can be used to tell it how to run:
-FVSDoNotAskForSetup YES / NO – suppresses prompting the user to enable FileVault 2 encryption. The default is NO
-FVSForceSetup YES / NO – Sets the FileVault 2 encryption to use /Library/Keychains/FileVaultMaster.keychain as an institutional recovery key. The default is NO
-FVSUseKeychain YES / NO – Sets the FileVault 2 encryption to use /Library/Keychains/FileVaultMaster.keychain as an institutional recovery key. The default is YES
-FVSCreateRecoveryKey YES / NO – Sets the FileVault 2 encryption to generate and use an alphanumeric individual recovery key. The default is YES
FileVault Setup can also be managed by MCX or by the defaults command. FileVault Setup accepts four defaults:
FVSDoNotAskForSetup: suppresses prompting the user to enable FileVault 2 encryption, default is NO / FALSE
FVSForceSetup: Sets the FileVault 2 encryption to use /Library/Keychains/FileVaultMaster.keychain as an institutional recovery key, default is NO / FALSE
FVSUseKeychain: Sets the FileVault 2 encryption to use /Library/Keychains/FileVaultMaster.keychain as an institutional recovery key, default is YES / TRUE
FVSCreateRecoveryKey: Sets the FileVault 2 encryption to generate and use an alphanumeric individual recovery key, default is YES / TRUE
The settings are stored in the following domain: ca.sfu.its.filevaultsetup
Running FileVault Setup without any command line switches or other management will mean it will run with the following configuration:
/path/to/FileVault\ Setup.app/Contents/MacOS/FileVault\ Setup -FVSDoNotAskForSetup NO -FVSForceSetup NO -FVSUseKeychain YES -FVSCreateRecoveryKey YES
In this case, FileVault 2 encryption set up is not forced. For the recovery keys, FileVault Setup will have fdesetup both generate an alphanumeric individual recovery key and set /Library/Keychains/FileVaultMaster.keychain as an institutional recovery key.
Recovery Keys
As mentioned above, in its default configuration FileVault Setup will try to set up two recovery keys by using a properly configured /Library/Keychains/FileVaultMaster.keychain as the institutional recovery key and also generate an alphanumeric individual recovery key.
To make sure that the individual recovery key is recorded for later reference, FileVault Setup will generate a plist file containing the individual recovery key and store it in the following location:
/private/var/root/fdesetup_output.plist
The plist itself will look similar to this:
<?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>EnabledDate</key> <string>2013-04-29 22:17:00 -0400</string> <key>HardwareUUID</key> <string>00000000-0000-1000-8000-000C29CEF923</string> <key>HasMasterKeychain</key> <true/> <key>LVGUUID</key> <string>9807169C-24E6-4DDC-975A-71D078D73390</string> <key>LVUUID</key> <string>2BF1F4CA-5E97-4A6B-820A-A87F1DEA5B1D</string> <key>PVUUID</key> <string>0B0DE25B-8D24-4E31-B1B0-0831455C3A65</string> <key>RecoveryKey</key> <string>QFDA-9W5V-K2W3-93MR-Y7T8-DPZ5</string> <key>SerialNumber</key> <string>VMWVk2F+NYrG/tkLIignnJaiw</string> </dict> </plist>
If you want to use only the institutional recovery key, you would need to ensure that there is a properly configured FileVaultMaster.keychain stored in /Library/Keychains, then use FVSUseKeychain YES and FVSCreateRecoveryKey NO:
Example command:
/path/to/FileVault\ Setup.app/Contents/MacOS/FileVault\ Setup -FVSUseKeychain YES -FVSCreateRecoveryKey NO
If you want to use only the individual recovery key, you would need to ensure that there is not a FileVaultMaster.keychain stored in /Library/Keychains, then use FVSUseKeychain NO and FVSCreateRecoveryKey YES.
Example command:
/path/to/FileVault\ Setup.app/Contents/MacOS/FileVault\ Setup -FVSUseKeychain NO -FVSCreateRecoveryKey YES
Testing FileVault Setup
My testing was focused on forcing FileVault 2 encryption and using the command-line switches to tell FileVault Setup what to do. As part of that, I set up the following loginhook:
#!/bin/sh
FVSETUP=/path/to/FileVault\ Setup.app/Contents/MacOS/FileVault\ Setup
DISKUTIL="/usr/sbin/diskutil"
LOGGER="/usr/bin/logger"
# check_encryption_state taken
# from the Cauliflower Vest wiki's
# loginhook script:
# http://code.google.com/p/cauliflowervest/wiki/LoginHook
check_encryption_state() {
${DISKUTIL} cs list | grep -q -e 'Conversion\ Status.*Pending'
if [[ ${?} -eq 0 ]]; then
${LOGGER} "Disk encryption pending, skipping."
exit 0
fi
${DISKUTIL} cs list | grep -q -e 'Conversion\ Status.*Complete'
if [[ ${?} -eq 0 ]]; then
${LOGGER} "Disk encryption complete, skipping."
exit 0
fi
${DISKUTIL} cs list | grep -q -e 'Conversion\ Status.*Converting'
if [[ ${?} -eq 0 ]]; then
${LOGGER} "Disk encrypting or decrypting, skipping."
exit 0
fi
}
# If the FileVault Setup binary is present,
# proceed with encryption. If not, exit the
# script.
if [[ ! -f "$FVSETUP" ]]; then
${LOGGER} "FileVault Setup not installed on Mac in specified location"
exit 0
fi
if [[ -f "$FVSETUP" ]]; then
${LOGGER} "FileVault Setup present on Mac"
# Check to see if the Mac is encrypted
# or already encrypting. The application
# also checks for this, but I added this
# to help speed up the loginhook script's
# end if needed
check_encryption_state
# Replace YOUR_LOCAL_ADMIN_ACCOUNT with
# an account that you want to be able
# to login to the Mac without triggering
# the encryption to run.
if [[ $1 == "root" || $1 == "YOUR_LOCAL_ADMIN_ACCOUNT" ]]; then
${LOGGER} "Exiting encryption setup for user account: $1"
exit 0
else
# If the Mac isn't encrypted, run FileVault Setup
"${FVSETUP}" -FVSForceSetup YES -FVSOptionsHere
${LOGGER} "Enabling encryption on this Mac."
fi
else
exit 0
fi
While I used this login hook for my testing, I also tried a much simpler loginscript:
#!/bin/sh /path/to/FileVault\ Setup.app/Contents/MacOS/FileVault\ Setup -FVSForceSetup YES
I was able to replicate my earlier encryption results, but the pause at the loginwindow (for the loginhook script to run) was a few seconds longer.
From my testing, here’s the commands that will worked along the ones that will generate errors. The errors will be coming from fdesetup or CoreStorage and are the result of FileVault Setup being asked to initialize an unsupported FileVault 2 configuration:
Successful FileVault 2 enablement
With no recovery keychain in /Library/Keychains, FileVault Setup forced FileVault 2 enablement and generated an individual recovery key as the Mac’s only recovery key with the following command:
/path/to/FileVault\ Setup.app/Contents/MacOS/FileVault\ Setup -FVSForceSetup YES -FVSUseKeychain NO -FVSCreateRecoveryKey YES
With FileVaultMaster.keychain stored in /Library/Keychains, FileVault Setup forced FileVault 2 enablement and set the FileVaultMaster.keychain as the Mac’s only recovery key with the following command:
/path/to/FileVault\ Setup.app/Contents/MacOS/FileVault\ Setup -FVSForceSetup YES -FVSUseKeychain YES -FVSCreateRecoveryKey NO
With FileVaultMaster.keychain stored in /Library/Keychains, FileVault Setup forced FileVault 2 enablement and set both the FileVaultMaster.keychain and an individual recovery key with the following command:
/path/to/FileVault\ Setup.app/Contents/MacOS/FileVault\ Setup -FVSForceSetup YES
With FileVaultMaster.keychain stored in /Library/Keychains, FileVault Setup forced FileVault 2 enablement and set the FileVaultMaster.keychain as the Mac’s only recovery key with the following command:
/path/to/FileVault\ Setup.app/Contents/MacOS/FileVault\ Setup -FVSForceSetup YES -FVSCreateRecoveryKey NO
Unsuccessful FileVault 2 enablement
With FileVaultMaster.keychain stored in /Library/Keychains, FileVault Setup gave a fdesetup error 18 with the following command:
/path/to/FileVault\ Setup.app/Contents/MacOS/FileVault\ Setup -FVSForceSetup YES -FVSUseKeychain NO
With no recovery keychain on the Mac, FileVault Setup gave a fdesetup error 19 with the following command:
/path/to/FileVault\ Setup.app/Contents/MacOS/FileVault\ Setup -FVSForceSetup YES -FVSUseKeychain YES -FVSCreateRecoveryKey NO
With no recovery keychain on the Mac, FileVault Setup gave a fdesetup error 19 with the following command:
/path/to/FileVault\ Setup.app/Contents/MacOS/FileVault\ Setup -FVSForceSetup YES -FVSCreateRecoveryKey YES
With no recovery keychain on the Mac, FileVault Setup gave a fdesetup error 19 with the following command:
/path/to/FileVault\ Setup.app/Contents/MacOS/FileVault\ Setup -FVSForceSetup YES
With no recovery keychain on the Mac, FileVault Setup gave an error 15 with the following command:
/path/to/FileVault\ Setup.app/Contents/MacOS/FileVault\ Setup -FVSForceSetup YES -FVSUseKeychain NO -FVSCreateRecoveryKey NO
This last error is because FileVault Setup was being asked to set up FileVault 2 encryption without a recovery key. This does not work; you must have a recovery key when encrypting a Mac with FileVault 2.
Running FileVault Setup on an already-encrypted Mac
One of the nicer features of this application is that it can detect if the Mac has already been encrypted with FileVault 2. If it’s launched on a Mac that’s encrypted, it displays a message that FileVault 2 has already been enabled. Once you click the OK button to acknowledge the message, FileVault Setup then quits.
At the login window, FileVault Setup will not appear when triggered by the loginhook on an already-encrypted Mac. Instead, the app will silently quit in the background.
Conclusion
If you’re looking for a way to enforce FileVault 2 on your Macs and don’t have access to server resources, FileVault Setup is a great addition to your set of tools. It will give you the ability to encourage encryption on your machines or force it, depending on your security needs.
It also gives you the ability to prepare a machine and deploy it to your users without encrypting it first, as the loginhook will ensure that encryption gets turned on at the first login.
I’ll be speaking about FileVault 2 at the Penn State MacAdmins Conference 2013, which is being held from May 22nd – 24th, 2013 in State College. For those interested, my talk will be on Thursday, May 23.
For a description of what I’ll be talking about, please see the Managing FileVault 2 on Mountain Lion session description. You can see the whole list of speakers here on the Sessions page.
For those who wanted a copy of my FileVault 2 session slides from Penn State’s MacAdmins Conference 2013, here are links to the slides in PDF and Keynote format.
PDF document link: http://tinyurl.com/PSUMac2013PDF
Keynote slides link: http://tinyurl.com/PSUMac2013key
One of the changes noted in Apple’s security notes about 10.8.4 and Security Update 2013-002 was this section:
Disk Management
Available for: OS X Mountain Lion v10.8 to v10.8.3
Impact: A local user may disable FileVault
Description: A local user who is not an administrator may disable FileVault using the command-line. This issue was addressed by adding additional authentication.
CVE-ID
CVE-2013-0985
In short, this helps address an issue that has vexed various Mac admins since 10.7.0: If you have a FileVault 2-enabled account, you can decrypt the encryption from the command line using your account’s password.
With 10.8.4, the command-line diskutil tool has now been updated to request an administrator’s login and password before allowing decryption to proceed.
Administrators are also prompted, but can supply their account’s username and password to start the decryption process.
The good folks at Penn State have posted the session videos from the Penn State MacAdmins Conference 2013. The sessions slides and videos are all accessible from the Penn State MacAdmins’ Resources page at the link below:
http://macadmins.psu.edu/conference/resources/
As all the session videos have been posted to YouTube, I’ve linked my FileVault 2 session here:
To follow on to my earlier post about needing admin rights to decrypt FileVault 2 on Mac OS X 10.8.4, it appears that Mac OS X 10.8.4′s Recovery HD partition no longer can decrypt FileVault 2-encrypted Macs. If you boot from a 10.8.4 Recovery HD partition, you can unlock a FileVault 2-encrypted boot drive but you can’t decrypt it either from Disk Utility or the command line.
In Disk Utility’s File menu, Turn Off Encryption… is now grayed out. Unlock “Drive Name” is still an available option.
In Terminal, attempting to decrypt with diskutil with the following commands now results a The given UUID is not a CoreStorage Logical Volume UUID error.
diskutil cs revert UUID_here -stdinpassphrase
diskutil cs revert UUID_here -passphrase
diskutil corestorage revert UUID_here -recoveryKeychain /path/to/FileVaultMaster.keychain
Unlocking from the command line continues to work.
The fact that decrypting using the institutional keychain does not work is particularly worrying. To the best of my knowledge, the only way you can decrypt using the institutional keychain is by using Recovery HD or Internet Recovery. I’ve verified that booting from an alternate 10.8.4 boot drive gives the same behavior with regards to Disk Utility and the diskutil tool.
I’ve filed bugreports at bugreport.apple.com for these issues. For those who who want to submit duplicate bugs, they are bug IDs 14099380 and 14099359.
I’ve also posted the bug reports at Open Radar:
rdar://14099380 – Unable to decrypt using diskutil while booted from Recovery HD
rdar://14099359 – Unable to decrypt using Disk Utility while booted from Recovery HD
As a follow-up to my earlier post about not being able to decrypt FileVault 2 from the Recovery HD partition, it looks like Apple has changed the process for how decryption works. Previously, you could run a command to decrypt on a locked FileVault 2-encrypted boot volume and it would decrypt.
As of 10.8.4, it appears that Apple now requires that the encrypted volume be unlocked first. Once it’s unlocked, then you can decrypt. See below the jump for details.
Here’s how the new decryption procedure works for Disk Utility:
1. Boot your Mac and hold down ⌘-R (Command –R) to boot from the Mac’s Recovery HD partition.
Note: You can also boot from a 10.8.4 installer drive , boot to Target Disk Mode and connect it via Firewire or Thunderbolt to another Mac, or use some other 10.8.4-booting drive. As long as you have 10.8.4′s Disk Utility, this should work.
2. Open Disk Utility.
3. Select your locked hard drive.
4. Under the File menu, select Unlock “Drive Name”
5. When prompted for a password, you can enter the password of any authorized account on the drive.
6. Once you unlock the disk, hold down the Option key on your keyboard and click on the File menu.
7. Under the File menu, select Turn Off Encryption… (with the Option key held down, it’s no longer grayed-out.)
8. When prompted for a password, you can enter the password of any authorized account on the drive.
9. Disk Utility should briefly display a progress window labeled Starting conversion to JHFS+
Your drive should now start decrypting.
You should also be able to unlock then decrypt your Mac from the command line, using the procedures described in this previous post.
I tested specifically to see if the institutional recovery key using FileVaultMaster.keychain worked with the new unlock-first-then-decrypt method while booted from Recovery HD. As shown below, unlocking then decrypting using the institutional recovery key works fine.
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, you’ll see the user information appear with both the username and UUID information.
For local accounts, this isn’t an issue as the OS will properly generate 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 have heard of problems has been with non-Apple LDAP servers. If the LDAP server doesn’t provide the GeneratedUID user attribute for mobile LDAP accounts on Macs, 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:
1. 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 mobile LDAP account on the Mac. Stack Overflow has a good discussion about this issue that I recommend checking out for more details.
2. The account icon being present, but the password not matching the current password on the LDAP server – This behavior has been observed when the mobile LDAP account’s UUID does not match what FileVault 2 is expecting.
A good example of the latter behavior comes from a Mac admin who recently 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
They looked like this:
7c9afb0e-e06e-43fa-8e9f-1d410344d2aa
To the best of my knowledge at the time, alphabetical characters used in Mac UUIDs were all upper-case but I didn’t know for certain that the UUIDs were case-sensitive, so I recommended that he call AppleCare Enterprise support to see if they knew.
After checking with another colleague, who confirmed that Mac account UUIDs were both upper-case and case-sensitive, he changed a test account’s UUID to be all upper-case. At that point, FileVault 2 logins for that account began working properly.
Fixing this issue
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:
1. 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.
2. Ensure that all alphabetical characters listed in the the apple-generateduid value are upper-case.
Note: 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
There’s a couple of functions that you can enable on your Mac that will show up at the FileVault 2 pre-boot login screen. The two functions that I’m familiar with are the keyboard input menu and a text-only login banner.
On an FileVault 2-encrypted Mac, you can go into System Preferences and enable these functions. At the next restart, they should show up at the FileVault 2 pre-boot login screen. However, if these functions were enabled using the defaults command, they may show up at the regular login window, but not FileVault 2′s login screen.
The answer seems to be that, in addition to running the defaults commands, you also need to remove certain cache filenames ending in .efires from /System/Library/Caches/com.apple.corestorage/EFILoginLocalizations. Clearing the filename.efires cache files forces the system to update the FileVault 2 pre-boot login screen. Whether this update happens right away or when the system reboots is not yet clear; if you know, please let me know in the comments.
For example, running the following commands with root privileges updates the FileVault 2 pre-boot login screen with both the keyboard input menu and a login banner:
defaults write /Library/Preferences/com.apple.loginwindow LoginwindowText "My Login Window Text Goes Here" defaults write /Library/Preferences/com.apple.loginwindow showInputMenu -bool TRUE rm /System/Library/Caches/com.apple.corestorage/EFILoginLocalizations/*.efires
On restart, the FileVault 2 pre-boot login screen should look like this, with keyboard input and login text (highlighted in red) now showing.
To remove these, you would need to boot back into the OS and run the following commands:
defaults delete /Library/Preferences/com.apple.loginwindow LoginwindowText defaults write /Library/Preferences/com.apple.loginwindow showInputMenu -bool FALSE rm /System/Library/Caches/com.apple.corestorage/EFILoginLocalizations/*.efires
On restart, the FileVault 2 pre-boot login screen should no longer have either a keyboard input menu or a login banner.
Hat tip to Josh Schripsema for figuring out that the .efires cache files need to be removed to force the refresh.
On occasion, it’s necessary to erase a FileVault 2-encrypted volume. However, Disk Utility won’t let you erase or repartition 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. This includes the ability to erase encrypted CoreStorage volumes (aka FileVault 2-encrypted volumes) without first decrypting or unlocking them.
To do this, first run the following command:
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 it’s the one we want to delete.
Next, run the following command:
diskutil cs delete UUID_here
This will delete your CoreStorage volume and reformat it as an unencrypted HFS+ volume.
Apple announced on Friday, June 28th that the FIPS 140-2 validations for the cryptographic modules used by iOS 6 and OS X 10.8.x have now been completed. This is significant news for Mac admins who want to use FileVault 2 in government and regulated industries (such as financial and health-care institutions.)
For folks who haven’t heard of it before, FIPS 140-2 is an information technology security accreditation program run jointly by the US and Canadian governments. This program is used by private sector vendors to have their cryptographic modules certified for use in US and Canadian government departments and private industries with regulatory requirements for security.
As part of today’s announcement, Apple has released KBase articles, tools and guidance for security offices who deal with encryption:
Apple FIPS Cryptographic Modules v3.0 – http://support.apple.com/kb/DL1555
Mountain Lion: How to set up and maintain a FIPS-enabled system – http://support.apple.com/kb/HT5396
Crypto Officer Role Guide for FIPS 140-2 Compliance OS X Mountain Lion v10.8 – http://km.support.apple.com/library/APPLE/APPLECARE_ALLGEOS/HT5396/Crypto_Officer_Role_Guide_for_FIPS_140-2_Compliance_OS_X_Mountain_Lion_v10.8.pdf
FIPS Administration Tools v3.0 – http://support.apple.com/kb/DL1555
FileVault 2 is listed as being FIPS 140-2 Compliant as part of the Crypto Officer Role Guide for FIPS 140-2 Compliance OS X Mountain Lion v10.8 documentation, in the Compliant Applications and Services section.
For those who wanted a copy of my FileVault 2 session slides from MacSysAdmin 2013, here are links to the slides in PDF and Keynote format.
PDF document link: http://tinyurl.com/MacSysAd2013PDF
Keynote slides link: http://tinyurl.com/MacSysAd2013key
The documentation from MacSysAdmin 2013 is now available, with the session slides and videos being accessible from the link below:
http://documentation.macsysadmin.se
The video of my session is available for download from here:
http://docs.macsysadmin.se/2013/video/Day2Session5.mp4
I also like to thank Tycho Sjögren and Apoio AB again for inviting me to speak. I had a great time.
