MacOS – Preparing the MacBook Pro in case it is ever stolen

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)

After a bit of messing about, it turns out that there is a better compromise which doesn't seem to be clearly documented anywhere obvious, so I thought I'd share it here. I don't believe this is a duplicate but I'm happy to see this question closed if I've missed something.

The cost of the solution (which may be unacceptable to some) is that you need to sacrifice about 14G of your drive to a honeypot partition. The steps I took are:

1. Use Disk Utility to resize your boot partition to create at least 14.3G of free space at the end of the drive. If you've already enabled FileVault, I believe this means you're going to have to turn it off and wait for it to finish decrypting first.

2. Create an empty, Mac OS Extended, Journalled partition at the end of your drive filling the free space.

3. To make things look a bit more convincing, give your new partition a name that's more plausible than Macintosh HD (2) - I name mine after my host name.

4. Restart your computer and launch into recovery mode by holding down Cmd-R as the system boots.

5. Select reinstall OS from the recovery menu, and follow through with the install. Somewhere along the line you will get the option to select where to install the OS. You want to put it on the new partition, obviously. It should be just big enough to let you install Lion. If it isn't you're going to have to drop back out to the main recovery menu, fire up Disk Utility and resize the partitions again. This is a bit of crapshoot because you don't end up with as much free space as the specified size of the partition but you'll get there in the end.

6. Complete the installation of your new copy of Lion. You want to set this up as a honeypot, so:

   • Enable automatic login that logs into a non-administrative account with the same username as you use on your main partition (for added plausibility)
   • Make sure your admin account has a decent password to make it hard for the thief to mess with your tracking software if he finds it
   • Don't hook anything up to iCloud - I'm assuming you're going to be using an alternative service like Undercover, Prey or LoJack to aid recovery, so it's just more potential exposure and best avoided.
7. Install your tracking software of choice on the honeypot partition. I went with Undercover in the end because it's a one-off cost and Prey is written in bash <shudder>.

8. Prevent corestoraged from trying to mount encrypted partitions on startup, thus blowing your cover:

   sudo mkdir -p /System/Library/LaunchDaemons.Disabled
   sudo mv /System/Library/LaunchDaemons/com.apple.corestorage.corestoraged.plist /System/Library/LaunchDaemons.Disabled/com.apple.corestorage.corestoraged.plist
   

   (A bit of a hack, but it's only a honeypot. Hat tip to the contributors here )

9. Reboot your system. You'll need to hold down alt/opt as the system boots to bring up the boot menu. Select your original main partition to boot into your main system.
10. (Re)Enable FileVault for this partition and allow it to complete.
11. Install your tracking software on this partition as well (this works fine for Undercover, which identifies machines by serial number of MAC address, so it doesn't care which partition you boot into)
12. Set a firmware password. If you're on a pre-2011 mac this is only a token gesture, but I suppose every little helps. If you have a newer mac, this is a serious security measure, as the only options for circumventing it AFAIK are taking it to Apple or physically replacing a chip on the motherboard.

So now, if you power off your mac and boot it from cold, it will boot into the honeypot partition without even asking for a password. To an unsophisticated thief, it will look like they've got access to your machine just by rebooting it. There's a fighting chance that your tracking software will have a chance to file a report before the thief realises that something isn't quite right.

When you reboot your machine, you will have to remember to hold down the alt/option key to get into your proper system, at which point you will be prompted for a password to decrypt it. Assuming that you have the appropriate locking settings enabled for sensible security, your machine is tolerably secure against someone getting hold of sensitive private data.

If you have a recent mac with proper firmware protection, the thief will have an exceptionally difficult time using anything other than the honeypot partition, and will struggle to do anything particularly useful even with that, since he has no administrative rights. With any luck, by the time he's finished getting frustrated with it the police will already be knocking at his door :-)