FileVault2 deferred enablement

So is what you're saying that the FileVault enablement dialog never comes up on logout? Because 'deferred enablement' means it prompts the user referenced by "username" on logout to enter their password to start FileVault. It's not clear from your post if you tried logging out of the account or not.

The popup window comes up to "Enable Now". The user can click that and you think it would start encrypting. But when you go to Security and Privacy to see if it is running it is still off. I have attached a screenshot from the log details.

Ah, gotcha. Ok, well then that indicates something is wrong. It should start enabling FV2. The password must be correct since that dialog won't accept a wrong password for the deferred enabled account.
Is there a valid Recovery partition on these Macs? Because that's needed for FileVault. I assume so, but worth just double checking on, especially if these are traditionally imaged Macs, not DEP enrolled or something.

Have you tried manually enabling FV2 on any of the affected machines in the Security & Privacy pane, just to see if it turns on that way? I'm not suggesting that as a solution of course. Just trying to see if this is an OS based issue or something with the FV2 configuration in your Jamf console.

The users login password is correct. Theyre using local accounts, not ad joined. There is a recovery partition on the ones I checked, from what I was told they wernt imaged in anyway just taken out of the box, account created and standard software installed. Yes, I just did test and was able to manually enable FV2 from the Security and Privacy pane.

It might be useful to have a read up on SecureToken.
https://derflounder.wordpress.com/2018/01/20/secure-token-and-filevault-on-apple-file-system/

I have been dealing with an issue that if I wipe and enrol a Mac into Jamf a second time without deleting the computer record from Jamf first then no one gets enabled for SecureToken. For a successfully encrypted drive this means that no users can unlock the drive... only the escrowed key. In another case it means that on logout the FileVault prompt shows but it fails to work. And if I try to enable FileVault from the System Preferences the button clicks but gives no feedback.

My solution so far has been to delete the computer record in Jamf before re-enrolling the same machine again.

I can try that on one of them to delete from the record from Jamf and re-enroll. Some of these it's the first time enrolling them and we are seeing this issue.

Ok, that sucks. I have to deploy a machine next week. Fingers crossed it doesn't fail like this. Will follow your progress.

Could you check in inventory computer-DiskEncryption if you've "FileVault 2 Enabled Users: user_youwant" ?
this message appears When SecureToken is disable

In JSS Disk Encrypt pref, it's about that Jamf notify "Beginning with macOS 10.13, the management account can no longer be used to enable FileVault when the account was created with Jamf Pro due to the lack of a secure token."
It's the same for other user, you need to enable SecureToken.

Disk Encrypt Pref : Curent or Next User (For High Sierra and Mojave)
Config Profile : Filevault redirection Key Automatically to Jamf Pro (or specific Serveur if you want)
Policie : Disk Encryption - At Next Login + Script BEFORE to enable SecureToken for User (need the user password, you can ask him with a popup)

#!/bin/sh
#Variable
CurrentUser=$(stat -f%Su /dev/console)
UIDCurrentUser=$(id -u "$CurrentUser")
#Ask User Password
userPassword=$(/bin/launchctl asuser "$UIDCurrentUser" sudo -iu "$CurrentUser" /usr/bin/osascript -e 'Tell application "System Events" to display dialog "Password of $CurrentUser :" default answer "" with title "Security" with text buttons {"Ok"} default button 1 with hidden answer' -e 'text returned of result')
#Enable SecureToken for the CurrentUser and adminUser
sysadminctl -adminUser an_admin_user -adminPassword admin_password -secureTokenOn $CurrentUser -password $userPassword
#Notification
/Library/Application Support/JAMF/bin/jamfHelper.app/Contents/MacOS/jamfHelper -windowType utility -description "At Next logon The Disk Encryption will be start" -button1 "Ok"
exit

I attached a screenshot of a user who gets the popup to enable FileVault2 when she logs in but the device never actually encrypts. The FileVault 2 Enabled Users in the Inventory is blank.

the SecureToken is disabled, you need to activate it : Use my script in previous post.
SecureToken need a password admin, and the password of user.

Script to show a popup to ask the password of user, and Activate SecureToken

#!/bin/sh
#Variable
CurrentUser=$(stat -f%Su /dev/console)
UIDCurrentUser=$(id -u "$CurrentUser")
#Ask User Password
userPassword=$(/bin/launchctl asuser "$UIDCurrentUser" sudo -iu "$CurrentUser" /usr/bin/osascript -e 'Tell application "System Events" to display dialog "Password of $CurrentUser :" default answer "" with title "Security" with text buttons {"Ok"} default button 1 with hidden answer' -e 'text returned of result')
#Enable SecureToken for the CurrentUser and adminUser
sysadminctl -adminUser an_admin_user -adminPassword admin_password -secureTokenOn $CurrentUser -password $userPassword
#Notification
/Library/Application Support/JAMF/bin/jamfHelper.app/Contents/MacOS/jamfHelper -windowType utility -description "At Next logon The Disk Encryption will be start" -button1 "Ok"
exit

Or if you know user password

#!/bin/sh
#Enable SecureToken for the CurrentUser and adminUser
sysadminctl -adminUser an_admin_user -adminPassword admin_password -secureTokenOn user_you_want -password user_password
#Notification
/Library/Application Support/JAMF/bin/jamfHelper.app/Contents/MacOS/jamfHelper -windowType utility -description "At Next logon The Disk Encryption will be start" -button1 "Ok"
exit

