FileVault recovery key escrow changes in 10.13 and has a new payload. Apple has documented this change in its Developer articles:
https://developer.apple.com/library/content/featuredarticles/iPhoneConfigurationProfileRef/Introduction/Introduction.html#//apple_ref/doc/uid/TP40010206-CH1-SW42

Worth looking at that.

Thanks, @emily.

My current understanding is that the new "Security & Privacy > FileVault > Enable Escrow Personal Recovery Key" option available now in Jamf Pro 10 Beta 2 will be available when 9.101.0 is released.

When encrypting a macOS 10.13 test machine with a Jamf Pro 10 Beta 2 policy, all works as expected (i.e., the Recovery Key is escrowed in the Jamf Pro Server).

I'm getting the error when trying correct invalid Recovery Keys on computers running macOS 10.13 with AFPS.

I'm seeing a similar problem in the release version of 9.101 and the 10.13 GM. Regenerating the key via policy (with the management account setup as a FV user) throws an error. The logs in the JSS don't say much, so I ran it as a custom trigger in the terminal with verbose.

I get the following error:

verbose: Policy error: 402

So far redirection and regeneration of personal keys is the big bad bug of the new release in my testing.

So far this has only been tested on an iMac with SSD running APFS. No clue if going to HFS+ makes a difference

@dcgagne We're seeing the same with 9.101.0 and macOS 10.13.0 (17A362a). Our case number is: JAMF-0405419.

@dan.snelson Thanks, let us know how it goes.

If it helps, I disabled the new escrow on a fresh install and loaded the older key redirection config profile to see if it made a difference. It shows the same behavior. Key regeneration as a policy fails and manually running "fdesetup changerecovery -personal" regenerates the key but is not redirected.

@dcgagne did you try running recon after regenerating the key to see if the computer record updated? I found when enabling FV2 with 9.101 on a 10.13 machine that the key didn't appear on the computer record until I ran a recon on the machine.

@emily We make sure to run recon after any key regeneration as a matter of policy and it didn't make a difference for us. Any combination manual/policy key regeneration and recon makes it show as "Invalid" and only has the key from the original escrow.

edit That may be confusing. We can escrow the key once when FileVault is turned on, but changing the key afterwards is where the escrow fails. That's a problem for us because if the recovery key is ever used for a login issue we require it be changed and make our compliance auditors happy.

@emily Confirming @dcgagne's experience: With JSS 9.101.0 and macOS 10.13 Beta (17A362a), fresh encryptions work as expected (i.e., the key is escrowed and is visible in the JSS as expected). Attempting to re-generate the key fails.

My rock-star STAM, @tom.koehler, has confirmed that this issue is something the Jamf engineering team is aware of and working on.

My rock-star STAM

Aww, shucks :)

Thanks for the update! It's a frustrating bug but it's nice to have it acknowledged.

Unfortunately this doesn't look like a Jamf bug. It's working as intended for APFS drives according to Apple (via man fdesetup). No passing in a recovery key for changerecovery with APFS.

changerecovery -personal | -institutional [[-keychain] | [-certificate path_to_cer_file]] [-key path_to_keychain_file] [-inputplist] [-verbose]
Adds or updates the current recovery key. Either personal and/or institutional options must be specified. When changing the personal recovery key, the updated personal recovery key will be automatically generated. When changing either key, the old value will be removed and replaced. Because APFS volumes require an OD authentication before it will allow for the change, the current recovery key cannot be used for the authentication. On CoreStorage volunes the -key option can be used to unlock FileVault. More information on this is described elsewhere in this document.

You may want to consider moving to a workflow like https://github.com/homebysix/jss-filevault-reissue or similar.

