Your question contains the most important thing needed to secure a computer against a motivated attack to compromise a FileVault 2 protected Mac volume.
- Don't connect FireWire to a device you don't or can't trust while you are logged in to an account that has file vault keys active.
- Pick good single use passwords to reduce the chance of other compromises degrading the security of your FileVault password.
- Update to 10.7.3 and verify
sudo pmset -a destroyfvkeyonstandby 1 hibernatemode 25 power management settings that force hibernate mode to secure your keys from compromise when the device would normally "sleep"
I do follow Rich Trouton to keep up to date on his blog for nice commentary on securing macs. The mix of up to date topics seasoned with experience as a real world system administrator make his writing very valuable to me.
The crux of the issue is your parsing What user behavior is necessary to have security. I always like to think of security as a mindset and ongoing attempt to plan, implement, measure and adapt. Security isn't something you buy or something you "set up" and training users to actually not divulge the passcode they have used to store their unlock phrase is the weakest part of FileVault's security layer. Not reusing that passcode - having a system where you get your users to understand why their keychain password needs to be unique and secure is far, far harder and takes far longer than just setting up a plan for implementing file vault initially. Best of luck in your quest for security!
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
Nope - there’s no getting around FileVault at the moment and with the T2 chips controlling this, you’ll need Apple to move to get the alternatives you mention off the ground let alone to production.
There are very good pre-log in screen options like the NoMad family and JAMF Connect that allow you to have LDAP/AD users checked at log in time, creating a local user if needed so you don’t have to pre-set up local users on macOS.
You’ll need an MDM to collect your FileVault keys (individual or institutional) if you need to be able to unlock a mac where a user isn’t already FileVault enabled. You’ll also need to keep track of secure tokens on newer OS.
Hit up the mac admin community on slack if you manage macOS professionally - most of the tooling needed is open source and the community blogs to get you up to speed are invaluable.
You’re right this isn’t manageable with tools like Apple Business Manager / DEP / MDM so you’ll need to bring some tools to manage 500+ Macs without a large staff and tons of repetitive work.