Case #: JAMF-0423603

@dan.snelson , @bartlomiej.sojka ,

I've been studying this whole thread as I'm seeing some of the same things. (OS 10.13.1, JAMF Pro 10.0.0-t1508873342).

Has there been any updates? Where I seem to be stuck now is after multiple recons - the individual recovery key matches the key generated by the 'fdesetup changerecovery' command, however the JSS still reports the Individual Recovery Key as invalid.

Are you seeing the same?

@acaveny There's lots of good information in the FileVault channel on MacAdmins Slack.

Are fresh High Sierra encryptions working as expected? If so, you know your Configuration Profiles are set correctly.

Here's the critical function of our script which is working well with macOS 10.13.2 betas (you can replace ScriptLog and jssLog with echo):

function issueNewRecoveryKey() { # Issue the new recovery key



    ScriptLog "Issuing new recovery key ..."



    # Check the OS version.

    OS_major=$(/usr/bin/sw_vers -productVersion | /usr/bin/awk -F . '{print $1}')

    OS_minor=$(/usr/bin/sw_vers -productVersion | /usr/bin/awk -F . '{print $2}')

    if [[ "$OS_major" -ne 10 || "$OS_minor" -lt 9 ]]; then



        jssLog "ERROR: OS version not 10.9+ or OS version unrecognized: `/usr/bin/sw_vers -productVersion`"



        exit 1



    else



        ScriptLog "Operating system version is: `/usr/bin/sw_vers -productVersion`; proceeding ..."



    fi



    ScriptLog "Unloading FDERecoveryAgent..."

    /bin/launchctl unload -wF /System/Library/LaunchDaemons/com.apple.security.FDERecoveryAgent.plist



    ScriptLog "Issuing new recovery key..."



    # Translate XML reserved characters to XML friendly representations. 

    # Thanks @AggroBoy! - https://gist.github.com/AggroBoy/1242257 

    userPassXMLFriendly=$( /bin/echo "$loginPassword" | /usr/bin/sed -e 's~&~&amp;~g' -e 's~<~&lt;~g' -e 's~>~&gt;~g' -e 's~"~&quot;~g' -e "s~'~&apos;~g" )



    /usr/bin/fdesetup changerecovery -personal -user "${loggedInUser}" -verbose -norecoverykey -inputplist << EOF

<?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>$loggedInUser</string>

    <key>Password</key>

    <string>$userPassXMLFriendly</string>

</dict>

</plist>

EOF



    result=$?



    if [[ $result -ne 0 ]]; then



        # Inform user of the error

        jamfDisplayMessage "FAILED: FileVault Configuration Tool exited with return code: $result. Please contact the GSC."



        jssLog "FAILED: FileVault Configuration Tool exited with return code: $result."



        exit $result



    fi



    ScriptLog "Loading FDERecoveryAgent..."

    # `fdesetup changerecovery` should do this automatically, but just in case...

    /bin/launchctl load -wF /System/Library/LaunchDaemons/com.apple.security.FDERecoveryAgent.plist &>/dev/null



    # Inform user



    /usr/local/bin/jamf recon



    jamfDisplayMessage "Recovery Key Reissued. Thank you."



    jssLog "Recovery Key Reissued; validate in the JSS"



    exit 0



}

@dan.snelson ,

New encryptions on new out of box 10.13 instances appear to be working.

Have you gotten any additional feedback from JAMF on the status of the open bug report (Case #: JAMF-0423603)

I will hop on the FileVault Slack channel.

Thanks!

@acaveny I've closed the Jamf case as 10.13.2 is working as expected for us in limited use-cases.

(Jamf and Apple are still working together on the nightmare that is SecureToken and fdesetup usingrecoverykey not being available on APFS drives.)

@dan.snelson FYI

https://forums.developer.apple.com/thread/97695

PS, requires an Apple Developer login as always.

Thanks, @donmontalvo.

Hey guys,

I know this is a topic that's been on and off for a while now, but we have a machine with a weird FV2 behavior and maybe someone around here has a clue.

We were testing @dan.snelson's script as well as the one from HomeBySix and both were failing, so after a bit of debugging, we noticed the error message saying "Error: Unable to change key." and we haven't found a way to change this behavior.

Additionally, we notice that if we go to the FV2 GUI in System Preferences and try to enable additional users, no matter how many times we click the Enable button, the additional user is never enabled.

We could go for decrypting / re-encrypting, but we are afraid there may be more machines in this scenario and fixing them manually is not the best choice.

Thanks for your insights!

@bearzooka
Like you I am in the same situation. I can successfully get 100% of new Macs to do the initial FileVault 2 setup and the initial escrow but about a third - so far of our Macs have subsequently ended up with broken recovery keys. These are all High Sierra with APFS machines. The broken machines are a mixture of 10.13.4, 10.13.5 and 10.13.6. I cannot tell if some of the 10.13.6 machines were on that version before they became broken or it is merely users have upgraded since they became broken.

I can say 10.13.4 and 10.13.5 machines have become broken.

I also tried an admittedly customised version of the HomeBySix script and had the same error as you. If anything it made the issue worse as a previously enabled account became broken for FileVault login - this was the account I was using with the script.

What is JAMS opinion on this problem?