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