FileVault can no longer renew recovery key.

[CorpIT_eB]

I have a simple policy setup that when used, use to issue out a new recovery key when the old was was used I would add a specific computer to that policy that would need a new recovery key and JAMF use to take care the rest. This is no longer working, I tried some of the scripts out there and could not get anything to work properly or would take a very long time to end up failing in the end. A while back ago, when I first set this up it was working without a problem.

My Current setup:

Error I am getting now:

Executing Policy Issue NEW FileVault2 Individual Recovery Key
Adding user JSSAdmin to filevault
Error: Added users failed error.
Error adding user to FileVault: Added users failed error.
New personal recovery key = '(...)'
Running Recon...
Retrieving inventory preferences from https://mycompnay.jamfcloud.com/...
Locating package receipts...
Locating accounts...
Searching path: /Applications
Locating software updates...
Locating printers...
Locating hardware information (Mac OS X 10.14.5)...
Gathering application usage information...

[easyedc]

So out of curiosity, if you pick one to test with and manually add your management account does it still fail? I'm getting issues attempting to reissue keys, but I've manually added them

fdesetup add -usertoadd JAMFAdmin

and then remote call my policy to run it

jamf policy -event fvnewkey
Checking for policies triggered by "fvnewkey" for user "xxxxxxxx"...
Executing Policy FileVault 2 - Reissue FileVault 2 Encryption Key - MANUALLY Generate New Key

Error: Authentication error.

It doesn't seem to be related to SecureToken either.

sysadminctl -secureTokenStatus JAMFAdmin
2019-07-03 10:20:56.224 sysadminctl[21653:296694] Secure token is ENABLED for user JAMFAdmin

When I run this against an APFS volume, I get more of a specific error

jamf policy -event fvnewkey -verbose
 verbose: JAMF binary already symlinked
 verbose: JAMF agent already symlinked
 verbose: Checking for an existing instance of this application...
Checking for policies triggered by "fvnewkey" for user "xxxxxx"...
 verbose: Checking for active ethernet connection...
 verbose: No active ethernet connection found...
 verbose: Removing any cached policies for this trigger.
 verbose: Parsing servers...
 verbose: Parsing Policy FileVault 2 - Reissue FileVault 2 Encryption Key - MANUALLY Generate New Key (922)...
 verbose: The Management Framework Settings are up to date.
 verbose: Found 1 matching policies.
Executing Policy FileVault 2 - Reissue FileVault 2 Encryption Key - MANUALLY Generate New Key

Error: An option or parameter is not supported for APFS volumes.
Submitting log to https://jamf.humana.com:8443/
 verbose: Policy error code: 402

But on the APFS one, it did actually generate a new key. Go figure.

[CorpIT_eB]

@easyedc I am in the processes of testing this very theory out now but in the past the policy never needed a script for it to work if I have to manually add the JSSAdmin account now that would be a problem as I never had to do that in the past.

[easyedc]

@CorpIT_eB So my thought about the manually adding the account give you some visibility about where that error could be coming from. We use 2 different accounts for different purposes

admin

and

JAMFAdmin

Admin is the one our front line support staff can log into for various issues if need be, and generally has rights to unlock drives with Filevault. We ran into an issue when we migrated from one JSS to our new JSS due to a server rebuilt that the keys didn't migrate so I had to recreate this on most of our fleet. JAMFAdmin does all our JAMF related work. So I used the workflow built by Rich Trouton (I think it was his work) to create a plist to import those credentials to authorize and then recreate the key that way. I think you can still use the plist method to deploy that user for rights to FV2. I just get stuck at the fact that the key still fails to regenerate even when there's authorized rights.

[CorpIT_eB]

@easyedc We are setup the same way we have an admin account that handles everything locally and then the JSSAdmin that we never touch on JAMFs side. (the heavy lifter)

I may have to add a script to add the user now going further out now which kind of sucks since I enjoyed the fact that this used work without the need for a script.

[easyedc]

@CorpIT_eB The old workflow was to throw a plist into a package and drop it onto the Mac in a random directory and import it there with a simple script (really, just an executed command). I dug out some of the old threads that I've been a part of on this topic and this one has some useful stuff. Issue New Recovery Key probably has the most info from various people. It has the post that I used to create the old reissue (10.12.x) but it also has someone providing the updated link to JAMF's script to do this. The only issue with the JAMF script that I see is user interaction is required, but you could probably take that out. Der Flounder's work is here. You might also check JAMF's work here.

[CorpIT_eB]

@easyedc Thank You, I have alot of JAMF scripts and several links I have not had a moment around here to test any of this stuff out to get it working again. I'll report more when I compile something.

Just sad that this no longer works out of the box like the Admin Guide says.

Thanks Again