fdesetup changes in macOS 10.13 (17A360a): Exit Code 136

[dan-snelson]

Radar / OpenRadar: 34371492

---

While testing a custom Bash script to re-issue a personal FileVault Recovery Key with macOS 10.13 (17A360a) and an APFS-formatted drive, we’re receiving an Exit Code of 136, which is NOT listed in the man page for fdesetup.

We’re seeing the following errors in the logs:

Unloading FDERecoveryAgent...
/System/Library/LaunchDaemons/com.apple.security.FDERecoveryAgent.plist: Could not find specified service

Error: Unable to change key.
FAILED: FileVault Configuration Tool exited with return code: 136.

The script works as expected while running macOS 10.12.6 (16G29).

[emily]

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/Introduct...

Worth looking at that.

[dan-snelson]

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.

[dcgagne]

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

[dan-snelson]

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

[dcgagne]

@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.

[emily]

@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.

[dcgagne]

@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.

[dan-snelson]

@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.

[dan-snelson]

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

[tom_koehler]

My rock-star STAM

Aww, shucks :)

[dcgagne]

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

[owen_hael]

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.

[dan-snelson]

@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.)

[dcgagne]

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.

[dan-snelson]

Thanks for the additional details, @dcgagne.

[bartlomiejsojka]

@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).

[dan-snelson]

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

[bartlomiejsojka]

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

[dan-snelson]

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

[brunerd]

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

[dan-snelson]

@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.)

[bartlomiejsojka]

@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!).

[dan-snelson]

@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.)

[bartlomiejsojka]

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.

[dan-snelson]

@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).

[dan-snelson]

Case #: JAMF-0423603

[acaveny]

@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?

[dan-snelson]

@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

}

[acaveny]

@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!

[dan-snelson]

@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.)

[donmontalvo]

@dan.snelson FYI

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

PS, requires an Apple Developer login as always.

[dan-snelson]

Thanks, @donmontalvo.

[bearzooka]

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!

[jelockwood]

@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?