FileVault Deployment Broken in Catalina

Filevault config profiles on Catalina are weird. they cannot run on logout and needs to run on login. My solution was to set up a policy that forces filevault enabling on login.

for more info see https://www.jamf.com/jamf-nation/discussions/33538/title#responseChild194616

Thanks for the message @strayer that is exactly how I have my policy set up. Are you using a Profile as well?

@bassic

Laurence, I have the same set up as you, how do you trigger the policy? I have mine triggered custom and I call it after the 1st login during an enrollment triggered script. I have figured out in testing that if you try and start the encryption even the defer before that 1st login the OS doesn't like it. Also are your machines" User Approved MDM" and "Supervised". In the beta of Catalina everyone saw that message until Apple changed it to allow User Approved MDM not request that pop-up.

C

[Edit]

@bassic

I just re-read your post and my answers might be wrong... or I'm mixed up if your post says both profile requires and it doesn't ..

if the profile is set to "Require FV and Escrow" then it's enabling it on next logout.. and that is reported as broken in a different thread.. and you are send mixed messages to the OS next logout and next login.

C

@gachowski

Thanks I really appreciate your response. I have a profile that sets the escrow, and I did have it it set To require FV as well, but I have unchecked this.
The Encryption policy (just the standard Jamf one) runs after the user's account has been created and logged in to (using NoMAD Login).
The Mac is ABM registered and in a Pre-Stage enrollment.

The thing is I am getting the "fdesetup wantsto enable Filevault" when all profiles are off, and no policies have run yet. I'm starting to suspect the T2 chip, I can't think what else could be triggering it.

@bassic

Is it possible that NoMad is triggering it? I have only used Jamf connect in testing and there is an option there to start it. Also what OS are you using? I don't think it's the T2 chip as I don't see that message any more after one of the beta....

It's also possible that the Jamf Profile is still triggering it, as even though the box is not check it's still included, did you check the profile in system prefs? or like this.. there are automator actions at the end of the post...

https://macmule.com/2015/11/16/making-downloaded-jss-configuration-profiles-readable/

Pretty disappointed at Jamf's guidance with this. I hate that their support either ignores issues or just address them at the end of their response. A specific example with 10.15+ FV2 enablement & enforcement. I asked about this and their response was "Our recommendation for macOS 10.13 and above is to use a Configuration Profile to enable FileVault. Here is the workflow that we have used successfully in the past:". Which I was aware of but my question was specifically about 10.15+ so why not address this directly and right away? Enabling and enforcing FV2 is a requirement for many of us, I'm curious if they are addressing this during jumpstarts at this time our just leaving admins to figure it out themselves like seems to be the case. This at the end of their response:
"With Catalina we discovered a new Product Issue that Apple and us are working at getting resolved. Essentially what happens is after logout or reboot FileVault enablement never triggers. What we need to do is create a separate policy with "Disk Encryption" enabled at "Next Login". We can create a Smart Group based on the Operating System using the "Like" operator and specifying the version to be 10.15. We can then use that for our scope".

I'm getting the same problem. And this is on a the new MacPro tower. I do not have a config file forcing FV to to be enabled, I just enable it with a policy with deferred enablement.

I log out, log back in, FV doesn't ask to be enabled. I log out, reboot, login, FV pop up says its being enabled ... but its actually not being enabled.

My question is:
Is this a JAMF problem, Catalina problem, Apple problem, or a horrible mix of the three?

Yea Apple's Catalina and JAMF right now are a real mess, and I wont update my users till JAMF catches up on these hard pieces. It was the same thing for Mojave from High Sierra. So we might have to wait a bit till JAMF catches up with their code and arrays. It will start to get decent about 6 months out. All you can really do is start being proactive and noticing whats broken, make a list and test it each time JAMF releasees a patch, new version or revision on the subject. It's a lovely game of cat and mouse, but I understand JAMF's out take on the matter as Apple doesn't make it easy for them. But it will all work itself out, just in time for the Next BIG macOS drop and we start all over.

Biggest one for me as well is, FV2 and the way it handles the token currently and until JAMF catches up with It's new way of implementing the bootstrap method we are left with manually doing this process.

If you have a secure token, the fdesetup deferred method works fine at "next login." If the user does not have a secure token, it will say it's enabling FV, but fail out. I use control scripts to validate, and only enable FV if the target user has a valid secure token.

There's a lot of remediation that has to take place when the system isn't handled properly. If a mobile user doesn't get their token at first login, it's a huge PITA, but this will soon be remedied with bootstrap tokens via DEP (which will make sure all mobile users have secure tokens). There's also the problem of users changing their directory passwords off-system, which will invalidate their secure token.

This is squarely on Apple for implementing a terrible system in High Sierra and taking years to address basic problems, and still not having good results. There really needed to be some MDM-driven way to just say "every user gets a secure token no matter what" so we could at least retain functionality if we didn't really care about their half-baked security posture.

@alexjdale I agree, man but since when has Apple cared about the Enterprise.

We use a helper script where it does all of our first user login configurations. During the process we collect their AD password and store it into their keychain. we then use our local account creds to pass the secure token to the new user. Once the secure token is passed and we have verified it was successful, we delete the local account. We grab the current logged in username and password from their keychain then do any conversions to make sure it is readable and pass it to a temporary plist. We then take that plist and run the fdesetup command

fdesetup enable -keychain -defer /tmp/com.whatever.Filevault.plist -forceatlogin 0 -dontaskatlogout

After that command is ran, the temp plist is destroyed. Following that command we display a dialogue to the user telling them we need to log them out and then they can begin to use their device. After a short delay we run this command to boot them out. make sure you have code to define the username logged in.

launchctl bootout user/$(id -u $username)

They will then log back in and be prompted to enable FileVault. If they select no, it will bring them back to the login screen until they choose the enable option :)

A lot of what we did came from here: https://derflounder.wordpress.com/2019/10/17/managing-macos-catalinas-filevault-2-with-fdesetup/

Only way we really got it to work. Definitely hard to get support on this.

When i enable FileVault using following command getting an error "A problem occurred while trying to enable FileVault. (-69594)".
sudo fdesetup enable -user $username -password -$userpassword.

Anyone come cross this error ? Please suggest