@bmichael If I understand it right the issue you are getting is due to something which is fixed in 10.14.2.

The fact that the end user sees the prompt to enable FileVault but nothing happens when clicking ok, is because of the lack of secure token.

Before 10.14.2 policies to enable FileVault don't actually enable FileVault if that user does not have a secure token, and profiles would give an error when trying to enforce FileVault at logout.

This is all fixed in 10.14.2.

I've been testing all possible scenarios (I think), and here are my notes: Mojave 10.14.2 Secure Tokens

Apart from that the “deferral” message is normal. It’s just saying that FileVault will be enforced after X logins (see JamfPro Settings - Computer Management - Disk Encryption).

You can choose after how many logins it actually gets enforced.

Thanks @mpuyet I will give those scripts a try this morning.

@frederick.abeloos what about users who are still on an older os? We have a good handful or more that are on 10.13.x that get the popup to enable filevault but it never enables even after the 2 logins that we have it set for.

@bmichael not sure, I only did intensive testing on 10.14.1 and 10.14.2.

I could test again but that would then be a 10.13.6

Will test but it’s only 10.14.2 which especially changed this behavior.

It's not all fixed in 10.14.2, I tested it this morning using an admin mobile account. I purposely bypassed the secure token dialog on login to simulate a user/technician not following process (first user is a local admin account we create to run our provisioning policy which binds to AD and so on).

I was still unable to initiate FV encryption using an "at next login" Jamf policy for the mobile account that had no secure token. It correctly identified my user, set up deferred enablement, and when I logged in it said I needed to enable FV to proceed. I click OK, it looks like it's working, no errors...but nothing happened. FV is still disabled, that account has no secure token.

10.14.2 might address older systems that happen to have no secure token accounts, but if you create a new device with 10.14.2, all it does is make sure you can't take any action that strips the initial account of its secure token. Can't delete that account, can't change the password the wrong way, can't disable the secure token. The OS won't allow those actions no matter what.

So if you lose that initial admin password or don't want to/can't enter it to enable FV or grant another user a secure token, it's kind of pointless.

Maybe these will help.

https://travellingtechguy.eu/mojave-10-14-2-and-secure-tokens-it-works/

https://travellingtechguy.eu/script-secure-tokens-mojave/

Full disclosure: I didn't write them, I just found them useful today and thought you might as well.

@alexjdale If you get the popup about secure token when logging in with a mobile account, this means indeed that another account already has one.

This is expected behaviour and is indeed due to the fact that you logged in with a local admin account at very first login.

If you bypass the popup you end up in what Apple intended... a mobile user which can't be enabled for FileVault. This due to the lack of secure token. This is not an issue but expected behaviour.

To avoid this, just don't log in with a local admin before the mobile account end user logs in... hence NO users will have a secure token and your policy or profile to enable FileVault will work. This has been fixed in 10.14.2 as before enabling FileVault for any user without secure token would give you exactly the behaviour you mentioned.

Again, this only works if no other user already has a secure token. Enabling FV for a user without ST, while another user has one does not work and is expected behaviour.

That's why I wrote the script above in order to try avoiding this kind of situations.

My suggested workflow would be:

• DEP with any user creation you want: standard - admin - or skip if you bind
• Create an additional Admin in the prestage if you want, or use the Management account for whatever admin purposes you need it for later
• Bind the Mac at Enrolment complete if you need (but go for NoLoAD if you can)
• Let the end user login
• Run the script to manipulate the secure tokens before enabling FileVault. For instance at the next checkin, or as part of a DEPNotify/SplashBuddy workflow
• Enable FileVault, for instance at the end of DEPNotify or just call a custom policy trigger at the end of my script.

You might have your reasons to log in with a local admin account before the end user logs in, but you could actually just include the bind as an enrolment complete policy?

In case you do log in with a local admin account that account will have a token. Hence your mobile end user will have to comply with the popup to get one as well. But I would say, avoid enabling FileVault until you have your tokens sorted. The script should be able to cover you in all situations.

@bmichael just tested on 10.13.6.

DEP - prestage limiting the end user to Standard Account.

First login: the standard account, hence NO tokens on the system. Checked it.

Enabled FileVault with a policy, logging out, popup to enable FV at login OK, drive starts encrypting as expected.

What version of 10.13 are you having issues with?
Did you check if any other accounts have a secure token on the system?

10.13.6 are a couple that I am having problems with. Some are still on 10.12.x

Just want to chime in here as I ran into this recently with a newly-enrolled Mac running 10.14.6. We decided to migrate the user account from the user's old Mac (user account only - no Applications or system settings). The user account migration happened after enrolling the new machine in JAMF and binding it to AD. We then assigned the Mac to our FV2 encryption policy. We kept running into the "FileVault is off, deferred enablement appears to be enabled for active user: username" message in JAMF when looking at the logs for our FileVault2 policy. Nothing above in this thread seemed to work - until I noticed that the user account was, in fact, a mobile account.

I ran the script in this post: Derflounder - Migrating AD Mobile Accounts to Local User Accounts

Then un-enrolled / re-enrolled the machine in JAMF (just to be safe). The message of deferred enrollment still showed up, but the encryption finally went through and finished with everything valid and present.