1 - We've set ours up to use both the Institutional and Individual Recovery keys. In this way, if we ever need to use a key, techs can pull the individual recovery key using their elevated accounts. We can even at times give that key to the end user of the system and it only applies to their Mac. The Institutional key is heavily guarded and only a few select people have it or know how to use it to unlock any of our FV2 enabled systems.

2 - We only enable the primary user of the Mac, not any local admins on it. We don't want those accounts showing up at the FV2 login screen and currently Apple provides no way to change the FV2 pre-boot screen to display username & password fields instead of the list of users, which would be a huge help. FWIW, we have put in a formal request to Apple on that. Same for the Casper service account. We don't enable it, especially since no-one would ever log into that account for any reason.

3- I can't speak much to this issue since we really only enable it for the primary user on the Mac. We have it set up so it will run after the user first logs into their Mac. They need to do a logout right after to finish setting up their system and it prompts them to enable FV2 at that time. We're using the current or next user option for that.

All good information. Thanks!

We do the admin user first, then the machine's primary user at delivery. We need to be able to get in in case a user is unavailable and an unplanned restart occurs.

@barnesaw, that's what the Recovery key is for. You can use it at the FV2 login screen to unlock the Mac and log into the primary user's account, then if needed, go back to the login screen and log in as your local admin user.
Granted, the above steps allow you to access a user's account, which may or may not be acceptable in your environment, so perhaps that's why you chose to go that route?

1. We use both keys, for the reasons mentioned. Also, if Apple fixes their current bug with fdsetup, you'll also be able to use the individual recovery key to add (or delete) other users from being able to unlock the drive.

2. We're only enabling initially for the user. We'll use the individual recovery key if we have to unlock the drive as an admin. Also, because of...

3. We actually enable via Self-Service. Seems to work great and allows the users to have some control over it (which they like). We scope various policies to whether or not the drive is encrypted (like an annoying pop-up to go encrypt).

@mm270 - If you don't include your JSS account, how do you manage the systems? If the drive is FDE - wouldn't that block access to the local accounts? How would you be able to push software to an encrypted drive w/o the JSS account being able to access the drive? Is it possible to login with the local admin at all if you only encrypt the Users account? (SSO would only show the user account in that case).

@jwojda,

FileVault 2's encryption unlocks before OS X boots. Once the Mac has booted to the point where Casper can communicate with it, everything runs like it does on an unencrypted machine.

@jwojda,

One key thing to know about FileVault 2 is that FileVault 2 does not work at all like FileVault did on 10.3.x - 10.6.x. The two are very different encryption solutions.

FileVault 2 does not encrypt on a per-user basis. Instead, FileVault 2 encrypts a whole boot volume, then allows authorized accounts access to the encrypted volume. However, the account-based access happens before the OS boots. From the OS's perspective, nothing's blocked when it boots up. Everything it needs to access is accessible.

@mm2270 - That is exactly why we have a second user. Infosec does not allow us to access anyone else's account on a machine unless they are present to give consent. Once consent is given, however, we are allowed to work in their account as long as needed. Kind of a backwards rule, but one we have to follow.

The added bonus for us is that we know, 100%, that the drive is done encrypting before it leaves our office. One more checkbox for the audits.

