MacOS – FileVault 2 Login Issues on OpenLDAP Network with Admin, Managed, Mobile Account on Lion 10.7.4

authenticationbugfilevaultldapmacos

This issue occurs on any machine with Lion in my environment. I install Lion and connect to OpenLDAP for authentication. I enable FileVault.

Some users were reporting that when they'd wake their computer from sleep or reboot, the only available account to unlock FileVault was Administrator (not their local cached OpenLDAP account any longer).

In an attempt to reproduce this issue, I shut down all network interfaces on my test MacBook Pro and rebooted — sure enough FileVault will only allow me to unlock my hard drive by using the Administrator password, just as it occurred for my users.

Also, when I tried to check to see if my user account was still enabled in FileVault (by accessing System Preferences -> Security & Privacy), System Preferences crashes.

I found a workaround that sometimes works: Open any other System Preferences pane (for example, Users & Groups), and authenticate by clicking the lock icon. Then click Show All to go back to the main System Preferences UI, and access Security & Privacy again. It will work. In the FileVault tab, the text "Some users are not able to unlock this disk" appears (presumably my Admin, Managed, Mobile Account). I click on the "Enable Users" button and it brings up a dialog, but in this dialog my user account is the only one listed, and it has a green checkmark badge, as though it's set up properly (even when it isn't). If I click the "Done" button here, it appears to process something for a moment. If I reboot after doing this, it works, and I'm able to authenticate as myself.

I think what is happening here is that the network is shutting down on MacBooks that are in sleep mode or shut down, and FileVault is then removing any accounts that authenticate with LDAP from the Enabled Users. I presume something is broken too here, due to the crash that happens when trying to investigate the FileVault configuration.

Steps to Reproduce

Install Lion.
Connect to my OpenLDAP server.
Enable FileVault 2, enable LDAP-authenticated user to unlock FileVault.
Reboot.
It works!
Log in, and disable network interfaces, with the goal of forcing Lion to use the cached LDAP credentials for user authentication in FileVault.
Reboot.
The only user that is available for authentication is Administrator.
After logging in as Administrator, then logging out, and logging back in as the LDAP-auth'd user, I try to access System Preferences -> Security & Privacy. This causes System Preferences to crash with the crash dump pasted below. The only way to prevent this crash is to authenticate by clicking the lock icon on any other System Preferences pane (e.g. Users & Groups), then click "Show All", then click "Security & Privacy" again. This time it will work. Details are noted in the above Summary section of this bug report.

Expected Results

I would expect FileVault 2 authentication to work for the user it is originally set up under.

Actual Results

This isn't happening, and the users end up not able to unlock their machine (and thus, can't work without me (the sysadmin) coming over and unlocking their machine as Administrator, then logging out and letting them log into OS X under their account). I have filed a bug report with Apple, but heard nothing from them. I'm going to get in touch with phone support to see if it is of any use, but I'm curious if anyone here has encountered and somehow overcome these issues.

Notes

Here is the crash log produced when trying to access Security & Privacy after the issue occurs:

http://pastebin.com/2ewfZCUP

Best Answer

FileVault 2 uses the GeneratedUID user attribute to save who is permitted to unlock an encrypted volume. If the GeneratedUID of a user differs from what was generated (or pulled from LDAP) when FileVault 2 was enabled, the user will not be permitted to unlock the machine, as their account will appear to be unavailable at the EFI menu. Also, this causes the crash of System Preferences on their Mac whenever they try to access the Security & Privacy prefpane.

