Escrow Personal Recovery Key From Command Line Using fdesetup

[1ManRockBand]

At the company I work for, I.T. sets up all laptops for incoming employees and I'm trying to figure out how to automate as much of the computer setup as possible.

One of the snags I'm running in to is that FileVault 2, when set up from the command line via

sudo fdesetup enable

doesn't provide an obvious way to escrow the recovery key to JAMF like it does when you do FileVault 2 setup manually through System Preferences (see image).

Anyone know how to do this? All the computers this applies to are 10.13 or higher.

Thanks in advance!

.

[donmontalvo · Accepted solution]

This should be managed using a Configuration Profile.
- For 10.12 and lower use the FileVault Recovery Key Redirection payload.
- For 10.13 or higher you'll need to check Security & Privacy > FileVault > [x] Enable Escrow Personal Recovery Key.

[1ManRockBand · Accepted solution]

Seems I misunderstood how Jamf grabs the recovery keys.  The computer saves the recovery key locally regardless of whether or not you select a destination in the setup process.  When Security & Privacy >> FileVault >> Enable Escrow Personal Recovery Key is enabled Jamf pulls the local key during an inventory update (or some other update process) and copies it to the computer's record in Jamf.

So, using

sudo fdesetup enable -inputplist -verbose < /path/to/filevaultSetup.plist

and not specifying the destination (like system preferences makes you during setup) has no effect on whether or not the key actually gets to Jamf.

You can use that command with a plist to enable FileVault for one or more users from the command line.

[joeyk]

Did you ever get an answer for this?

[donmontalvo · Accepted solution]

This should be managed using a Configuration Profile.
- For 10.12 and lower use the FileVault Recovery Key Redirection payload.
- For 10.13 or higher you'll need to check Security & Privacy > FileVault > [x] Enable Escrow Personal Recovery Key.

[1ManRockBand · Accepted solution]

Seems I misunderstood how Jamf grabs the recovery keys.  The computer saves the recovery key locally regardless of whether or not you select a destination in the setup process.  When Security & Privacy >> FileVault >> Enable Escrow Personal Recovery Key is enabled Jamf pulls the local key during an inventory update (or some other update process) and copies it to the computer's record in Jamf.

So, using

sudo fdesetup enable -inputplist -verbose < /path/to/filevaultSetup.plist

and not specifying the destination (like system preferences makes you during setup) has no effect on whether or not the key actually gets to Jamf.

You can use that command with a plist to enable FileVault for one or more users from the command line.

[1ManRockBand · Accepted solution]

Following up on this same topic, I also created a script to automatically enable FileVault on a user's computer in situations where you (the admin) know their password. 

• In situations where you do not know the password it will prompt for it, though at that point you may as well use the FileVault enablement tool in a config profile since it essentially does the same thing.

We set computers up by hand for new employees and use a static default password during the setup process.  Once setup is complete, we run the script below to ensure the user is prompted to set a new password at first login.

echo <DEFAULT_PASSWORD> | sudo -S pwpolicy -u "$USER" -setpolicy "newPasswordRequired=1"

This FileVault script, when paired with the correct PPPC payload will silently enable FileVault and display a notification indicating FileVault has been enabled.  Jamf will pick up the newly created recovery key at the next inventory update and update the computer's record in your Jamf server.

Some error handling has also been built in to display notifications or log output when something goes wrong or an exception is found.

*** Please note that this command in the script will not actually run until a button in a security popup has been clicked, and as such this command requires some AppleScript to function correctly, which means some "Apple Events" processes will also need to be whitelisted in your PPPC payload.

Here's the script.  I'm sure there's probably a way to make this prettier/more efficient, but it has been working reliably for our specific use case.

#!/bin/bash

## check if FileVault is already enabled
fvStatus=$(fdesetup status)
if [[ $fvStatus == *"FileVault is On."* ]]; then
	echo FileVault is already enabled.
	exit 0
fi

## get the logged in user's username
userName=$(/usr/bin/stat -f%Su /dev/console)

## define default password and check if current user password is default password
userPw="DEFAULT_PASSWORD"
userPw_Check=$(dscl /Local/Default authonly $userName $userPw; echo $?)

## if current user password is not default password, prompt user to enter password and verify
## repeat password prompt if manually entered password is incorrect
while [[ $userPw_Check != 0 ]]; do
dialogResponse=$(osascript -e 'set pwPrompt to display dialog "FileVault is not enabled on this computer.\nPlease enter your password to enable FileVault.\n" default answer "" with icon caution buttons {"Continue", "Enable FileVault Later"} default button 1 with hidden answer')

if [[ $dialogResponse == *"Enable FileVault Later"* ]]; then
	echo "FileVault setup manually canceled"
	exit 1
else
	userPw=$(echo "$dialogResponse" | cut -d ":" -f3)
	userPw_Check=$(dscl /Local/Default authonly $userName $userPw; echo $?)
	if [[ $userPw_Check == 0 ]]; then
    	echo "User password verified.  Creating config plist."
  	fi
fi
done

## make plist for fdesetup to use as input
sudo mkdir -p /Users/Shared/.Jamf
sudo defaults write /Users/Shared/.Jamf/fvSetup Password $userPw
sudo defaults write /Users/Shared/.Jamf/fvSetup Username $userName
sudo chmod 744 /Users/Shared/.Jamf/fvSetup.plist
echo "plist created"

# run FileVault enable command using plist to fill username and password
sudo fdesetup enable -inputplist -verbose < /Users/Shared/.Jamf/fvSetup.plist &

# click "OK" on "fdesetup would like to enable FileVault" security dialog window
/usr/bin/osascript <<EOF

set dialogFound to false
set loopCount to 0
tell application "System Events"
	tell process "UserNotificationCenter"
		repeat while dialogFound is false and loopCount ≤ 1200
			if exists window "" then
				set dialogFound to true
				try
					click button "OK" of window ""
				end try
			else
				set loopCount to loopCount + 1
				delay 0.1
			end if
		end repeat
	end tell
end tell


EOF

loopCount=0
timeout=false
while [[ $fvStatus != *"FileVault is On."* ]]; do
	echo $fvStatus – Checking again: ATTEMPT $loopCount
    fvStatus=$(fdesetup status)
    loopCount=$((loopCount+1))

	sleep 2

	if [[ $loopCount == 60 ]]; then
       	timeout=true
        echo "FileVault setup failed due to an error.  Prompting for manual setup."
		sudo jamf displayMessage -message "FileVault automatic setup has encountered an error.

Please enable FileVault manually."
    open "x-apple.systempreferences:com.apple.preference.security?FDE" || echo unable to open FileVault prefpane.  Continuing...
	break
	fi
done


## display alert and remove plist
if [[ $timeout = false ]]; then
	sudo jamf displayMessage -message "FileVault has been enabled."
    echo FileVault has been enabled.
    sudo rm /Users/Shared/.Jamf/fvSetup.plist && echo plist removed || echo plist not removed.
    exit 0
else
	
	sudo rm /Users/Shared/.Jamf/fvSetup.plist && echo plist removed || echo plist not removed.
    exit 1
fi

Hopefully this is helpful to some of you trying to optimize your FileVault workflow for new computer setups.