Installing FileVault from policy on High Sierra.

[dpodgors]

We have a bunch of old non DEP Mac's that when we install HS 10.13.1, we are unable to kick off FileVault through any policy. It tell us it's going to do it but never does. The policy completes successfully and in the history we get: FileVault is Off.
Deferred enablement appears to be active for user 'someuser'.
<<<<Begin Policy>>>>
Disk Encryption
Action
Action to take on computers
<Apply Disk Encryption Configuration>

Disk Encryption Configuration
Disk encryption configuration to use to enable FileVault 2
<FileVault>

Require FileVault 2
Require users to enable FileVault 2 based on one of the following events
<At next login>

Thanks

[a_stonham]

could you post a screen shot of your policy and filevault config?

Also what happens when you login as "someuser" (the user it is deferred for)

[dpodgors]

Every time you login as "someuser", it tells you it's going to start the FV. You get the dialog "Your administrator requires that you enable FileVault". So you click on "Enable FileVault" and you get the second dialog saying FV is turned on, but it doesn't. It's just a vicious cycle.
If you go to system prefs under FV it still says it's set to off.

[dpodgors]

[MikeF]

I have been fighting with this for a while now. What I have found is when I use the config profile to set this up all users need to be admin accounts.

But I have come to the point where I find it is better to install 10.13.1. Set up accounts. We don't bind to ad anymore.
Encrypt the mac. Seems to need all admin accounts for this to work right.
Then after it completes the encryption Enroll to Casper
We have a script to recover the filevault key.

After we get all this done we then run a policy to install all that we need. This is the only way I have been able to have a successful result each time

Then after we get all set up I have found that every account has been enabled for filevault. The option is not available in system preferences . As we do not want the administrator to have filevaiult access we have to remove using a terminal command. After doing this the system preference option to enable/disable shows up.

High Sierra seems to be a real pain with APFS. Lots of issues with accounts getting locked during setup.

Seems almost easier to install Sierra get all working and then just upgrade. Upgrades seem to work with no issue at all. I have opened a case with Apple on accounts getting enabled and I was told that it had to be escalated. That was a month ago. I am not expecting to hear back about it.

[dpodgors]

Thanks for the update - I opened tickets with JAMF and Apple today. The "someuser" account is admin and the only other account on the box is our hidden admin account we use. When I run sudo fdesetup status, it reports it's waiting for "someuser" to log back in but it's a cycle.

FileVault is Off.
FileVault master keychain appears to be installed.
Deferred enablement appears to be active for user 'someuser'

The crazy thing is, if it's a DEP we have no problem. It must be a timing thing with the account.

[nellis]

Hi dpodgors -

Did you get any fixes or an update on this? I think I'm running into a similar issue with High Sierra systems that were originally enrolled as High Sierra systems. In other words, not enrolled with Jamf prior to upgrade from < 10.13.0. This issue does not seem to affect systems that were already enrolled with Jamf while running Sierra or earlier, and then upgraded to High Sierra.

We recently upgraded from Jamf Pro 9.98 to 10.0 (cloud hosted), and I was hoping this issue was simply due to an inability for 9.98 to escrow the FV recovery key for 10.13. However, I still have a couple of systems that are exhibiting the exact behavior in 10.0, which I believe is supposed to be able to escrow FV keys for 10.13.

I had hoped that disabling deferred enablement would resolve the issue, but no luck. Ran fdesetup disable, rebooted and checked status via fdesetup status. Confirmed deferred enablement was no longer active. Ran our policy to enable FV, logged out, then logged back in. Got the message to enable FV, but then it simply takes you to the desktop. No FileVault, and deferred enablement is back again. No bueno.

[dpodgors]

Yes, after working with Apple and JAMF support. The issue has to do with the secure token which was introduced with 10.13. It seems that after JAMF enrollment, the secure token doesn't get enabled to any accounts that are created. To test this run this command:
sudo sysadminctl interactive -secureTokenStatus YOURUSER Where YOURUSER is any user created on that MAC.

In our case the original user created at setup, had the token enabled. The hidden admin created by enrollment did not. The mobile user (which is all we use) that logs in after enrollment, also did not have the token enabled.

The sysadminctl command is pretty kludgy and requires passwords entered on the command line in clear text. It will however allow you to enable the token so the use can get FV and delete other users. Apple is looking to pretty this utility up but nothing yet.

JAMF support says this is a known bug and added my case to the interested parties. I didn't get the defect number, but with JAMF once it's a know bug, that's their get out of jail free card and the conversation ends pretty quickly.

Oddly enough we don't see the same behavior with DEP machines, just the older non DEP that start out as 10.13 before enrollment.

Options (I'm sure there are many more than this but I'm not exploring):
1. Start the machine out as a 10.12 machine, enroll and FV, then upgrade to 10.13.
2. Build some sort of script/policy to enable the secure token on accounts where you could type password not in clear text. 3. Wait for Apple to build a better sysadminctl interface.
4. Wait for JAMF to fix the defect.

We are choosing 1 or 4. Most of our non-DEP macs are deployed so they are ready to go, if the user just upgrades to 10.13. In the unlikely event that we need to repurpose a non-DEP, we will do option 1.

