Posted on 08-08-2015 06:23 AM
How would you setups FileVault 2 policy for AD joined computers so it enables all users that have currently already have logged in and for any future new users that login?
Also for computers that are not AD joined but have multiple user accounts currently configured?
Solved! Go to Solution.
Posted on 08-10-2015 07:54 AM
Here's our 'manual' method.
In the JSS go to Computer Management > Disk Encryption Configurations
Create a new configuration
We're using both individual and institutional, you can look here for how to create an institutional recovery key.
Enabled FileVault 2 User we set to next or current user. You can use the Casper Management account, but the Casper Management account will show up at startup with the other FileVault enabled users.
We have a smart group setup to see if FileVault 2 is not enabled how we want it...
(FileVault 2 Status is not Boot Partitions Encrypted and FileVault 2 Individual Key Validation is not Valid and FileVault 2 Institutional Key is not Present) and Model like Book <- We only encrypt laptops and Local User Accounts has support <- makes sure that the machine has our support account on it and Local User Accounts has genericuser <- makes sure that the machine has our generic user account on it
We also have another smart group to see if our Support account is enabled for FileVault, but that the generic account is enabled. We don't want to enable the support account only.
FileVault 2 User does not have support and FileVault 2 User has genericuser
We also have a script to enable our support account...
#!/bin/bash
echo "<plist><dict><key>Username</key><string>support</string><key>Password</key><string>supportpassword</string></dict></array></dict></plist>" | fdesetup add -inputplist
exit 0
And there are two policies. The first's frequency is set to on-going as we may have to redo it for a machine (for whatever reason). Select the Disk Encryption from the list of policy options down the left side and select the encryption you want for that machine. Set to apply (duh) and at next logout. Maintenance is also set to Update Inventory. It's Scoped to All Computers, limited it to users in our Admin NT group (they'll have to log-in to Self-Service). Self-Service is enabled.
The second policy runs the script above to enable our support account, ongoing, and has Maintenance set to Update Inventory. It's scoped to the second smart group above. We enable to generic account first because a local user may need to help us remotely and we don't want to give out our support password.
After imaging our support people log into the machine with our generic user account and go to self-service for any updates that haven't been included into the image yet, run a policy to load our custom dock, and see if the Firmware Password needs to be set and finally enable FileVault 2. They'll run the FileVault 2 item last and log out or restart (doesn't matter - it's going to restart regardless). The user will be prompted to enter the current account password.
On restart the machine will no longer be reachable via remote management (ARD, VNC, Bomgar, etc). At the next log out a script is kicked off that enables our support account for FileVault. This will cause the logout to seem to stall by a minute or two more than usual, but no worries.
Right now that's where we end. Our generic account has admin access and the user go to town.
In the near future we'll be enabling NT Authentication and the setup will continue. In these cases the generic account won't have admin access. We have a local user 'log in' with the generic account which unlocks FileVault. Then we can remote in if we have to. The local user can log out of the generic account, but FileVault is still unlocked. At the login prompt they can enter their NT credentials and their account will be created. They can then go to System Preferences > Security > FileVault and add their account. If they're one of our supported users they're already in an NT group that has admin rights, so they can unlock System Preferences. if they're not one of our supported users they'll have to call us, or get someone who is who will be asking them what they're doing. Normally non-supported users should be fine being limited to our generic account.
Posted on 08-09-2015 01:27 AM
Quick Answer - there's not quick and easy way to do it.
Long Answer - The only way to add a user account to FileVault is to know the account's password. To add existing users, or new users, there are a few methods where you can prompt them for their password and use that to add them to FileVault access with a script in command line. The same for new users, prompt them for their password and use the command line. I don't think these scripts work with 10.9 and 10.10 however - I'd have to re-read the thread that talks about it.
Regardless, you will need to enable FileVault with an account already on the machine that you already know the password to first so that you can get into the machine later.
We're using a policy to enable FileVault either from SelfService or at first logout (if we know that the account logged in is our support account). This sets the filevault password for our support account and restarts the machine. This is the only account that can log in at this point. Support logs in and at next logout a script is run that adds our generic non-admin account to filevault (because we know its password as well).
After this we tell the first user on the machine that once they've logged in with the generic account to unlock filevault they can log out and then back in using their NT credentials which (usually) gives them admin rights so that they can add their account to FileVault through System Preferences. That's a degree of trust however, which is fine for our organization.
Posted on 08-09-2015 04:06 AM
Would you be willing to post your process and support scripts. That sounds exactly like what we'd like to do. Today, we are only authorizing the user themselves for FileVault, and relying on the Enterprise Recovery Key if we later have to "break in" and work on the machine. It works, but it's very time consuming.
Posted on 08-10-2015 07:54 AM
Here's our 'manual' method.
In the JSS go to Computer Management > Disk Encryption Configurations
Create a new configuration
We're using both individual and institutional, you can look here for how to create an institutional recovery key.
Enabled FileVault 2 User we set to next or current user. You can use the Casper Management account, but the Casper Management account will show up at startup with the other FileVault enabled users.
We have a smart group setup to see if FileVault 2 is not enabled how we want it...
(FileVault 2 Status is not Boot Partitions Encrypted and FileVault 2 Individual Key Validation is not Valid and FileVault 2 Institutional Key is not Present) and Model like Book <- We only encrypt laptops and Local User Accounts has support <- makes sure that the machine has our support account on it and Local User Accounts has genericuser <- makes sure that the machine has our generic user account on it
We also have another smart group to see if our Support account is enabled for FileVault, but that the generic account is enabled. We don't want to enable the support account only.
FileVault 2 User does not have support and FileVault 2 User has genericuser
We also have a script to enable our support account...
#!/bin/bash
echo "<plist><dict><key>Username</key><string>support</string><key>Password</key><string>supportpassword</string></dict></array></dict></plist>" | fdesetup add -inputplist
exit 0
And there are two policies. The first's frequency is set to on-going as we may have to redo it for a machine (for whatever reason). Select the Disk Encryption from the list of policy options down the left side and select the encryption you want for that machine. Set to apply (duh) and at next logout. Maintenance is also set to Update Inventory. It's Scoped to All Computers, limited it to users in our Admin NT group (they'll have to log-in to Self-Service). Self-Service is enabled.
The second policy runs the script above to enable our support account, ongoing, and has Maintenance set to Update Inventory. It's scoped to the second smart group above. We enable to generic account first because a local user may need to help us remotely and we don't want to give out our support password.
After imaging our support people log into the machine with our generic user account and go to self-service for any updates that haven't been included into the image yet, run a policy to load our custom dock, and see if the Firmware Password needs to be set and finally enable FileVault 2. They'll run the FileVault 2 item last and log out or restart (doesn't matter - it's going to restart regardless). The user will be prompted to enter the current account password.
On restart the machine will no longer be reachable via remote management (ARD, VNC, Bomgar, etc). At the next log out a script is kicked off that enables our support account for FileVault. This will cause the logout to seem to stall by a minute or two more than usual, but no worries.
Right now that's where we end. Our generic account has admin access and the user go to town.
In the near future we'll be enabling NT Authentication and the setup will continue. In these cases the generic account won't have admin access. We have a local user 'log in' with the generic account which unlocks FileVault. Then we can remote in if we have to. The local user can log out of the generic account, but FileVault is still unlocked. At the login prompt they can enter their NT credentials and their account will be created. They can then go to System Preferences > Security > FileVault and add their account. If they're one of our supported users they're already in an NT group that has admin rights, so they can unlock System Preferences. if they're not one of our supported users they'll have to call us, or get someone who is who will be asking them what they're doing. Normally non-supported users should be fine being limited to our generic account.