FileVault Key Escrow error

wsg
New Contributor III

I have a smart group that looks for invalid FV keys to determine if the key needs to be redirected to JSS:

3ae6fb12f5204bd7bfed679aafccd5a2

Based on that, it'll run the following script (https://github.com/JAMFSupport/FileVault2_Scripts/blob/master/reissueKey.sh):

#!/bin/bash

####################################################################################################
#
# Copyright (c) 2017, 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
#   -Updated by Bram Cohen on May 27, 2016
#       -Pipe FV key and password to /dev/null
#   -Updated by Jordan Wisniewski on Dec 5, 2016
#       -Removed quotes for 'send {${userPass}}' so
#       passwords with spaces work.
#   -Updated by Shane Brown/Kylie Bareis on Aug 29, 2017
#        - Fixed an issue with usernames that contain 
#       sub-string matches of each other.
#   -Updated by Bram Cohen on Jan 3, 2018
#       - 10.13 adds a new prompt for username before password in changerecovery
#
####################################################################################################
#
## Get the logged in user's name
userName=$(/usr/bin/stat -f%Su /dev/console)

## Grab the UUID of the User
userNameUUID=$(dscl . -read /Users/$userName/ GeneratedUID | awk '{print $2}')

## 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="$userNameUUID" -F, 'match($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 old password to send Jamf your FileVault recovery key:" 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 ]] &&  [[ $OS -lt 13 ]]; 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
    " >> /dev/null
elif [[ $OS -ge 13 ]]; then
    expect -c "
    log_user 0
    spawn fdesetup changerecovery -personal
    expect "Enter the user name:"
    send {${userName}}
    send 
    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;

The script seems to work fine when running sudo jamf policy, but if executed automatically, it runs into the following message:

Executing Policy Escrow FileVault Key
Running script reKey Existing FileVault...
Script exit code: 0
Script result: Prompting t-rex-dawnbreaker2 for their login password.
36:232: execution error: An error of type -10810 has occurred. (-10810)
Issuing new recovery key
Error: Password is required.
Error: User could not be authenticated.
Error: Unable to unlock or authenticate to FileVault.

This is happening on Sierra and High Sierra macOS.

Thoughts?

1 ACCEPTED SOLUTION

steve_summers
Contributor III

Hey @iterable , looking at your post, it looks like what I was going through using that same script from Jamf. I was seeing errors just like yours. So, I came across another script/workflow and it actually works. I'm in the process of getting keys reissued to folks who have a "Not Configured" status on their recovery keys in their computer record. Here is a link to the script I am using:

https://github.com/homebysix/jss-filevault-reissue

Now, it's easier to break out the non-High Sierra users vs High Sierra ones. I've tested this with success on non-High Sierra people and haven't really ran it on 10.13 folks. It may, or may not work, so just wanted to mention that nugget for you.

I like this workflow for it allows me to pop up a branded message notifying customers about entering in the PW. Just remember to make sure you have the JSS Redirection policy in place on these machines or this script too will error.

Good luck..!

View solution in original post

8 REPLIES 8

SeanA
Contributor III
but if executed automatically, it runs into the following message:

What do you mean by "automatically"?

Is the user on the client machines being prompted for their password (as the script is trying to do)?

steve_summers
Contributor III

Hey @iterable , looking at your post, it looks like what I was going through using that same script from Jamf. I was seeing errors just like yours. So, I came across another script/workflow and it actually works. I'm in the process of getting keys reissued to folks who have a "Not Configured" status on their recovery keys in their computer record. Here is a link to the script I am using:

https://github.com/homebysix/jss-filevault-reissue

Now, it's easier to break out the non-High Sierra users vs High Sierra ones. I've tested this with success on non-High Sierra people and haven't really ran it on 10.13 folks. It may, or may not work, so just wanted to mention that nugget for you.

I like this workflow for it allows me to pop up a branded message notifying customers about entering in the PW. Just remember to make sure you have the JSS Redirection policy in place on these machines or this script too will error.

Good luck..!

wsg
New Contributor III

@SeanA running the policy. @steve.summers, thank you, I'll take a look at the project.

jeffkh
New Contributor II

The "solved" answer is not really a solution. The homebysix script does not work with High Sierra, I've tested.

There really does not seem to be any reliable way to make this work in 10.13+. Jamf, get your act together this is basic functionality that your product is missing. We are shopping alternative MDM solutions, Jamf is just too unreliable for us.

hope_gibson
New Contributor II

Has anyone experienced this issue with any Beta versios of Mac OS? I've got one MBP that is being troublesome and the only difference is that its on Mojave Beta

Lotusshaney
Contributor II

The homebysix script works fine on both 10.13 and 10.14. I use it all the time, scoped to macs with invalid keys.

If you having a problem it may be worth removing the escrow profile and reapplying it. If not reenrolling the Mac can also fix problems.

hope_gibson
New Contributor II

@Lotusshaney I also have this script in place but have one MBP that this policy fails to work. We've removed framework, deleted the record from the DB and re-enrolled 3 times but each time it tries to run on this one computer it errors. The MacOS is 10.14.6 so and i've seen it work on others with the same version. I'm just not sure what else to try aside from turning off FV and re-enabling. Thoughts? Suggestions?

elliotjordan
Contributor III

Hi! I'm the maintainer of the jss-filevault-reissue workflow referenced above, and I've got a quick update that may be of interest to you.

My team has published a new tool called Escrow Buddy, which regenerates FileVault keys at the loginwindow, thus avoiding the need to prompt users for their password later. It should be suitable as a drop-in replacement for my previous jss-filevault-reissue workflow at most organizations.

You can read more in this announcement on the Netflix Tech Blog, and this post on my site specifically covers migrating from my old workflow to Escrow Buddy. Escrow Buddy's source code and installer are available on GitHub.

Thanks!