Enable Filevault Automatically

[rderewianko]

I scoured the forum, couldn't find anything.

I would like to have a policy that upon reboot into mountain lion, having a smart group show that file vault is not enabled, run the enable file vault policy, so the next time they restart it starts encrypting. Is this possible?

[jarednichols]

http://www.jamfsoftware.com/resources/white-papers

Check out the "Administering FileVault 2 on OS X Mountain Lion with the Casper Suite" white paper.

[gachowski]

From what I understand not really. There is no way to force the encryption, it requires the "user's password"

C

[mm2270 · Accepted solution]

From what I understand not really. There is no way to force the encryption, it requires the "user's password"

Technically that's not true. You can use the management account instead of the user account, but that function is mostly useless when talking about FileVault 2. No-one would be able to log in without knowing your Casper management account. I can't imagine anyone wanting to do that.

[jhbush]

The option I'm looking at is having JAMF set for the "Next logged in user" preferably this would be the assigned user. I would then create a self destructing agent that would call a plist with our local admin user name and password followed up with the removal of the plist for security purposes. Rich T. covers a lot of this on his blog. Anyone see this not working?

[rtrouton]

Jason,

I'm not sure that would work as intended. Having it set for "next logged-in user" means that the jamf binary is running the following command:

fdesetup enable -defer /path/to/filename.plist

As I understand what you're thinking, you want to then run a second separate fdesetup command:

fdesetup enable -inputplist < /path/to/filename.plist

I haven't tested this scenario, so I recommend double-checking the behavior with JAMF's support, but I believe that the first command, using -defer, would be the one that the system would use. That would mean that the second command would be ignored.

If the system did use the second command, that would probably mean that the JSS would not get a record of the recovery key because the jamf binary would be running the script's call of fdesetup, instead of the binary running fdesetup directly.

[jhbush]

Rich, I was thinking more of just adding the user to the list of users allowed to decrypt the disk. The assigned user would be a unknown password, but the local admin would be known. I think that's possible correct?

[rtrouton]

Jason,

The issue is that, unless you're using the -defer option, you'll need to know in advance the user's account password in order to add them. The only other way to have someone get added without the admin knowing their password is the following:

1. Encrypt the Mac with a username and password that is known to the support person.

Note: The user's account must not exist on the Mac at this point.

1. The Mac support person logs in at the FileVault 2 pre-boot login screen with that account's credentials.

2. Following the login process's completion, the support person then logs out to the regular login screen.

3. The user then logs in at the regular login screen with their account credentials.

The user will then get added to the list of enabled users.