Right now with all the "fun" Apple is having with 10.13, we are not rushing to upgrade, so hopefully option 4 comes along before.

[jowbaldw]

I am having the same issue.

[chris_kemp]

@dpodgors Curious - are you creating the end user first on these machines, or are you using an admin account to set them up? Given this:

In our case the original user created at setup, had the token enabled. The hidden admin created by enrollment did not. The mobile user (which is all we use) that logs in after enrollment, also did not have the token enabled. ... Oddly enough we don't see the same behavior with DEP machines, just the older non DEP that start out as 10.13 before enrollment.

It actually sounds like the same behavior to me. DEP setup creates that first user account which, if it's the end user, should allow the token to be set, yes?

[dpodgors]

Actually we turned off the initial account creation in DEP. So the first person to login is the mobil account.

[chris_kemp]

To be clear, I'm not talking about the DEP PreStage user, I'm talking about the user that is created when you log in for DEP.

[dpodgors]

Yes we turn that off.

[chris_kemp]

To be clear, I'm not talking about the DEP PreStage user, I'm talking about the user that is created when you log in for DEP.

Meaning initial setup, not during enrollment.

[dpodgors]

I give up - you win

[chris_kemp]

Win? I'm just trying to understand how you're enrolling your machines.

We have both DEP and re-deployed, non-DEP machines. One of the challenges we often have is that some techs insist on setting up machines as "admin" or similar, when we've explicitly told them to create an account using the end user's name. This is so that rollout policies will be correctly applied to the intended user, including FileVault, and not some backdoor admin account.

[jowbaldw]

So we don't have ANY DEP machines. New apple machines that we pull out of the box, setup our ADMIN account and then create a user ADMIN account can be FV2 with no issue.

The problem I am having is with computers that were upgraded to High Sierra. If you look at the Local User Accounts in JAMF all of them are set to NO under FileVault 2 Enabled.

If I run the same policy on a new machine it works just as designed, but on upgraded machines it asks the user to authenticate at login, then tells them to FV2 then a message about running in the background. But NOTHING happens. Everytime you reboot it shows those messages but never actually triggers the FV2.

sudo sysadminctl -secureTokenStatus [username] is set to DISABLED for each user.

[nellis]

Thanks for your response, dpodgors! While I haven't had the time to fully confirm my issue is the same, my preliminary review seems to indicate that it is. I also found this blog post that confirms the new secure token behavior that you describe. I really appreciate all of the detail!

Some of the new security features (and bugs) in High Sierra have had dubious implementations so far... It's made life difficult.

[analog_kid]

We are also seeing that accounts created via Jamf policy do not get a Secure Token and can't be enabled for FileVault without some manual intervention.

[AmigoDeluxe]

So is there a solution to this issue? We are using a disk encryption policy and facing the same issue. While it works fine on any pre-10.13.x macOS version, it fails with the latest one. Has anyone tested the 10.13.3 betas? Any ideas how we could get this to work?

Thanks
K

[nellis]

Here is the best solution we have found so far -- Posted by the creator in the MacAdmins slack channel in #filevault. Essentially, it allows you to script enabling the SecureToken for the logged in user. Hope this helps!

[afurtado]

Thank you for sharing your findings, at beginning it was not clear, got it now.

[tstott]

@nellis and now its broken with 10.13.3. .......... anyone able to fix it?

[gachowski]

@tstott

It's worked in my testing ... what version of Jamf Pro are you using?

C

[tstott]

Scrap that it is working. I had put in an OS requirement.....

[rcorbin]

Does anyone have a DEP workflow working yet with APFS and FileVault. Everything works fine for us with HFS+. But with APFS we don't get the secure tokens being added to user accounts consistently. Is it just totally broken ?

Our workflow would be something like this :
Turn on machine - boots to setup assistant. Machine talks to DEP. First user logs in and creates local account and password
Configuration Profiles get pushed down to machine
Prestage also creates an admin account
Filevault gets turned on. Both of those accounts need filevault secure tokens. But sometimes one account gets it and not the other.

Works perfectly with an HFS+ workflow but not with APFS. We just received a lot of laptops that are all in APFS format. It seems really sad to have to burn them down and reformat to HFS+ to make it all work correctly.

[CasperSally]

@rcorbin I'm just getting around to testing FV and so far it's working for me with 10.13.4.

Our prestage adds admin account but skips all screens possible. We enable FV via a policy scoped to all computers that need FV that aren't already enabled. It's set to run at startup and checkin/ongoing. Policy is setting a disk encryption payload that requires FV2 at next login. Techs are prompted that FV must be enabled.

I confirmed our admin user that is created via prestage has a secure token via the sysadminctl command above. I tested logging in with an AD user, and I got the 10.13.4 securetoken prompt "Enter a securetoken administrator's name and password to allow this mobile account to login at startup time." Tech enters our admin account credentials and then that account can login at startup. I confirmed this AD user has a securetoken & there's a FV recovery key in JSS. If technician clicks bypass at that prompt, no securetoken is given and that user cannot login at startup, but they can be enabled via the system prefs - security - FV screen.

Filevault does take such a long time to enable on APFS though, what a mess.