Problems escrowing personal recovery keys in Casper 9.6 and 9.6.1

rtrouton
Release Candidate Programs Tester

In talking with @Banks][/url][/url this morning, we discovered that FileVault 2 personal recovery keys (PRK) are not getting escrowed to Casper from Macs running 10.10.1. In my testing, this looks like this may be tied to having the Require FileVault 2 setting of the Disk Encryption section of an encryption policy set to being "at next login".

external image link

This may be caused by an issue with fdesetup in 10.10.x. Yosemite's fdesetup has a new -defer option which forces encryption at login, but this new feature doesn't appear to work in my testing.*

The fix I've identified is to set it to require FileVault 2 at next logout.

external image link

When set to "at next logout", Yosemite's fdesetup will use the same -defer behavior that Mavericks uses. I've tested and verified that using "at next logout" enables encryption and properly escrows a PRK on the JSS.

*For those interested, I've filed a bug report about this with Apple. The bug ID number is 18486881 and I've cross-posted the details to Open Radar:

http://openradar.appspot.com/radar?id=5276526840905728

12 REPLIES 12

mm2270
Legendary Contributor III

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

guidotti
Contributor II

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.

kitzy
Contributor III

Hi @guidotti,

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

emily
Valued Contributor III
Valued Contributor III

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.

RobertHammen
Valued Contributor II

<waiting impatiently for 9.62>

gachowski
Valued Contributor II

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

alexjdale
Valued Contributor III

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?

chriscollins
Valued Contributor

@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?

mm2270
Legendary Contributor III

@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.

dgreening
Valued Contributor II

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.

gachowski
Valued Contributor II

@ 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

alexjdale
Valued Contributor III

@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.