- Password Changes and FileVault 2
- The Guest User and FileVault 2
- Enabling Admin Users for FileVault 2 via System Preferences
- Creating an Institutional Recovery Key
- Erasing a FileVault 2?Encrypted Volume from the Command Line
- Setting a Text-Only Login Banner from the Command Line for the FileVault 2 Pre-Boot Login Screen
- Booting into Single-User Mode on a FileVault 2?Encrypted Mac
- Using Apple's Internet Recovery to Unlock or Decrypt a FileVault 2?Encrypted Boot Drive
- FileVault 2 and UUIDs
- Automating fdesetup authrestart in 10.9.x or Later
- Conclusion
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
FileVault 2 and UUIDs
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 in the Terminal, the user information for FileVault 2–enabled accounts appears with both the username and UUID information (see Figure 36).
)
Figure 36 Using fdesetup list to display enabled usernames and UUIDs.
For local accounts, the OS will properly generate a GeneratedUID user attribute to provide a UUID for the local account. Active Directory also generally handles this action correctly on Macs, so I haven't seen UUID problems occur for AD mobile users.
Where I've heard of problems is with Macs bound to non-Apple LDAP servers. If the LDAP server doesn't provide the GeneratedUID user attribute for its accounts, or it does not provide the UUID in the way that FileVault 2 expects, one or more of the following behaviors could occur:
- The LDAP account's icon disappears from the FileVault 2 pre-boot login screen. This behavior is generally caused by the GeneratedUID attribute not being set for the LDAP account.
- The account icon is present, but the password doesn't match the current password on the LDAP server. This behavior has been observed when the GeneratedUID doesn't match what FileVault 2 expects.
A good example of the latter behavior came from a Mac admin who asked me about passwords not updating. His shop was running an LDAP server as the 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 on 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 lowercase letters; did that matter? When I followed up on this question, he confirmed that instead of his UUIDs looking like this:
7C9AFB0E-E06E-43FA-8E9F-1D410344D2AA
instead they looked like this:
7c9afb0e-e06e-43fa-8e9f-1d410344d2aa
After confirming that Mac account UUIDs need to use uppercase alphabetical characters and are case-sensitive, my colleague changed a test account's UUID to use uppercase alphabetical characters. At that point, FileVault 2 logins for that account began working properly.
If you have an LDAP server and your mobile LDAP accounts aren't working properly with FileVault 2, these steps should make FileVault 2 start working properly:
Make sure that your LDAP server(s) have apple-generateduid values 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.
- Ensure that all alphabetical characters listed in the apple-generateduid value are uppercase.
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.