Problems escrowing personal recovery keys in Casper 9.6 and 9.6.1

Thanks for the heads up! Something to look out for as we do more Yosemite testing here.

Not to thread jack, but @rtrouton, have you seen where the JSS reports "No Partitions Encrypted" under the FV2 field although they actually are encrypted? These are partitions encrypted previously, personally without Casper.
If I drill down into the computer details, it shows that the primary partition is encrypted.

Hi @guidotti,

This is a known defect (D-007885) and a fix should be implemented in 9.62.

I just ran our FV2 policy (institutional and PRK) on a newly imaged 10.10.1 machine and the PRK was escrowed correctly in our JSS. I'd be interested to see what differs in the environments to see what might keeping Casper from grabbing those PRKs.

<waiting impatiently for 9.62>

Emily,

In our environment we are seeing about 10% of the key not showing in the GUI. I reached out to Casper support and they have a "magic" way to see if the key is in the database but no showing on the web. : )

C

Will Casper only escrow recovery keys when Casper enables FV? Is there any way to script the enable (since I may want more control or use options besides what Casper offers) and then have the key picked up on the next recon?

@gachowski

I have been waiting to hear back from our TAM at JAMF but since you have some insight on this, we have machines affected by the defect where they were encrypted while on 10.9 and the recovery key was in the GUI and then after they upgraded to 10.10 on their first recon after it disappeared from the GUI. The key is still there right?

@alexjdale, I think technically, yes, it can be done outside of Casper, because at the end of the day, what Casper is using is built in functionality in fdesetup for enablement. Thing is, the individual encryption key would need to be written into an xml file or files in the correct format and placed onto disk for a recon to pick up into the computer record. That's the basic process of what it does today, and, I believe is the process used when you set up a policy to re-issue a new PRK. The jamf binary sees these xml files and recognizes them as encryption keys and scoops them up into the db at the next recon.
I've never actually done the above though, so I can't speak to it directly. Maybe others who have gone down that road can address it more.
We just use the built in functionality, but that's my understanding of the process. There may actually be a better way to do that though.

We have seen this and are re-issuing PRKs via policy to all of our 10.10 tester machines which have been upgraded from 10.9.5 via policy until this gets resolved.

@ Chris C,

I not 100% sure, I only really can test clean X.10 imaged after our 9.6.1 upgrade. The only two old machines I looked at didn't have keys. However with X.9 I can't prove that the key was ever there as it requires user/engineer interaction.

With X.10 there is no user/engineer interaction required so every new imaged X.10 should have a key, unless the JSS went off line at the same time the key is being reported back.

C

@mm2270 yeah, I already have to write a control script to automate/manage the enable process (I exclude some accounts and do some other stuff), so the vast list of options in fdesetup these days is appealing. I figure since Casper is leveraging fdesetup and managing the recovery key output, it should be scriptable, but I also like Casper managing the whole process from a security/audit standpoint.

That said, I just did some testing with the "at login" option and I think I am going to be happy with the options Casper is offering. Escrow worked for me on 10.10.1 on 9.61 JSS.