Catalina - FileVault Enablement

[mnickels]

I'm currently testing out Catalina on a VM. I have the Security & Privacy MDM profile deployed to it with the setting enabled to require FileVault.

When I reboot the VM, I am prompted for my password. It says that it will enable FileVault, but it never does - the Mac just reboots and then I go through the same process all over again.

If I enable FileVault through the local Mac settings it works fine.

Is anyone else having this issue? Any idea why the MDM setting is not enabling FileVault?

[GregE]

Looks like Bootstrap tokens are working with DEP Catalina Jamf 10.18 which is good news, however the current dealbreaker is that the user must log out and not restart when FV is enforced via a Config Profile, otherwise encryption goes in to deferred mode and won't actually encrypt until the user next logs off (which they never will in a 1-1 Mac scenario). Plus everytime they restart they get prompted for their password to enable FV (which never does as it's deferred).

From what I gather if we enable via Policy (so that it enables at login) but try to enforce with a config profile (which only has the option for log out) you run the risk of an 'enable at log in but also at log out' conflict.

[Heavy_D]

@GregE Are you forcing any restarts on the machine?

In our environment we have two scripts that require a reboot. We have FV enabled in the login as intended. When the machine restarts and the user logs in it's good to go. However, we are all on Mojave 10.14.6 at the moment, So I am not sure, if it's working properly on Catalina last time I relived this Bootstrap was still not working with DEP and there was a slew of other issues that I did not want to deal with at the time.

Next time I relive this I will post on my findings.

[GregE]

We're still in testing so haven't pushed this out to the fleet at all. Have been waiting for Bootstrap support from Jamf so are making a concerted effort to get this to work now (with zero-touch) since it's now supported (and Windows has been BitLockered for over a year). All my testing is in Catalina since that will be the way forward and everyone will be upgraded as part of this project.

One thing I'm finding though is that the Bootstrap token for the mobile account isn't being created upon login. My mobile account is a standard user, so I switch user in Terminal to the local admin account to run sudo commands (like sudo fdesetup list) and the local admin account (created in PreStage Enrolment in Jamf) will have a secureToken (even though it has never gone through the setup assistant) and thus my mobile account won't get the Bootstrap. Not sure if switching user in Terminal is what's causing this.

[quip_MDavison]

Just throwing out my findings on this, as our environment is experiencing this as we update to Catalina as well. If you Shutdown or Restart the issue persists, but if the user goes Apple Menu > Sign Out it does enable Filevault after being prompted and the key does get escrowed to JAMF successfully. Not ideal, but it's been a serviceable workaround for us as we build out a new way to script it that works for our environment.

[dsardaczuk]

Even in the new 10.19. it's not fixed. Known issue PI-007582 https://www.jamf.com/jamf-nation/my/products/known-issues.

[Tapia]

@quip_MDavison I am experiencing the same in my testing. If the Mac is Shut Down or Restarted FileVault will not encrypt. It has to be an actual Log Out. Obviously this is only for new enrollments and all upgrades are still encrypted as expected.

[BOBW]

If you are using jamf connect login take a look at this:
https://travellingtechguy.eu/jamf-connect-and-laps/
We have managed to get it all working without prompt and without reboot / logout
Just make sure you have a generic local admin account as the defined admin user in your prestage, our local admin account we use is then pushed down using a policy after enrolment.
The generic account will then be the first admin account who is able to enable FV for all users and the PW is changed after escrowing to JAMF to the unlock key.

NOTE: While we have not moved this into production in testing it all worked fine without failures

[LeidenUniv]

this is a clickable link for the post from BOBW above...

[bmee]

have anyone found a work around or solution? When we sign out from the Apple menu, it still doesn't issue us the recovery key, when logged back in, in security and privacy, it stated that FileVault is turn off.

[Scotty]

I didn't read all of this, but I'm a little confused about what the issues are. Its pretty simple. You need a Profile to enable key escrow and a Policy to enable encryption. Since we have technicians set up all our Macs, they go to a "Tech Tools" section in Self Service (via logon/LDAP) and run it from there. Its setup to prompt for the password at next logoff (or reboot).I confirmed this is working just in 10.15.1, 10.15.2 and 10.15.3.

