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