@owen.pragel Have you been able to successfully re-issue a recovery key with OD credentials on a macOS 10.13 Beta machine with an APFS-formatted drive? (I receive an error 136, which isn't included in the man page for fdesetup of macOS build 17A362a.)

Just a little update from my testing.

Scenario 1:
A device has the key set as "invalid" and is then decrypted and re-encrypted using the new config profile and manually enabling FV2 using a Self Service policy. A recon is performed. Result - The key shows up as "unknown." Attempting to regenerate changes key status to "invalid"

Scenario 2:
A device with a valid key escrowed is reimaged, but its inventoried information is not removed from the JamfPro server. Its original key is still escrowed. After the reimage and enrollment, the FV configuration profile is applied and our normal workflow of installing software and applying a policy to enable FV is followed. A recon is performed. Result - The key shows as unknown. Manual regeneration/recon changes its status to invalid. However I jotted down the recovery key that was generated on the terminal and noticed it appeared in the JamfPro server. When I ran recon again it changed status to "Valid."

That made me scratch my head so I went back to the scenario 1 device that was still encrypting with an "invalid" key. I manually regenerated the recovery key again from the terminal and jotted it down. Ran recon. The key shows as "Invalid." However, the key I wrote down is in the Management section of the JSS for the device. I ran another recon and suddenly it updated to valid!

Needless to say this is very odd behavior. It's excellent to know the key is being regenerated and escrowed. It's less excellent that it takes multiple recons in these scenarios.

I can now reliably recreate this on my test machines. It appears the first recon escrows the key, but fails to validate it correctly. The second recon performs no escrow, and only validates the key which then passes. I would venture there is a workflow issue with the new config profile escrow and jamf recon.

Thanks for the additional details, @dcgagne.

@dan.snelson, the Beta 3 (17B42a) is out and the error code 136 is still there. You can add these two OpenRadar reports to the list. I've sent a bug report to Apple and recommend everyone to do the same. @owen.pragel, the man is correct and providing current recovery key results with error 34, but if you provide incorrect or mistyped password the key is gone forever (136).

@bartlomiej.sojka Thanks for testing; I've updated my open bug report with your two reports.

@dan.snelson Two betas later (17B46a) and the bug is still there. I'm getting worried.

@bartlomiej.sojka Two words: Bummer city. Thanks for keeping this on your radar. (I’m traveling home from JNUC and have yet to test.)

Beta 5 and the bug is still there... incorrect password or password of non-console user given and the FV2 recovery key is deleted. Simply insane and a regression of behavior since fdesetup first appeared in 10.7 all the way to 10.12. And yeah that's not even counting the fact that the behavior was changed so that the current recovery key does not work anymore either (yes, I saw above and in the man page as well about OD auth which seems like BS TBH...) which breaks Jamf Pro policy payload to "Issue New Recovery Key"

http://www.openradar.me/radar?id=4943461371346944

@brunerd & @bartlomiej.sojka Our AppleCare rep just emailed me that macOS 10.13.2 (17C60c) should resolve this issue.

(I'm busy getting macOS 10.13.1 out to our testers this morning and should be able to report back later today.)

@dan.snelson Indeed it does. They've added a username prompt and the code 136 is no more – only 11 if the password is incorrect or 34 if you try to use recovery key (argh!).

@bartlomiej.sojka Thanks for confirming what I'm seeing; have you successfully been able to re-issue a Recovery Key? (My unaltered script from 10.12.6 produced an error 11 with the correct password.)

Well, I haven't tried it yet, but since there's an additional step – username prompt – I believe you'll have to ensure your script adds a -user flag with proper user's short name.

@bartlomiej.sojka You're correct; adding -user did allow the Recovery Key to be re-generated, but the new key doesn't appear to be escrowed in the Jamf Pro Server 10.0.0-t1508873342 (which seems odd to me as the macOS 10.13.x-specific FileVault Recovery Key Escrow payload successfully captured the original key). Three recons later and the original key is still displayed in the Jamf Pro Server.

Here's the macOS 10.13.2 variation of the critical function we're using ...

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

    jamfDisplayMessage "Recovery Key Reissued. Thank you."



    jssLog "Recovery Key Reissued; validate in the JSS"



    exit 0



}

Without -norecoverykey, I can see the new key in the client-side log (which I presume means it won't be escrowed in the Jamf Pro Server).