Catalina - Reissue FileVault2 Key

[mnickels]

Hello everyone,

Occasionally, we have a Mac enroll with an unknown or invalid FIleVault 2 recovery key (an example is when a Mac is encrypted before MDM enrollment). We currently use a script that prompts the user for their password, and then rotates and re-archives the key.

Script: https://github.com/homebysix/jss-filevault-reissue

I have just learned that in Catalina, Apple has removed the ability to pass the username/password to the fdesetup tool. The script notes this at the bottom of the page: "This script will not work on macOS Catalina due to the inability to pass user authentication information to the fdesetup tool."

Does anyone have a solution to ensure the FileVault2 recovery key is escrowed to the JSS in Catalina?

[ClassicII]

I just tested this about a week or so ago and it worked. You need a TCC profile to allow this. Let me test again in the morning and I will report back.

[Hugonaut]

@ClassicII would love it if you shared your TCC Profile! Haven't fully integrated our Provisioning process with Catalina yet but I've been reading a lot about the changes & fdesetup seems to be a big thing - only allowed with mdm profiles

[mnickels]

I would also be interested in your TCC profile. Thanks!

[mucgyver-old]

Same here! :-)

[nwagner]

+1 right here

[jmariani]

I am also be interested in your TCC profile. Thanks!

[wmehilos]

I would love this profile as well. Working on writing up a proposal to replace our Symantec Endpoint Encryption requirement with just using Jamf to manage and escrow the key, having a means to rotate the key on Catalina is paramount.

[mm2270]

@ClassicII Just adding my name to the list asking if you'd be ok with sharing the details on your PPPC profile for this. Does it use the fdesetup binary?
I will likely need to know how to do this for clients I'm working with. We're all going to need to manage Catalina sooner rather than later, and being able to rotate the FV2 key is important to many.

[bmarks]

One additional idea, you may also want to reconsider your FileVault workflow. In all of our communications with both Apple and Jamf, they're really pressing the idea of managing FileVault with a configuration profile payload. So, rather than a TCC profile to "fix" your FV workflow, you could just go straight to an FV profile which among other things also handles key escrow destination. Via this method, you don't have to override the new limitations of the fdesetup command. FileVault is triggered as soon as the profile reaches the device, and a user cannot disable it either, even with the fdesetup command. The only additional step is the user has to logout to trigger password entry to finish the FV activation process. We have found that this greatly simplifies our provisioning workflow. I know everyone's workflow is different, but it may be worth considering. The main issue I can see with some workflows is timing, especially if your first created used is a local admin for which you may not want FV enabled. But, that's just a matter of scoping.

Also, one other thing worth mentioning... in our experience, "unknown" FileVault keys are not actually unknown. There's another thread on this topic, but often times you can run a MySQL command that will fix the keys marked as unknown. We never determined a root cause while working with Jamf, but there's a scenario where a key can be marked as "to be deleted" inadvertently in the JSS. It isn't actually deleted, it gets listed as "unknown." Your Jamf rep can give you a MySQL command to fix these Macs in bulk if this is a common issue. We found the jss-filevault-reissue script problematic for us because it required the user to enter their password, and that prevented us from reissuing the keys invisibly. We also found the script didn't always fix the issue anyway but unhiding them did.

[alexjdale]

The main issue I've found with config profiles for FV is that they are basically just like running fdesetup with a deferral, which has downsides, like locking in on the user who was logged in at the time. If the profile installs when an admin or other account is logged in and it switches to another user, the system will wait forever for the original user's password and encryption will never begin.

As such, I'd rather just script it and use fdesetup to configure, once I've validated it's the user I want. I very much wish FV could encrypt devices without needing an initial user's password to begin the process (which the T2 does, but not really). Or just "next person who logs in has to enable FV to proceed" instead of limiting it to one specific user account.

[mucgyver-old]

@bmarks , what would you scope how exactly to prevent the first local admin (=setup user) to be the secure token holder, as this should be wiped afterwards anyway?

[bmarks]

@cbednarzwd There's a mistake in my post. I should've said "first user to log in." In our PreStage config, the owner creates their account during Setup Assistant. An additional local admin user is also created invisibly as part of our PreStage settings, but when Setup Assistant is complete, the user ends up in Finder logged in as themselves, which is technically the "first user to log in." According to our Apple rep, this is the workflow they recommend because the first user to log in always gets a secure token, admin or not, mobile or local. This workflow enables us to trigger FileVault immediately because the profile is pushed to the Mac before Setup Assistant even completes, and all the owner has to do is logout/login to finish FV activation. It also does not enable FV automatically for the local admin user (which is what we wanted, but something to note.) As far as scoping the FV profile, I have tested adding it to the PreStage config itself which works fine, no scoping needed (though you have to be careful you don't scope it so it gets removed later.). It also works if you scope the profile so that it's relevant during initial boot. In either scenario, it gets pushed early enough to trigger FV by the time the user gets to the Finder.

[elliotjordan]

Hi folks! I'm the maintainer of the jss-filevault-reissue workflow referenced above, and I've got a quick update that may be of interest.

My team has published a new tool called Escrow Buddy, which regenerates FileVault keys at the loginwindow, thus avoiding the need to prompt users for their password later. It should be suitable as a drop-in replacement for my previous jss-filevault-reissue workflow at most organizations.

You can read more in this announcement on the Netflix Tech Blog, and this post on my site specifically covers migrating from my old workflow to Escrow Buddy. Escrow Buddy's source code and installer are available on GitHub.

Thanks!