FileVault Individual Key and JSS Upload

I was under the impression that the key gets escrowed at the time of enablement and the recon just updates the status of the machines encryption status.

I know that if I don't add a Recon at the end of everything, the key doesn't immediately get uploaded. I've repeated this a few times. There's something wrong with this workflow, but I can't put my finger on it. What might be different about enabling FV via an small GUI that triggers a policy vs. running that policy directly in Terminal?

Yes, if the Mac doesn't perform a recon within a period of time, though I don't know what the limit is, the key residing in the plist file stored on the Mac doesn't get picked up by the jamf binary into the Mac's record in the JSS. You need to ensure you are getting a recon done in a reasonable amount of time after enablement or the key could get lost. I've seen this happen myself actually, so just make sure an inventory collection gets done soonish after enablement.

EDIT: Actually the situation mentioned above is how it has worked for us in the past, but I wonder if the JSS is using something different now to get that Recovery key uploaded. I think it still needs to use a local plist file with the key in it, but I'm not 100% sure, so don't take my word for it as it is today. My experience on the above may be a bit out of date.

I think I fixed my own issue by creating a Recon policy at boot and that's ongoing (separate from the normal recurring check-in Recon policy that's the weekly default.) Our FV config is set to enable at logout, and I guess that interrupts any Recon that might also be scheduled to run as part of the policy itself since you enter the user password and then immediately restart.

Because, if it's true about the key being in a temp .plist (and I had a hunch that was the case which is why I started this thread) and the .plist does eventually get deleted or it expires, then by the time our normal Recon would run, the key would no longer be there.

I also want to know details on how the IRK is escrowed as I have a dozen or so Macs with it missing in inventory. This would be with machines that had FV enabled via policy and completed encryption but don't show a Disk Encryption Configuration being present nor the recovery key.

I don't know the specifics, but I'm pretty sure the info in this thread is correct now that I've worked on these issues some more. I had to adjust my inventory collection policy so that inventory is now collected at the first reboot after FV is enabled. Adding inventory collection to this specific policy doesn't appear to do anything because it gets interrupted before it can perform a Recon.

If your affected Macs only recently had FV enabled, you can try just running a Recon to see if the data gets uploaded to your JSS. Again, I don't know how long that window is open to do so as mentioned earlier in this thread, but it does appear that eventually an upload-able key does "expire."

There are a couple ways to fix missing keys too. The simplest is to create a policy that re-issues the keys but I haven't had much luck getting that to work. So if that doesn't work, there's another option that involves a config profile, a script from JAMF and a policy.

We're using this to get the FileVault Keys Re-Issued:
Link To GitHub

That's exactly what we're using but it still led to the issue that caused my creation of this thread. Also, I don't think that all the triggers mentioned for that script fully function in El Capitan. We could no longer get the "recurring check-in" trigger to work for the procedure outline on that page.

We haven't moved onto El Capitan yet, as we're waiting on the STIG to get released, but this seems to work fine in Yosemite.

Is it failing as a Self Service policy, too? We did notice that there were issues if the FV2 password was out of sync with the current user password. In that case, we'd get an error in our policy logs that mentions "did not return exit 0" - since I had to add some debugging to diagnose and find these failures.

The other thing we see when running as "recurring check-in" is that sometimes the users don't interact with the prompts that are thrown by the policy, resulting in error logs like this:

Executing Policy Re-Issue Recovery Key...
[STEP 1 of 2]
Running command sh /Library/Scripts/reissue_key.sh...
Result of command:
Alerting user macadmin about incoming password prompt...
0Prompting macadmin for their Mac password...
Prompting macadmin for their Mac password (attempt 2)...
Prompting macadmin for their Mac password (attempt 3)...
Prompting macadmin for their Mac password (attempt 4)...
Prompting macadmin for their Mac password (attempt 5)...
[ERROR] Password prompt unsuccessful after 5 attempts.
Inventory will be updated when all queued actions in Self Service are complete.

That one took a bit to figure out, since the prompt will reload on its own once a minute or so, and then eventually bomb out.

What do your policy logs show on these failures?

@merps It ran fine when I configured it for Self Service.

So, the log you entered... I get all the errors about password attempts... but no popup is ever shown. I've tested this on about 10 different newly-imaged Macs. If I call the policy manually via the Terminal, everything runs fine. But when set to recurring check-in, no popup is ever displayed even though those log entries are made.