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.

@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.

@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.

!/bin/bash

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

@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.

@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.

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

@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.

@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...

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.