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
