Filevault Recovery key is missing

[Asifahmed]

Hell Team,

I am looking for a solutions to get the recovery key in my JAMF console for those mac devices recovery key is missing, but user should be interrupted. I can see it has happened for both personal and institutional key. What is the main concept of personal recovery key validation, some time it is showing invalid or unknown but recovery key is there, strange! Please help to understand and also with a perfect resolution I am looking for. BTW device is getting encrypted by a config profile and to escrow the key in JAMF.

[PhillyPhoto]

I use a modified version of this script and it's been helpful for us

https://github.com/homebysix/jss-filevault-reissue/blob/main/reissue_filevault_recovery_key.sh

[Asifahmed]

But this script will run on Big Sur and Monterey OS?

And is it not possible to escrow without any user's prompt? I mean full silent operation.

[Asifahmed]

https://docs.jamf.com/technical-papers/jamf-pro/administering-filevault-macos/10.30.0/Issuing_a_New_...

Is that link works fine?

[stuartluscombe]

When you say 'modified', in what way? We are also using this script but are running into some issues with Big Sur/Monterey where the key is not being picked up.

[BradJr]

We're also seeing some machines that have had new FV recovery keys (PRK) issued followed by a recon, which does update it in Jamf. Fast forward a week or so and those same machines are back on the list of "unknown" with some of them not having the key available once again while others just have the status of "unknown". 

[macguitarman]

Seeing the same exact thing @BradJr, but it only takes a few days or so. Something is up. And it is becoming "Unknown". I have reached out to Frederick, Traveling Tech Guy...

[RAnderson1]

Any luck finding a solution? We've been seeing this this for some of the computers in our environment, too...

[BradJr]

Still nothing that I've seen or heard of yet. Seems like there is definitely something up but perhaps we'll see some of a resolve as we begin upgrading to Ventura.

Not sure if anyone else has seen the same issue on any Ventura machines yet?

[BradJr]

Just replying to say, we’ve finally gotten Escrow Buddy implemented in our environment and it’s truly been a lifesaver when it comes to those FV recovery keys!

Thanks to Elliot Jordan here from the forum and team for creating that tool, it’s been outstanding 

https://github.com/macadmins/escrow-buddy

[Asifahmed]

Does it reissue the key and escrow in JAMF console or it just escrow the key in JAMF which was not escrowed in JAMF console before. And does it need recovery partition to use this tool?

[elliotjordan]

@Asifahmed - The primary use case for Escrow Buddy is to regenerate and escrow keys that were missing from Jamf, but you can decide which Macs to target based on a smart group of your choosing.

If you're asking whether any changes are needed in Recovery Mode to use the tool, the answer is no.

[macguitarman]

@Asifahmed, elliotjordan gave the answer so you should be all set. I can chime in with a few points. I have not used Escrow Buddy but FV Reissue PRK script and profile that is mentioned above. I think Escrow Buddy forgoes the need for a config profile not sure, would have to look at it. What I have noticed in my travels, when rolling out a new Jamf Pro, there are no Macs yet enrolled so there are Invalid PRKs, and if I am not mistaken, I believe in some later version of Jamf Pro 10x and 11, Jamf now has this built in as part of a FV enabling config profile, it now has an Escrow PRK (I think that feature has been there for a bit, but there may be something new with regards to PRK ). So any Mac that gets (ADE I would think, why any other way) enrolled, and has a FV enable requirement is going to FV enable and escrow the key and show as "Valid", so you are good. When we inherit a Jamf Pro environment and FV is involved, for sure we are going to see FV enabled, but the PRK is "invalid", hence we need a Smart Group that shows "Invalid", and scope something like Escrow Buddy to these Macs. I think Escrow Buddy does not invoke a window and a corresponding user password entry, which is great. It's just transparent. And about Recovery Partition and FV, not related really. But there is no Mac I have seen where macOS installed correctly and there is Recovery Partition, in other words in macOS is booting / working, there by definition is a present and functioning Recovery Partition. Another thing about macOS Recovery Part. Have you noticed for Apple silicon, Macs there is no situation where when you "Erase Mac" you wind up with zero Recovery Part. On Intel Macs, when one Erase a Mac, of deleted / erased the main Volume in Disk Utility, there is nothing to boot from, and hence you would see the "spinning Globe", which you are booting from Apple's AIR server. With Apple silicon Macs, even with Erase Mac, Disk Util erase volume, the Recovery Partition is always there, cannot be deleted, not sure how Apple did this, some boot volume that can never be deleted. I for one am grateful Apple finally did this.

[Asifahmed]

I implemented it and working fine, now question is when I can see recovery key is escrowed in my JAMF console, then can I remove those machines from my config profile or should I keep in the scope?

[macguitarman]

You don’t have to touch / adjust the config profile. It’s the Smart Group scoping criteria. The criteria is ‘not Valid’, so only those Macs would show up in the Smart Group. Once a Mac from that group gets a new / valid PRK, it will drop out of that group. The number will keep going down.

[macguitarman]

https://hcsonline.com/images/PDFs/Jamf_Recovery_key_Filevault.pdf

[jklimeck-ahead]

Some say a reboot makes Valid stick. Run the PRK Re-issue policy again, user enter password, but this time the Mac reboots. So a reboot somehow makes "Vaild" stick...This seems to be working on some of the Macs / users that I have worked with...

[gsealander]

I'm still seeing this happen on various versions of Monterey and Ventura. I've submitted a ticket to hopefully understand why this is happening.

[Asifahmed]

I would request you to let me know if you get a  solution. 

[gsealander]

I was told by support that this is "expected behavior because the process that Apple uses to grab that key can be inconsistent." And Jamf support said that I should run a recon after the reissue key policy runs. I already have a recon as part of that policy, but was told that isn't enough. 

So sadly this is still happening and I have not yet found a real solution or explanation. 

[elliotjordan]

Hi all! 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!

[macguitarman]

This is excellent, I guess the key is regenerated and escrowed on login and that password.

Much better, it will be much more transparent.

Thanks, John K

[mfletch]

Wow, very cool!