[bmee]

hey @ScottSimmons thanks for the info and it works. Just a questions, it doesn't display the recovery key like all the Mojave devices, is that a normal behavior for all Catalina device(s)? Also do you guys have the policy scope it to all devices during the setup process or do you put add machines manually into the policy?

[kevin_v]

@ScottSimmons Technically don't need a policy. If you have the Config Profile configured the way you do, but check "Require FV2" - it enables at the next log out without a policy.

[GregE]

Looks like it's working for us now with Catalina 15.3, mobile accounts and bootstrap token.

Policy: Enable FV at login.
Config Profile: Escrow key (and enforce FV but only if it's enabled already otherwise you get a logout/login conflict)

I've found that it Escrow's the key anyway if deployed via Policy but you want the profile applied for any future key changes (if they become unknown or invalid in Jamf).

I've found that if you log in with the AD account (standard user) then do something like sudo fdesetup list or status in Terminal, which involves switching user in terminal to the local admin account su localadminaccount the local admin account then gets a secureToken and the mobile account can't enable FV without the local admin account granting it a secureToken first.
If you never do su localadmin in Terminal, the local account never gets a secureToken, and the Bootstrap is granted to the mobile account when the mobile account is prompted to encrypt at login (as no other token holders exist).

Also found that deploying FV at logout via the Config Profile displays the Individual Recovery Key to the end user (not ideal) and as mentioned above encryption is deferred until they do a logout. Shutdown/Restart won't enable it. This doesn't happen when deploying via Policy and users can shutdown/restart and they'll prompted to encrypt the next time they log in.

1.5yrs of testing and we're finally ready for deployment!

[Scotty]

@kevin.v we don't encrypt. all machines, we have a lot of iMacs we don't want to encrypt. (Although, these days performance is not really an issue so it wouldn't really hurt I guess)

@bmee no it doesn't display the recovery key, but it doesn't need to. We actually don't want our users having it. They call Help Desk for that. The scope is just in Self Service for our Techs when they log in. Its manually enabled when they set up the machines. I'm starting to test making it just happen automatically now.

[bmee]

@ScottSimmons We have all of our tech setup all Macs before deploying as well. You know if we can add these during enrollment?

[kevin_v]

Am I reading correctly that in order for FV to enable at next login via policy, the account created in PreStage enrollment must have the following:
-Create Account before Setup Assistant
-Hide account
-Local User Account type: Administrator

Once this is done, a policy can be generated to enable FV at next login, correct?

Ideal solution is FV enables at next login and bootstrap token is enabled.

[GregE]

@kevin.v Our PreStage enrollment account isn't hidden and it still works. The real difference is whether you log in (or switch user in Terminal) to that local admin account.
If you log in with it (first login), it will get a secureToken, and in that case you'll need a policy that will use its admin credentials to grant a token to the next (mobile account) user. If your local admin account created in PreStage Enrollment never logs in (which is our case as we're trying to actually make zero-touch deployments a reality) then the mobile account receives the secureToken when they are prompted to enable it at their next login (as no other token holders exist).

[kevin_v]

@GregE " you'll need a policy that will use its admin credentials to grant a token to the next (mobile account) user"

So this is where the Bootstrap Token comes into play ya? This is what I'm trying to sort out. Make a policy for the manual commands specified here?

https://www.jamf.com/jamf-nation/articles/764/manually-leveraging-apple-s-bootstrap-token-functionality

[GregE]

Kind of, the idea of the Bootstrap token is that your mobile account will get a secureToken (Bootstrap) without any other admin accounts having one. The testing I've done involves wiping my Mac each time so I can't comment on devices enrolled prior to 10.18 as mine is enrolled with whichever version of Cloud we're on at the time (10.18 & 10.19 in testing). This means the Bootstrap is granted with no additional input or scripting, it's automatic and is granted when you enable FV.

How would we even know which version of Jamf Cloud was hosted when the Mac was enrolled??

[kerouak]

@ kevin.v

If you setup the prestage as per my image, bootstrap toen will function for any mobile account . The admin A/C doesn't need to be hidden.

[kevin_v]

@kerouak What flavor of JSS? We're on 10.19, your PSE window looks slightly different:

[Heavy_D]

So with the assistance of other Admins through the slack admin channels I have noticed that this whole processes is manually done unless someone comes up with a clever way of scripting and automating the whole processes for mobile AD bound users.

Here is our workflow and how we have it configured via JAMF:

MOJAVE: This was working like a dream in Mojave, prior to Bootstrap It finish enrollment, I would log in with the Mobile AD user, JAMF would run its scripts and then promote the mobile user to a Admin on the next login. The mobile/admin user logs in the get prompted to turn on FV2 and all is right with the world.

NOW IN CATALINA: This was working like a dream in Mojave, prior to Bootstrap It finish enrollment, I would log in with the Mobile AD user, JAMF would run its scripts and then promote the mobile user to a Admin on the next login. The mobile/admin user logs in the get prompted to turn on FV2 but it's never turned on because the user at this time does NOT have a bootstrap according to this diagram Catalina Bootstrap Flowchart At this point I am now logged in with the mobile/admin AD bound user. I then manually did the following:

If the client is enrolled in MDM and associated to the MDM in ABM or ASM but Bootstrap Token hasn’t been escrowed yet, running
profiles status -type bootstraptoken

will result in:

profiles: Bootstrap Token supported on server: YES profiles: Bootstrap Token escrowed to server: NO

The first line being the most important. A YES means that the client is eligible for Bootstrap Token escrow since it is assigned to the MDM in ABM. If the result is NO then the client isn’t eligible at all and you need to look into what MDM the client is enrolled in and if the client and MDM are associated in ABM.

With a SecureToken enabled admin issue
profiles install -type bootstraptoken.

This process is interactive and requires the username and password to be typed in.

Enter the admin user name:localadmin Enter the password for user 'localadmin': profiles: Create Bootstrap Token created profiles: Bootstrap Token created profiles: Bootstrap Token escrowing to server... profiles: Bootstrap Token escrowed

If all goes well, Bootstrap Token is escrowed. To verify, on the client run
sudo profiles status -type bootstraptoken

profiles: Bootstrap Token supported on server: YES profiles: Bootstrap Token escrowed to server: YES

Note: This information was provided by another Admin in the SimpleMDM community who I spoke with he referred me to his post located here: ABOUT MACOS CATALINA BOOTSTRAP TOKEN

At this point, if the client is bound to a directory server, when a mobile account logs in a SecureToken will be enabled on the account at the next login, so I restarted the machine. After logging in with the mobile/admin account now it has a secure token. Still prompting me to enable FV2 at login but still not Enabling it in the process so it appears that it would take a couple restarts for the mobile/admin AD bound account to actually enable the FV2 at the login.

Please keep in mind I also just tested it manually turning on FV2 and it works but the Keys NEVER get escrowed to JAMF. Causing me to manually disabling it restarting getting prompted to enable at login and it finally turned ON FV2 with an Escrowed Key in JAMF.

*Note: You might also have to rely on fdesetp commands to enable FV2 and adding the mobile/admin AD user to the current FileVault Status. *

UPDATE: 03/09/2020 I did another manual deployment and even though it's still all very much manual process. I was able to enable FV2 after two restarts. So before my machine restarts for the first time as part of scripts after enrollment, and prior to making the mobile AD user an administrator on the machine I pop open a terminal and I su AdminAccount and run those sudo profile commands. I Left the policies finish and restart the machine. When I checked FV it was still not enabled after being prompted. So I restarted the machine and checked again after being prompted again to Enable, this time checking FV2 it was enabled and the Key was escrowed to JAMF.

[GregE]

Ours is working well (automated) without any IT interaction being required. I'm not certain why we need to escrow the bootstrap token? All our OS upgraded users are either issued a secureToken by the admin account (via policy/script), and any new PreStage Enrollment Macs are issues the bootstrap token upon login when FileVaul is enabled (via policy). Our bootstrapped token mobile accounts still pass the recovery key to the JSS when FV is enabled.

The only drama I'm currently hitting is the popup sometimes not appearing for the user to enter their credentials so that the existing (secureToken enabled) admin account can issue them one.

Script result: Prompting mobileusername for their login password.
2020-04-29 09:57:39.318 osascript[23786:301442] -[__NSCFConstantString objectAtIndex:]: unrecognized selector sent to instance 0x7fff8e1fbce0
2020-04-29 09:57:39.328 osascript[23786:301442] *** Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: '-[__NSCFConstantString objectAtIndex:]: unrecognized selector sent to instance 0x7fff8e1fbce0'
*** First throw call stack:

That's when running:

#!/bin/sh

currentUser=`ls -l /dev/console | awk '{ print $3 }'`

if [[ -n "$currentUser" && "$currentUser" != "root" ]]; then
orgName="orgname"
brandIcon="/System/Library/CoreServices/CoreTypes.bundle/Contents/Resources/FileVaultIcon.icns"

echo "Prompting ${currentUser} for their login password."
userPass=$(/usr/bin/osascript -e "
on run
display dialog "To enable FileVault" & return & "Enter login password for '$currentUser'" default answer "" with title "$orgName Disk Encryption" buttons {"Cancel", "Ok"} default button 2 with icon POSIX file "$brandIcon" with text and hidden answer giving up after 120
set userPass to text returned of the result
return userPass
end run")
    if [ "$?" == "1" ]
        then
    echo "Timeout - User Not Available"
    exit 1
    else

echo "Issuing SecureToken"
sysadminctl -adminUser ouruser -adminPassword ourpassword -secureTokenOn "$currentUser" -password "$userPass"

echo "Checking that secureToken has been granted"
token_status=$(/usr/sbin/sysadminctl -secureTokenStatus "$currentUser" 2>&1 | /usr/bin/grep -ic enabled)
        if [[ "$token_status" -eq 0 ]]; then
        result=DISABLED
        else
        result=ENABLED
        fi
    fi
fi
echo "<result>$result</result>"
exit 0

[JamelB]

@jordy.witteman how do we push your payload in jamfcloud please ? i'm not sure what is the process to configure it... Thank you. i'm using jamfcloud.

[JamelB]

@jordy.witteman how do we push your payload in jamfcloud please ? i'm not sure what is the process to configure it... Thank you. i'm using jamfcloud.

[JamelB]

@jordy.witteman how do we push your payload in jamfcloud please ? i'm not sure what is the process to configure it... Thank you. i'm using jamfcloud.

[JamelB]

@jordy.witteman how do we push your payload in jamfcloud please ? i'm not sure what is the process to configure it... Thank you. i'm using jamfcloud.

[JamelB]

@JarvisUno i'm interesting by your script to "Promote managed users ot admin" :)

[quip_MDavison]

Just throwing it out there because I saw this in my feed. This is still an issue with Catalina 10.15.5. And what's worse, if an admin sets the user password to expire (so they have to change it on next login) or someone manually changes the user password while you're in filevault enablement limbo, the filevault key is corrupted and that laptop is pretty much a brick. Doesn't take the new password, doesn't take the old password, trying to change the user's password via JAMF gives nondescript errors, even manually logging in as the local service admin account and trying to manually change the user's password fails.

The only solution is to reimage the laptop, it sucks. If we're setting up a new laptop and forget to manually log out and log back in before setting the user back to requiring a password change on next login, we just wasted 2+ hours of config. Fingers crossed this gets fixed in 10.16.x but I'm not holding my breath.

[AdamCraig]

@quip_MDavison Generally setting users to change password at next login hasn't worked will for me in the Mac environment. But in that instance you could log in as admin and switch users to their account and change the password there and then update the FV password via command line or a script

This is the script I use to update Filevault password in a self service policy. https://github.com/theadamcraig/jamf-scripts/blob/master/remove_and_readd_user%20to%20filevault

[Heavy_D]

So has anyone successfully been able to Configure this using JAMF I have not revisited this since we have not been a real hurry to get it get to a Zero Touch state and I been doing it Manually for the that last couple of Catalina Machines added to our fleet. But with BIG Sur around the corner would really like to see what others are doing that would assist in Enabling FV correctly via a JAMF Config and Policy.

My setup has not changed from the above interpretation: Heavy_D FV Enablement