Confusion with FV2 'Unknown' validation, escrowing keys, and possible rotation?

[Nate1]

Each week we go through and find the machines that have a 'Filevault 2 Individual Key Validation' of 'Unknown' and reach out to those users to resolve (via check in, reboot, etc).

My confusion is why they validations becomes 'Unknown'. I imaged a machine recently and the validation was 'Valid' and everything was fine, but after turning it off for a few days it later became 'Unknown'. What causes Jamf to no longer recognize the key is valid? The machine was imaged and had a valid key then only a day or two later it became 'Unknown'.

Did it try to rotate itself and the new key just needs to be validated by Jamf? If that's the case, how can we change the rotation frequency?

Does it regularly need to check-in with Jamf to validate the key even though it hasn't changed? If so, how can we tell it to validate the key less frequently?

We have a smart group enabled and use the 'Issue new FV key' policy on it but we aren't sure if that's helping at all

https://learn.jamf.com/bundle/jamf-pro-documentation-current/page/Managing_FileVault_on_Encrypted_Co...

Thanks for any insights!

Nate

[Tribruin · Accepted solution]

We see this regularly in our environment. I have never quite figured out why it happens, but i have been told it has to do with the SecurityInfo MDM command that is sent during an inventory update. 

I have a Smart Group that tracks this and I notice the number is really high on Monday and then goes down during the week. Maybe Jamf doesn't get the return value of the MDM command in time since the computers are sleeping over the weekend?

Either way, we add a policy to run an additional inventory (once per day) for any computer in that Smart Group. So, if a computer falls in to that Smart Group, an additional inventory collection will run at the next check-in. in many cases that fixes the issue. We do some tracking of computers that stay Unknown for more than a day and have a remediation policy to rotate the key (needs user interaction.) 

[mario_magnus]

I have the same problem, could you provide the remediation policy that you are using to fix that problem?

[Nate1]

I believe Tribruin is just saying to run an Update Inventory policy on machines with this issue.

For example, I have all my 'Unknown' FV2 machines in a smart group, then on that group I run an inventory update policy (New policy > maintenance tab > update inventory). Since I only run this update inventory on this smart group of 5-30 machines, I have it run on each check-in. Its a little overkill but once they update their inventory they should fall out of the smart group and therefor off the scope of the frequent updates.

The rest of the fleet (with healthy FV2) update their inventory once per day.

So far it seems to be working! I'll report back in here in a week or so with better updates because like the others mentioned, it's always high on Monday after the machines have been off all weekend then slowly falls off as they normally update inventory. This should likely just speed it up.

[shannon_pasto]

I'm seeing this as well and as @Tribruin mentioned it is usually high early in the week. In my case I escalated to Jamf as I had 30 reporting unknown or invalid on a Sunday then on Monday it was down to 15. I've spent the last 24 hours getting this number down to 5 then this morning up to 8. This might be just something we need to monitor and action if a device stays in the group too long

[ssoun]

We have this same issue at our place, usually just running a recon will resolve it, if the status was Unknown. If it's Invalid, you usually have to run the re-issue FV2 script, which requires user intervention.

[mario_magnus]

@ssoun that's what I mean - the update inventory does not resolve the invalid status. Can you share the script because what I found on Jamf's Github page doesn't seem to work.

[ssoun]

This is what I use, https://github.com/homebysix/jss-filevault-reissue/blob/main/reissue_filevault_recovery_key.sh, but slightly modified because I have an Okta workflow to create a Jira ticket if the script doesn't work. I have found that the script works really well. This script also works if you're using Dialog for prompts, https://github.com/robjschroeder/FileVault-Personal-Recovery-Key-Reissue/blob/main/FileVault%20PRK%2... but requires some modifications if you're using Jamf Connect and alias.

[mario_magnus]

thx @ssoun - I'll take a look at the scripts...

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

[judeglenn]

Hey there @elliotjordan - I'm in the process of testing/implementing EscrowBuddy. Everything appears to be configured and deployed correctly. Extension attributes say that it is configured even. However - FileVault status still shows Unknown after logout/login. I suspect it is due to Jamf Connect. Do you have any resources on how to implement EscrowBuddy with Jamf Connect?

[elliotjordan]

Hi @judeglenn — I'd recommend checking the Escrow Buddy logs (details on how to do that are on the FAQ page) and if that doesn't lead you to the root cause, open an issue on GitHub and I'll try to help troubleshoot. I haven't heard anybody report issues with using Jamf Connect and Escrow Buddy together so far.