FileVault 2 - Dealing with users who enabled FileVault on their own

[The_Lapin]

We have slowly rolled out FileVault 2 across our fleet of Macs with a good deal of success. However, I've found that a good number of our Macs were encrypted prior to our official deployment. These Macs do not have institutional keys and neither our management account or local admin account are listed as FileVault enabled on the Macs in question.

Looking at worst case scenarios I'm predicting a situation where someone leaves on bad terms and we're tasked with trying to unlock a Mac that they encrypted on their own. Obviously I'd like to avoid this.

So, do I have any options for programmatically disabling/decrypting these existing FileVault encrypted Macs, then re-encrypting them using Casper, thus giving us the recovery key and enabling our local admin user? I imagine not but figured I'd see if anyone found a creative solution before I start working with a couple dozen people to decrypt their Macs.

[JustDeWon · Accepted solution]

You can try this.. I can't remember where I got this script from. But this prompts user's for their current password they used to enabled FileVault2.. This redirects a new FileVault2 key to Casper..

#!/bin/bash

####################################################################################################
#
# Copyright (c) 2013, JAMF Software, LLC.  All rights reserved.
#
#       Redistribution and use in source and binary forms, with or without
#       modification, are permitted provided that the following conditions are met:
#               * Redistributions of source code must retain the above copyright
#                 notice, this list of conditions and the following disclaimer.
#               * Redistributions in binary form must reproduce the above copyright
#                 notice, this list of conditions and the following disclaimer in the
#                 documentation and/or other materials provided with the distribution.
#               * Neither the name of the JAMF Software, LLC nor the
#                 names of its contributors may be used to endorse or promote products
#                 derived from this software without specific prior written permission.
#
#       THIS SOFTWARE IS PROVIDED BY JAMF SOFTWARE, LLC "AS IS" AND ANY
#       EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
#       WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
#       DISCLAIMED. IN NO EVENT SHALL JAMF SOFTWARE, LLC BE LIABLE FOR ANY
#       DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
#       (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
#       LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
#       ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
#       (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
#       SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
#
####################################################################################################
#
# Description
#
#   The purpose of this script is to allow a new individual recovery key to be issued
#   if the current key is invalid and the management account is not enabled for FV2,
#   or if the machine was encrypted outside of the JSS.
#
#   First put a configuration profile for FV2 recovery key redirection in place.
#   Ensure keys are being redirected to your JSS.
#
#   This script will prompt the user for their password so a new FV2 individual
#   recovery key can be issued and redirected to the JSS.
#
####################################################################################################
# 
# HISTORY
#
#   -Created by Sam Fortuna on Sept. 5, 2014
#   -Updated by Sam Fortuna on Nov. 18, 2014
#       -Added support for 10.10
#       -Updated by Sam Fortuna on June 23, 2015
#           -Properly escapes special characters in user passwords
#
####################################################################################################
#
## Get the logged in user's name
userName=$(/usr/bin/stat -f%Su /dev/console)

## Get the OS version
OS=`/usr/bin/sw_vers -productVersion | awk -F. {'print $2'}`

## This first user check sees if the logged in account is already authorized with FileVault 2
userCheck=`fdesetup list | awk -v usrN="$userName" -F, 'index($0, usrN) {print $1}'`
if [ "${userCheck}" != "${userName}" ]; then
    echo "This user is not a FileVault 2 enabled user."
    exit 3
fi

## Check to see if the encryption process is complete
encryptCheck=`fdesetup status`
statusCheck=$(echo "${encryptCheck}" | grep "FileVault is On.")
expectedStatus="FileVault is On."
if [ "${statusCheck}" != "${expectedStatus}" ]; then
    echo "The encryption process has not completed."
    echo "${encryptCheck}"
    exit 4
fi

## Get the logged in user's password via a prompt
echo "Prompting ${userName} for their login password."
userPass="$(/usr/bin/osascript -e 'Tell application "System Events" to display dialog "Enter your computer login password to unlock FileVault2 (Casper Admin):" default answer "" with title "Login Password" with text buttons {"Ok"} default button 1 with hidden answer' -e 'text returned of result')"

echo "Issuing new recovery key"

if [[ $OS -ge 9  ]]; then
    ## This "expect" block will populate answers for the fdesetup prompts that normally occur while hiding them from output
    expect -c "
    log_user 0
    spawn fdesetup changerecovery -personal
    expect "Enter a password for '/', or the recovery key:"
    send "{${userPass}}"
    send 
    log_user 1
    expect eof
    "
else
    echo "OS version not 10.9+ or OS version unrecognized"
    echo "$(/usr/bin/sw_vers -productVersion)"
    exit 5
fi

exit 0

[bmarks]

@JustDeWon FYI, there's a newer version of that script available from JAMF's Github page.

https://github.com/JAMFSupport/FileVault2_Scripts/blob/master/reissueKey.sh

Also, for a few months back in the Spring, we were testing both that one and another one that our TAM gave us:

https://github.com/homebysix/misc/blob/master/2015-01-27%20MacBrained%20Reissuing%20FileVault%20Keys/reissue_filevault_recovery_key.sh

I mention both because your mileage may vary. We went around and around trying to resolve issues with the popup not being displayed at all on El Capitan. We ended up needing the 2nd version because it resolved those issues which were specific to the "Recurring Check-in" policy trigger. However, the one on JAMF's Github site has a much more recent modification date now, so it might also now work with all of the policy triggers. I haven't tested that one since its most recent update.

[The_Lapin]

@JustDeWon - Thanks! That'll help quite a bit. I modified it a bit to go ahead and add our management account as well. This'll be much easier to roll out as it won't require decrypting for hours, instead it'll just grant us access to the existing encryption.

[drew_duggan]

@The_Lapin and @JustDeWon The script works great, but running the script alone won't actually submit the newly generated recovery key to the JSS. The prerequisite for this to work as you need it to first deploy a configuration profile to the machine(s) with a FileVault Recovery Key Redirect payload included to send new keys to the JSS. Once that's in place, you can run this script in a policy to get a key stored in the JSS.

[koalatee]

Just want to chime in on @bmarks post. We have been using the homebysix script and it's been great.

If you want institutional keys added, you will have to look elsewhere, these scripts are just for the recovery/individual keys. Once your JSS has the key, it should have no issue adding your management account as a FV2 authorized user.