Potential Cause and Solution for Missing FileVault Keys

[bmarks]

There have been a number of threads regarding missing FileVault keys. I have started and/or responded to some of them. For us, this has been a years-long issue and up until recently, we used fde-rekey to fix them silently. But, fde-reky is broken on High Sierra and we didn't want to use either the Jamf or homebysix scripts because they prompt users for passwords (a political issue in our environment.) We started digging much deeper with the help of our Jamf support person, and we think we have discovered some very important info.

In our environment, it turns out the keys weren't actually missing. Even though affected Macs were still encrypted, the key validation field would say "unknown," the FileVault 2 section under Management would say "Not Configured" and the button to show the key would be gone. To us, this made it seem like the keys must be missing so we created policies to generate new keys. This would "fix" the issue but it turned out that it was completely unnecessary.

What we learned is that the Jamf binary was returning a value of "unknown" during key validation (which happens during a Recon which for us happens daily.) When the "unknown" status was sent to the Jamf database, it caused the "key_deleted" field to be flipped from 0 to 1 indicating the key had been deleted. This would then cause the other status changes mentioned earlier. We think the "unknown" status is being triggered when key validation experiences an error, maybe because the key is locked at the time of the Recon. We are still investigating. What we do know is that it doesn't fix itself.

The solution is to flip that database value from 1 back to 0. When you do this, the button to show the key re-appears in the console and the Management->FileVault 2 section goes back to saying "Configured." What doesn't change instantly is the key status. It still says "unknown" but this is fixed as soon as you perform another Recon.

If you have access to MySQL, you can validate whether this is the issue you are experiencing by issuing the following two commands where "Jamf Pro Computer ID" is the Mac record number from the JSS:

select key_deleted from file_vault_2_computer_key where computer_id = "Jamf Pro Computer ID";
UPDATE file_vault_2_computer_key SET key_deleted = "0" WHERE computer_id = "Jamf Pro Computer ID";

If you run these MySQL commands using the record number of an affected Mac, you should see instant results. This is, of course, assuming your issue is the same. For that, I make no guarantees.

If this works and you need to do it for a high number of Macs, your Jamf support agent may be able to help you will commands that will update them all at once. We were able to fix 5,700 Mac records in seconds. However, I want to ask our support person before putting up the command we used because I'm not sure whether it is specific to our environment or not.

I hope this helps others. If this has been posted elsewhere, I searched but I didn't find anything in advance of posting this.

If anyone has ideas regarding what might "lock" keys during key validation or what else might trigger the "unknown" status, please share that info because that may help fix this behavior once and for all.

[bmarks]

If you aren't comfortable running MySQL commands via Terminal, you can also download a free tool like Sequel Pro.app or MySQL Workbench.app. And, always make a backup first of course. With that said, the above commands only modify a single Mac record, so you shouldn't have to worry too much about borking your database.

[lashomb]

Depending on your verification strategy, this would take care of it in one line

UPDATE file_vault_2_computer_key SET key_deleted=0 WHERE (key_deleted=1 and individual_key_verified=1);

[mesmerli]

I got the same issue but our help desk said no key_deleted key in the record.
Could anybody know any identical key as key_deleted in the latest Jamf?
Thanks!