Posted on 06-03-2016 07:27 AM
Hey Everybody!
I need help. I am wanting to start using JAMF to encrypt my laptops. We have decided that we want individual keys and also enable my "Tech" local account as a FV2 user. I have created a Policy to kick off encryption for the current user, and am happy with the results. However, I am having a bear of a time figuring out a script to enable my Tech account as a secondary FV2 user.
There are a few articles that have helped, but I think I may need a full walkthrough on the scripting part. This seems like a simple task, but I just can't find anything beyond where I am now. Here is what I got so far:
echo "<plist><dict><key>Username</key><string>Drake Technician</string><key>Password</key><string>myTechnician'spasswordincleartext</string></dict></plist>" | fdesetup add -inputplist
I know very little about scripting, so please withhold judgment.
Solved! Go to Solution.
Posted on 06-03-2016 07:38 AM
I think the issue here will be that if the only FileVault enabled account on your Macs is the primary logged in user, scripting this to add an additional account into FileVault would require that user's password. That's a FileVault thing (security), not a limitation of Casper.
In essence, unless you set up your FileVault configuration to include your jamf management account as an enabled FV2 account, adding any extra users in to FV2 after its been enabled will require a password being passed to fdesetup. Meaning, the password of a user that is enabled.
I'm not saying that can't be done. There are a number of examples here on JN of people using scripts to prompt the current enabled user for their password, which can be passed into the plist for fdesetup to add extra accounts in, like your local admin user. I'm just not sure if you had hoped to do this in a silent way or not, because without already having an account FV2 enabled that either you know the password for, or the Casper Suite knows the password for, it won't be possible without some user interaction.
You should keep in mind, in case you weren't aware, that your local admin account will show up at the initial FV2 login screen when the Macs are booted up after its been added. There's no way to hide that account, even if its designated as a hidden account. It must show up at that login screen by design.
Posted on 06-03-2016 08:33 AM
@FeasiblePear You need to include your test user account credentials in the Plist. Also, I strongly suggest using the account shortname, not the long name for your tech account.
cat << EOF > $PLIST_TEMP
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>Username</key>
<string>testaccount</string>
<key>Password</key>
<string>testpassword</string>
<key>AdditionalUsers</key>
<array>
<dict>
<key>Username</key>
<string>draketechnician</string>
<key>Password</key>
<string>P@$$word</string>
</dict>
</array>
</dict>
</plist>
EOF
You can use osascript to leverage an applescript dialog box that asks the user for their current username and password and set some variables. Then in the Plist, just replace "testaccount" and "testpassword" with those variables.
It's my experience that @dpertschi's solution requires that the jss management account has to be enabled as a FileVault user before you can use account policies to add other users to FileVault. Without the management account being an enabled user, the JSS has no way to authenticate to FileVault and make changes.
Posted on 06-03-2016 07:36 AM
Check out my response to another post here.
You'll need to know the password of an existing FV user to add your account to each computer for the scripting method to work.
Posted on 06-03-2016 07:38 AM
I think the issue here will be that if the only FileVault enabled account on your Macs is the primary logged in user, scripting this to add an additional account into FileVault would require that user's password. That's a FileVault thing (security), not a limitation of Casper.
In essence, unless you set up your FileVault configuration to include your jamf management account as an enabled FV2 account, adding any extra users in to FV2 after its been enabled will require a password being passed to fdesetup. Meaning, the password of a user that is enabled.
I'm not saying that can't be done. There are a number of examples here on JN of people using scripts to prompt the current enabled user for their password, which can be passed into the plist for fdesetup to add extra accounts in, like your local admin user. I'm just not sure if you had hoped to do this in a silent way or not, because without already having an account FV2 enabled that either you know the password for, or the Casper Suite knows the password for, it won't be possible without some user interaction.
You should keep in mind, in case you weren't aware, that your local admin account will show up at the initial FV2 login screen when the Macs are booted up after its been added. There's no way to hide that account, even if its designated as a hidden account. It must show up at that login screen by design.
Posted on 06-03-2016 07:58 AM
@FeasiblePear Similarly, In addition to the primary user, I chose to add a FV authorized local user account to our machines for use by our desktop staff as needed. A service account if you will. This is not an admin and is not our casper management account.
I created a policy that uses the Local Accounts options to create the account and check box 'enable user for FV 2'. Policy to a SG that looks for the name of our Disk Encryption Configuration, run once per computer.
So this is getting the job done so far in early testing of our FV rollout.
Posted on 06-03-2016 08:01 AM
@Berrier Thanks for the script. I had not stumbled upon that discussion yet.
This is where I am now: I ran my policy to encrypt with the next user on my test computer. I signed in with a test account and FV2 enabled and allowed my test account to be a FV2 user. The computer is now fully encrypted with FV2 and the only user allowed to access the drive at login screen is the test account. Now, I am currently testing your script (published in Self Service - just for testing) to enable my Drake Technician account which exists on all my supported computers. The password is the same across the board for the Drake Technician account. I did not put the real password in the script below, its not P@$$word.
set -o nounset # Treat unset variables as an error
if [[ $EUID -ne 0 ]]; then
echo "This script must be run as root"
exit 1
fi
PLIST_TEMP=mktemp PL.XXXXXXX
cat << EOF > $PLIST_TEMP
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>Username</key>
<string>Drake Technician</string>
<key>Password</key>
string>P@$$word</string
</dict>
</plist>
EOF
/usr/bin/fdesetup add -inputplist < $PLIST_TEMP
srm -m $PLIST_TEMP
Posted on 06-03-2016 08:15 AM
@dpertschi This is exactly what I want to do in my environment. I believe this is exactly what I was trying to do.
I have a policy that sets the Tech (service account) upon enrollment and startup. The "Enable user for FileVault 2" checkbox has been checked. I figured that checking that box would immediately enable the Tech account as a FV2 user if applicable. This is not the case in my testing.
Posted on 06-03-2016 08:33 AM
@FeasiblePear You need to include your test user account credentials in the Plist. Also, I strongly suggest using the account shortname, not the long name for your tech account.
cat << EOF > $PLIST_TEMP
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>Username</key>
<string>testaccount</string>
<key>Password</key>
<string>testpassword</string>
<key>AdditionalUsers</key>
<array>
<dict>
<key>Username</key>
<string>draketechnician</string>
<key>Password</key>
<string>P@$$word</string>
</dict>
</array>
</dict>
</plist>
EOF
You can use osascript to leverage an applescript dialog box that asks the user for their current username and password and set some variables. Then in the Plist, just replace "testaccount" and "testpassword" with those variables.
It's my experience that @dpertschi's solution requires that the jss management account has to be enabled as a FileVault user before you can use account policies to add other users to FileVault. Without the management account being an enabled user, the JSS has no way to authenticate to FileVault and make changes.
Posted on 06-03-2016 08:47 AM
I went another way, as we don't want the management account to be the first enabled FV user (don't want to share the management account password outside of Desktop Engineering). We can enable the management user via native JSS policy after FV is on.
We wanted to enable for the local "tech" user using the "current or next user" FV configuration option, and only the "tech" user.
So, how to do? Well... I wrote a custom FV trigger script which checks for a specific user and triggered it at login. If the local user is the user we want, the script fires off a custom policy trigger which runs the "current or next user" FileVault policy, updates inventory, and pops a jamfHelper utility box letting the "tech" user know that FV is enabled and to log out to complete. Works like a charm!
Its on local IT to log in and enable the actual user of the machine after FV is enabled for "tech". We just don't want ANY passwords flying about in clear text...
# Trigger FileVault 2 push for tech user at login
thisUser=`stat -f '%u %Su' /dev/console | awk '{ print $2 }'`
if [ $thisUser = "tech" ]; then
echo "User is tech, executing FileVault enablement for tech"
jamf policy -event fvenable
jamf recon
/Library/Application Support/JAMF/bin/jamfHelper.app/Contents/MacOS/jamfHelper -windowType utility -description "This Mac has been enabled for FileVault 2 encryption for the user tech. Please log out of this Mac and enter the password for tech when prompted. This Mac will reboot once the password is entered." -button1 "OK"
else
echo "User is not tech, bailing on executing FileVault policy."
exit 0
fi
Posted on 06-03-2016 08:48 AM
@Berrier That's an interesting point because my encryption config, using individual and institutional keys, is set for current / next user, not the mgmt account. So is the fact we're using an institutional key providing the authorization to add that user?
@FeasiblePear the difference is that I'm adding the user after FV enablement.
Posted on 06-03-2016 08:57 AM
@dpertschi institutional keys are pretty much limited to decrypting the drive when you don't have password access to filevault, they don't let you authenticate to do other actions. Without seeing your particular setup, I'm hard pressed to think of how it might be working, but you know what they say about if it ain't broke...
Posted on 06-03-2016 12:18 PM
Thanks for the explanation @Berrier
Not what I hoping for, but it makes sense. I won't always know the user's creds to then pass in another user with the script. I am working on figuring out why I can't get computers to work like what @dpertschi got going on.