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

Question

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

1. Install Lion.
2. Connect to my OpenLDAP server.
3. Enable FileVault 2, enable LDAP-authenticated user to unlock FileVault.
4. Reboot.
5. It works!
6. Log in, and disable network interfaces, with the goal of forcing Lion to use the cached LDAP credentials for user authentication in FileVault.
7. Reboot.
8. The only user that is available for authentication is Administrator.
9. 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

Answer 1

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:

1. Open System Preferences.
2. Click Users & Groups.
3. Click Login Options.
4. Click on the Unlock Icon.
5. Under Network Account Server, click Edit.
6. Click to highlight your directory server.
7. Under Services, double-click on your directory service (in my case, it was LDAPv3)
8. In the window that slides open, highlight your configuration name, and then click the Edit... button.
9. Under Search & Mappings scroll down and single-click on Users to highlight it.
10. Click the Add button (the left one).
11. Choose GeneratedUID from the list of available Attribute Types.
12. 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.
13. 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)

Answer 2

Assuming they are mobile accounts (which should cache required user information locally on login) and there's a possibility of the network connectivity to the LDAP server not being immediately available / available at all, I'm highly suspicious of this log line:

2 libcsfde.dylib 0x00007fff8565af1f CSFDEGetUserEntryForUUID + 134

This is the thread that's crashing in your log and right before it crashes, it's attempting to get the length of a string returned as the result of that particular (private) library call.

The name of the call seems to imply: CoreServices Full Data/Disk Encryption (aka FileVault2) "GetUserEntryForUUID" - note: This is a function asking FileVault for user information based on a UUID, not the Collaboration framework, Identity Services, DirectoryServices / OpenDirectory, etc.

This bit of code is asking FileVault to provide details about a user with only UUID information, which sounds like FV is tracking user information separately (possibly) from the rest of OS X. This is accurate, because the FileVault2 procedure, as part of marking users available to unlock the boot OS partition, writes some information to the recovery partition.

However, it sounds like there's a breakdown somewhere with OpenLDAP / mobile / "alternative" directory account authentication mechanisms and the necessary information isn't being written to be able to unlock it without network access to the OpenLDAP server.

This is just a shot in the dark - but maybe an Apple rep would be able to help more with this. Sounds like a legit real bug to me.