Deploying and enforcing Filevault IRK in High Sierra

[lmeinecke]

I'm trying to come up with a solution that will require our High Sierra machines upon enrollment to get encrypted with a individual recovery key (IRK). I also need JSS to capture this key in the management tab of the computer object so we can use it in recovery scenarios.

JamF support stated that on High Sierra we should no longer use policies and use configuration profiles to enable Filevault (FV). I used that method and while it does ask the user to enable FV at logout it has the cancel option. If the user hits cancel at each logout they can avoid encryption indefinitely. Additionally, if they enter their password and encrypt the IRK is displayed. Unless I can suppress that window I'm worried they will scribble that down on a sticky note in their offices.

sudo fdesetup enable -defer /tmp/filevault.plist -forceatlogin 0

I ended up playing around with fdesetup and found a method to enable it via command line. Similar to the configuration profile (CP) method if you use the defer switch it prompts the user at login to encrypt. The difference being if you hit cancel you're logged back out. It enforces it with the 0 value.

The problem is the key is written in my example to /tmp and during a jamf recon it's not getting into JSS. JamF support doesn't think recon has anything to do with it. They're suggesting that unless I use a CP the IRK won't get into JSS.

Anyone have any suggestions?

Thanks in advance.

[timlarsen]

Hi @lmeinecke , this is a tough one and very confusing. We just finished up with a multi-day engagement with Apple Pro Services and this was a key thing we spent time discussing for our environment. Based on our engagement and testing I've done, here is what I believe to be true (key word 'believe') - please correct me community if I'm wrong...

-As long as you enroll Macs via DEP, using a CP to enable FV still works in a "deferred" manner on the user you setup during enrollment, which is why FV is not enabled until next logout. That being said, I have seen this not work on 1-2 computers running 10.13.3 for no apparent reason which I assume is either a Jamf or Apple bug...the fix is to reset MDM. No issues on 10.13.4 so far.

-As long as you are only encrypting High Sierra machines (not Sierra or below), you can avoid presenting the end user with the IRK at logout by not having a FileVault Recovery Key Redirection payload (and only have the Security > Filevault payload setup). I haven't tested this yet, but plan to, since I too do not like the IRK presented to the end user.

-The policy method and disk encryption configuration settings are indeed no longer the recommended way to enable FV using 10.13+, which is frustrating because the user experience, in my mind, was pretty solid.

-for High Sierra machines, it is probably true that the key will not get escrowed back to Jamf Pro unless you use a CP. You CAN, however, run a script to generate a new IRK using (you have to follow this with a full Recon or two for Jamf to see the change):

fdesetup changerecovery -personal

And as an added bonus, create a smart group looking for computers that have an unknown or not set disk encryption status and run this script on them...I don't think it can hurt if for some reason FV is not enabled. Again, I haven't tested this.

I was told the FV key redirection was being changed by Jamf at some point? But I haven't yet seen a change in managed config payloads in the last few versions. But I could be mistaken.

I know this was kind of a ramble, but hopefully some of this helps! Keep us posted with your findings.

[gachowski]

I think you two options.

1. Use the policy, that is what we are testing and it is working, set it to enable on log in

2. I think you can use a custom profile to set to enable on log in....I haven't test their but I have read here that it works.

The key I think is that the only way I have found to enforce is using enable on log in, if the users cancel out of it it just reboot back to the same window so they can cancel over and over, but won't be able to use the computer.

C

[mike_paul]

Enabling FileVault with PRK (Personal Recovery Key) and IRK (Institutional Recovery Key) via policy does work and does escrow the keys back to the Jamf Pro server but it is generally recommend to use the Re-direct profile in conjunction with the policy as an extra safety net.

For key escrow on Pre 10.13 you used the "FileVault Recovery Key Redirection" payload and 10.13+ you use the Security & Privacy payload with "Enable Escrow Personal Recovery Key" selected. Security & Privacy has some quirks that have been mentioned multiple times before in other discussions.

There are caveats with some changes in High Sierra though around secure tokens but it should work just fine to encrypt as Current or Next User using an individual key via policy set at next login (or whatever value you want to specify there).

Where things start failing is if you attempt to add another user to fileVault (including the management account) or re-issue keys using the built in policy methods as those functionalities now require the requesting user to have a secure token (chicken or the egg thing) or prompt end users who have one to enter their passwords. There are scripted methods that do accomplish this just fine though.

Also as of 10.13.2 institutional keys stopped being able to decrypt drives and are limited to unlocking only. (Same in 10.13, 10.13.1 allowed decryption, 10.13.2 removed it again).

[maurits]

Two notes: 1-I second the options @mike.paul mentions: use two profiles; one for 10.13+ and one for the older.
see https://www.jamf.com/jamf-nation/discussions/25558/macos-10-13-high-sierra-and-filevault-recovery-key-escrow-in-jss-9-101-0
2-IRK is the abbreviation for Institutional recovery Key (one certificate to unlock all macbooks) which is buggy in 10.13.x

You write Individual Recovery Key (*which most of us call PRK, Personal Recovery Key) so please read carefully your own post, and other posts.