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)
Think I found an answer: https://jamfnation.jamfsoftware.com/discussion.html?id=6025
sudo defaults write /Library/Preferences/com.apple.loginwindow DSBindTimeout -int 8
Changes the bind timeout to 8 seconds. Our bind happens within 3-4 seconds over ethernet, so we figure double it and add an extra second should be enough for an absolutely unscientific unengineering-like guess.
Best Answer
I will explain this process very technically in details.
When you have an encrypted disk with FileVault, the system needs to ask for an authorised user to login just after EFI boot.
This is necessary because the system has to mount the disk. And it can't mount it without an admin password input.
You then see a screen with local admin-level users avatars.
That screen shows some users avatar because that user's avatar were inserted on the EFI boot image/nvram. At this point of the boot sequence, there is no Operating System loaded yet, it's just a simple boot screen to ask the user password [which simulates the login screen appearance of the GUI], but it just a static image containing the user avatars! (almost like a kind of bootloader statical image, except it asks for user/pass combination)
After you insert the password, the disk is mounted, and the boot process begins.
After the loading bar reaches about 80% that screen changes to another almost identical, it sometimes blinks at this point. This is the GUI interface being loaded, process called WindowServer.
At this point the network interface is UP, other network subsystems are just started, including open directory services [which you need]. If the disk were NOT encrypted, this is the EXACT point where you would see the REAL login screen asking for username/password. But since the disk is encrypted and you have provided the user/pass to decrypt it earlier [before mounting the disk] it skips the real multiuser-mode login screen that should appear here and auto-logs the username you inserted before.
So in practice, it is just a mimic theatrical simulation of a real login since the boot, but it is fake, until when GUI is ready and then the MacOS does an auto-login once in multiuser mode, to make you think all was kind of "magical". But there is no magic at all.
So what you need/want is impossible on that initial screen, because no network authentication protocol is up at that point. Even the disk isn't ready, which only becomes mounted and readable after inserting the user/pass combination.
You can take a better understanding of what I have written and how all this happens by booting it a little different:
Use the
-v
nvram boot argument, to boot it verbosely.If you boot it using the "-v" nvram argument you can get a better view of what is happening "behind" the scene, and also can see the GUI loading moment, and the auto-login happening.
What has to be done:
To achieve what you need, we have to prevent the auto-login mechanism on the real GUI [windowServer] to happen.
This way you will have a local user just to mount the system-disk on Boot-time, then after GUI gets-up it must stay on the un-logged state, and showing the real login screen with the real avatars or fields to input user/password (depending on how you prefer to log users [by avatars or by text input name/pass]).
This will force 2 logins:
On the second login you can either login the same local user used on boot, or you can login any other user.
This will also let you login [on the second login] any AD user as you need to.
(Remember that the first login is not a real login, it just an authentication to mount the disk, so nobody is technically logged-in on the UNIX/BSD [system portion] after mounting the disk. The Real/true login only happens on the second one [on the GUI portion])
How to do it:
To force 2 (two) logins there is a secret key to be added to MacOS configuration:
After executing it, reboot, and it is done!
Executing the above command is completely safe, nothing to worry about it.