I was able to figure this out a while ago, but I realized I only posted the answer to my question on Serverfault. Here's the solution for this:
I ended up setting up Lion Server at my house, creating an Open Directory user with a remote home directory, and looking in the Directory Utility to see what the actual keys were set as. I was then able to use Directory Utility on the client's computer to set the keys manually and it worked perfectly.
Here are the keys you need to set assuming the server's hostname is server
, and the directory is /Users/test
on the server:
key: HomeDirectory
val: <home_dir><url>afp://server/Users</url><path>test</path></home_dir>
key: NFSHomeDirectory
val: /Network/Servers/server/Users/test
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)
Best Answer
I'm guessing from your tags this is a 10.5 Server with 10.7 clients?
In your Open Directory user configuration/preferences are you using portable home folders? (With the user in question selected in Workgroup Manager, choose the Preferences button and check the "Mobility" section)
If so (and even if not!), check that your users have a Home path set in Workgroup Manager -> Accounts -> testuser -> Home tab. Usually the diradmin default home is set to
/var
but for other users I've seen it default to (None) which causes the login window to just shake and reject the user when trying to log in on a client system, probably because the system doesn't know where to create their home folder.Try a test where you set testuser's Home location to
/Users/testuser
by clicking the + in the Home tab of WGM and entering/Users/testuser
under the Full Path: field (I'm basing this wording off a 10.6 server but I recall 10.4 to 10.6 being all quite similar.)Good luck!!