This problem arises when /usr/bin/mcxrefresh runs and pulls a null value or a value different than what is stored locally from LDAP (if the attribute isn't defined for the user in question or is defined incorrectly, respectively), overwriting the GeneratedUID stored locally (which is generated and only stored locally when FileVault 2 is enabled without a matching LDAP attribute).

In other words, if an apple-generateduid value exists in LDAP for a user and is mapped properly on the users Mac to the GeneratedUID attribute, FileVault 2 will not generate a new value, but will instead use the value stored in LDAP.

I was able to resolve this issue by adding an attribute called apple-generateduid to the LDAP entry of any user experiencing this issue. I could generate a random value for this attribute in Python by running the following one-liner from my terminal:

python -c 'import uuid; print str(uuid.uuid4()).upper();'

This isn't the only step, however. You must also add a mapping for this attribute on the client side. This is easily done using the following steps:

Open System Preferences.
Click Users & Groups.
Click Login Options.
Click on the Unlock Icon.
Under Network Account Server, click Edit.
Click to highlight your directory server.
Under Services, double-click on your directory service (in my case, it was LDAPv3)
In the window that slides open, highlight your configuration name, and then click the Edit... button.
Under Search & Mappings scroll down and single-click on Users to highlight it.
Click the Add button (the left one).
Choose GeneratedUID from the list of available Attribute Types.
In the right column, click the Add button, and type apple-generateduid. Click OK to save the changes until you're back at the main System Preferences dialog.
At this point a mapping from GeneratedUID to apple-generateduid has been created. Now when OS X looks up the GeneratedUID value it will get the value of apple-generateduid from the user in questions LDAP entry.

Finally, it's important that the locally stored value of GeneratedUID and value stored on LDAP match. Run the following command and make sure the two GeneratedUID values match:

dscl /Search search /Users GeneratedUID $(dscl . read /Users/$(echo $USER) GeneratedUID | cut -d " " -f2)

Encrypt the startup volume with Core Storage without FileVault

Two days after I added this answer, Apple published a technical white paper: Best Practices for Deploying FileVault 2 – Deploying OS X Full Disk Encryption Technology (PDF). At a glance, some of what I describe below seems to be described by Apple as:

Disk Password—based DEK.

Preparation

Backup
start Recovery OS
use Disk Utility to erase the startup volume – Mac OS Extended (Journaled, Encrypted)
restore
give the passphrase for the volume to AdminGuy.

Hint

At step 4 above, use a method that preserves the Apple_Boot slice (sometimes named Boot OS X, sometimes named Recovery HD) whilst restoring the JHFS+ startup volume.

To validate this answer, I used Disk Utility for that step. (I'm less familiar with restoration capabilities of Time Machine.)

The resulting EfiLoginUI:

As Disk Password has an avatar/icon, it's clear that Apple considers scenarios such as this.

Normal use thereafter

Alongside named users, EfiLoginUI presents Disk Password
AdminGuy can select Disk Password
AdminGuy can enter the passphrase to unlock the CoreStorage-protected startup volume
when loginwindow appears, select the required user.

Users may change their login passwords. The phrase for Disk Password will remain unchanged.

You need not use the FileVault areas of System Preferences but if you do, most things work as expected.

The machine pictured above is perfectly clean, restored from a Mountain Lion template that I created following installation of the OS (at the Welcome screen I shut down, then used Disk Utility to image all partitions/slices of the disk). I proceeded to create a user, then enabled that user for FileVault:

The resulting EfiLoginUI – one named user alongside the Disk Password option:

Appearance bug

System Preferences in Build 12A269 of OS X 10.8 may state that FileVault is enabled, with a recovery key set, when the key is no longer applicable. (Assume that an erased volume, with a possibly different passphrase, will not accept a recovery key that was set before erasure. A more definite opinion may be drawn from Infiltrate the Vault: Security Analysis and Decryption of Lion Full Disk Encryption (2012).) I have reported bugs to Apple.

Photographs above are of the USB flash drive that I used to validate this answer.

Photographs below are of the internal drive that I use every day.

EfiLoginUI – two named users enabled for FileVault, the Disk Password option, and the Guest User:

loginwindow – all named users:

my everyday loginwindow

How to disable unlock with Apple ID in Mountain Lion when FileVault is enabled

I haven't tried this with an Apple ID but in general you can add/remove users from the list using the fdesetup command. For example, to delete the user 'bill':

sudo fdesetup remove -user bill

You can use the following to see which users can unlock the disk:

sudo fdesetup list