FileVault 2 assistance

I've seen this issue as well. My JSS "forgot" the keys for several encrypted Macs under Casper management. I've escalated this to JAMF support, but no cause has been discovered.

I can't answer to how casper collects those keys, but I can give you the way we solve it.

We had the same issue, there was a bug at one time iirc that FileVault keys weren't getting stored in the casper server.

We ended up creating a smart group that contained Individual Recovery Key Validation:Unknown or IS not: eligible. Which then sent a config profile to that machine, redirecting the file vault key to our casper server.
Finally, we used a script (modified to use cocoa dialogue as it worked better for us) and sending an email to the parties with had problems.

We used this script: Re-issuekey (https://github.com/JAMFSupport/FileVault2_Scripts/blob/master/reissueKey.sh )

• RD

@roiegat - if you're asking how the Recovery key gets captured initially into Casper, when you've set it up as Next User deferment and the user enters their password at logout or reboot, the key gets generated and then written into an xml file stored on disk in a special location that the jamf binary sees on next recon and pulls into the db and attaches to that computer record. This is done using fdesetup's built in commands. There's an option to send the generated Recovery key into a local xml file. Casper Suite is utilizing this function.
At least, the above is how it was working when it was introduced. I believe the actual location of the xml file changed over some of the versions, but the process should still be the same.

As for missing Recovery keys, we have seen this on occasion. Keep in mind that Casper Suite will correctly report when a disk is encrypted, but its always possible that a user has initiated encryption on their own from Security & Privacy. In those cases, your JSS will know its encrypted, but not know the Recovery key since it wasn't initiated by your encryption configuration.
In other cases, we have also seen keys go missing, although that seems a bit rare for us.

Going forward, I would say definitely try to convince folks to use both an Institutional and Individual key setup. Think of that Institutional key as "insurance" or a master key. That's actually what it is, so that's important to keep in mind. Keep that institutional key under close guard. Although it can't be used just as-is (you have to create an unlocking keychain from it and know the password the original key was created with to do that), it will unlock any Mac in your environment that was encrypted with it.

Your scenario is the exact reason to be using the "hybrid" institutional/individual key approach. Use it only when needed, but the escrowed limited-access individual key should always give you a back door into the encrypted system.

I've been seeing this in my environment, as well. Came across this recently, which appears to provide a solution:

http://www.slideshare.net/macbrained/mac-brained-filevault-reissue-slides

Haven't tested it yet, however.

Thanks for all the info guys...a lot to look into!

So looking more into this with the great info you guys gave me, here's what I've been chasing so far.

@mm2270 mentioned that they were using the fdesetup command to enable to file vault and saving the recovery key to a plist file. Looking at the fdesetup command there seems to a option to do this:
fdesetup enable -user sally -outputplist > /secureplace/mykeyinfo.plist

So I figured why not use composer to capture all new and modified files when a computer gets the FV policy. While several plists where modified, non contained the recovery key. I was also trying to see if I could use the fdesetup command to just output the current key to a plist, but it didn't seem to like that. It kept generating zero byte plists. So if anyone know the right sequence to do that it would be greatly appreciated.

So then I was looking at @evan.moon link with the deck about pintrest and their solution. Looking at the script that they use provided by jamf it seems like the issue the following command to create the recovery key:
spawn fdesetup changerecovery -personal

So looking at their command they aren't saving it plist file in that command. So it seems like there is something else that I'm missing. It seems like it's like Casper is able to get the recovery key from somewhere local.

So my two possible solutions are use the script jamf provided or try adding the management user to the file vault users. I'm going to get some test machine to test what would work best. While I like the script method, it does require user interaction (for their password). So we would have to notify the users ahead of time and make sure they are aware they are going to be asked for their password.

Adding the management account to the file vault might work best if I could get it script ok. So I"ll need to test it and see what happens.

Thanks again for all the information.

@roiegat What you are missing is that what they are using is a config profile pushed down by Casper to the client that has a filevault redirection policy that redirects the key directly to the JSS instead of a local file.

Basically you have two options of getting the recovery key from a machine. When you use the regular built in Casper FV2 policies on the system, it will write the key out to an xml file that is hidden in /Library/Application Support/JAMF/. The file has a . before it so you can't see it by default. On the next recon the JAMF binary sees the file is there and uploads it into the database.

When you use a configuration profile with a FV2 key redirect, it tells the computer whenever it runs a command to generate a new recovery key or to encrypt the machine, to redirect that recovery key to a URL on the JSS and the JSS inserts the recovery key into the computer record.

@chriscollins Great Info! So looking at the folder you mentioned I found three hidden files. One is a blacklist file that has information on apps that we don't allow. The other is a user delay file which seems to have HTTP header. Then there is a file that has a odd name but has zero bytes, so nothing there. I"ll look into the rest of the folders later. But would be great to see that file.

So I'm going down he configuration profile route like you suggested. The problem is that Configuration Profiles haven't worked so well in our environment in the past. The main reason is that we don't have a working APN method. Our security blanket on our machines makes it hard for servers to communicate to the outside. We are working on getting a outside server to assist with this, but currently bogged down in red tape.

I'll see if I can push it to a couple users to test out. I'll post the results.

That file only exists if you use the built in Casper filevault policy with no configuration profile. The file will get written but as soon as a recon detects the file and submits the key to the JSS it will delete the file. So the only time you are going to see it is immediately after you initiate an encryption via a Casper policy.

@roiegat the hidden xml file gets removed from the Mac once a recon is performed (for obvious security reasons), so in your case it may have already been scooped up and deleted.
Try it again on another Mac not encrypted and look in that directory right after it reboots and you log in. It should be there, unless as @chriscollins mentioned, you are using the recovery key redirect configuration.
You can also keep the Mac completely disconnected from the network after reboot to prevent it from being picked up.