@jwojda
The biggest challenge I currently see is if you decide to enable multiple accounts, which do you do first? The 'User' of that computer or your admin account (I don't think there is a reason to enable your management account). It would be nice to be able to enable multiple accounts at once the first time so you could get your admin account and the current/next user..

Another thing to note, all enabled accounts show up at the pre-boot screen even if it's a hidden account. : (

We've filed a feature request with Apple to give us the option to keep these accounts hidden at the pre-boot screen as well. How they do it I don't know as I believe this is before the OS boots and it part of the EFI.

@krichterjr -We have a similar contention with the fact that all enabled accounts show up at the FV2 pre-boot screen - hence why we chose not to add any admin accounts to the authorized list.

We filed a similar request with Apple as yours, but in our case we would like to see an option to set the login screen to use the username/password fields instead of the List of users option. In an enterprise, having user account names show up at a login screen is troublesome. Half the battle in getting into a machine is knowing the username, the other half the password. and Apple is forcing us to give away half the secret at that login screen.
Yes, I know we're not "forced" to use FileVault 2, but even with its issues its still worlds better than the other FDE options out there, so we're living with it for now. I do hope they give us more control over this in 10.9.

@mm2270
I completely agree that having the username/password fields at the pre-boot login screen should be an option.

In BYOD-type environments, we only worry about the user's account.

In corporate-owned assets, most orgs that I work with choose to enable to local admin account (part of imaging process), then the user is enabled as the machine is set up. That way it's ensured the disk is encrypted before it's handed off to the user. Also allowing the admin user to unlock the disk without the individual or institutional recovery keys (most orgs that I know on 10.8 are doing the hybrid/dual approach)...

Of course, I haven't worked out how regular local admin password rotations (done via Casper policy) will affect the ability to unlock the disk...

Robert,

As long as the passsword rotation is done via policy (i.e. the Casper agent working with the OS to change the account's password), FileVault 2 should get the updated password as well.

You'll hit problems if you're updating the password on one machine, then dropping an updated account plist file into place onto other machines, as that won't trigger the FV 2 password update process. In that case, FV 2 will use the old password to unlock, then the user should be stopped at the regular login window.

At the regular login window, the user would need to log in using the new password. This is because the updated account password and the password used to unlock at the FV 2 login window won't match. Logging in with the updated password should then trigger the password update process and feed the new password back to FV 2.

With regards to your third question, I use a custom script that I wrote to grant users (one at a time) the ability to unlock the drive. see https://jamfnation.jamfsoftware.com/discussion.html?id=6169. It may require some tweaking for your environment. Since it's a plist file, there may be a few other ways to write it that are less cumbersome, that one just happened to work for me.

We enable the current end user via self-service and then have a smart group that populates when the encryption is completed. The smart group is scoped to a number of policies that run once per computer. Those policies trigger the script granting one additional user the ability to unlock the system.

Our internal policy is such that if we need to get into someone's system, we keep it in a secure area and just decrypt the system using the key in Casper. Because of that policy, our local admins aren't granted the ability to decrypt. I realize this is probably not the way that most companies work, but it's the case for us.

We are in the process of setting up FV2. We're probably going to create a standard non-admin account which only has the role of locking / unlocking the drive. The key will be a Individual + Institutional. The password will be generic so that all the users will know what it is.

It's still safer than not having any encrypting and it saves us some time. Because the users are already having trouble with the AD passwords and the keychain that doesn't get updated. Adding another password that they set themselves for FileVault 2.. will probably just add to the confusion.

1. We use individual and institutional keys. i'm a belt and braces guy when it comes to FDE.
2. we enable our local IT tech accounts in addition to the end user but not the JAMF management account.
3. we use the deferred enablement to setup the end user through self service. then, we have a policy scoped that runs a package that enables our IT accounts. the pkg dumps the plist for the fdesetup command onto the HD, then the postflight script from the pkg runs the fdesetup command using the plist's account info and srm's the plist when it's done.

works great, our techs love it and consistently remind our SCCM/Windows engineer how much better encryption is on macs than windows . . . .;)

Hate to resurrect a old thread, but what are the drawbacks of only enabling the end user account? How do things like OS upgrades or patching work with FV2? If we only enable the end user account and an employee leaves, how do we turn the machine around to a new user if we don't have a local admin account?

@jwojda we would either gain access with the individual recovery key (easiest) or the institutional key (very rarely because we secure it). With the individual recovery key, you get to the OS login window and can then log in with your administrator account and then do what you will (add a new user, decrypt, etc).

That said, we are required to wipe the drive of every system that we reissue to a new user, per corporate information security policy. We only gain access to the drive if we need to get data from it, otherwise we wipe it when we reimage it.

Same security policy prevents us from enabling FV for any non-end-user account (local administrator, Casper management account, etc) that would have a common password across systems, so we rely on the recovery key.

@jwojda

If you don't have an Institutional key, then you are formatting and re-imaging the system, unless you've backed up the individual key in Casper.

You cannot change the AD password , as it will not be sync'd to the FileVault 2 password, and will not unlock the drive.

@jwojda As long as you have a valid Recovery key for any of your FV2 encrypted Macs, you'll still be able to log into one of them if an employee leaves. At that point, you can simply add an additional user account to the authorized FV2 list (must be an actual account on the Mac), and then remove the original user. You can do all this using that Recovery Key.
None of this negates the need to have a local admin account on the Mac. You definitely still need those accounts on there. In the case above, if an employee leaves and they were using an LDAP account, once the Mac is unlocked with the Recovery key, it may get stopped at the username & password field prompt. In fact, its default behavior now since 10.9 that using the Recovery Key no longer auto logs into the user's account. You hit a "Reset Password" screen at which point you can cancel out of resetting the password, and just log in normally to any local account regardless of whether that account is in the FDE list.

As for OS upgrades and patching, I'm not sure I understand what the concern is. The Mac must be booted into the OS before any patches can be applied, and OS X patches are actually able to work with encrypted Macs just fine, even full OS upgrades without issue, so I don't see any need to be concerned over them.

It seems like a lot of folks here do enable their local admin account on their Macs, but as I explained in this thread, we chose not to. For me at least, it opens another possible avenue for getting into the Mac. This is both good and bad. Good from the sense of administering the systems, but also bad in that it means there is another account besides the primary user that can unlock the Mac in the event it ever gets lost or stolen.

If HackerA wants access to your system, all they need is access to JSS to view the FileVault 2 recovery key.

Boot into Single User Mode, and a few keystrokes later you've got a local admin account to log in with.

If it were up to me, I would use a separate, managed solution to escrow FileVault 2 keys.

To be quite honest, I would be ecstatic to see JAMF add Cauliflower Vest to NetSUS. :)

PS...thank you JAMF for the stealth implementation of this feature request... :):):)

Don

JAMF took some pains to secure FileVault 2 recovery keys, including adding special privileges which are needed to view FileVault recovery keys. In addition to the privilege-based safeguards:

• The FileVault 2 recovery keys are encrypted in the database.
• The JSS audits who accesses those keys
• The keys aren't accessible or exportable via the API.

More information on this is available here:

https://jamfnation.jamfsoftware.com/article.html?id=314

I don't think you can boot into single user mode if FileVault is enabled.

@bmarks from the Boot into Single User Mode link in my post above...

- Your Mac can't start up in single-user or verbose mode if the computer owner or administrator has set a firmware password. - If FileVault is enabled, you need to unlock the startup disk as part of this process. White text appears briefly before the FileVault login screen is shown. After selecting a user and entering the user’s password, the single-user mode or verbose mode startup process continues.

I think you're thinking of when Firmware password is enabled?

Don