Authenticated Restart with FileVault 2 Not Working

HNTIT
Contributor II

We have a Policy In place for our DEP Zero-Touch Build that enables FV2 as the Management Account, and then performs an Authenticated Restart, however on reboot the machine requires FV2 Authentication when it should not.
See below Policy Log.

Any Ideas ?

Executing Policy InitialBuild - FV2 - Enable Using JAMF Account
Adding institutional recovery user from keychain.
Adding personal recovery user.
fdesetup: adding user 'JAMF' to FileVault.
........................
Recovery key = '(...)'
FileVault is Off, but will be enabled after the next restart.
Blessing i386 macOS System on /...
Creating Reboot Script...

1 ACCEPTED SOLUTION

HNTIT
Contributor II

Found the Issue.

Apple Lied, anything Pre 10.12 we have found, requires a reboot to start the FileVault Encryption, and until then you cannot add extra users.

As filevault is not actually enabled until next boot the reboot script wont work so you need to authenticate on the first reboot, rubbish and totally contrary to the APple documentation, but thats what we have found across our estate.

Machines that cant take 10.12 are being done very carefully, those that can are being upgraded to Sierra before FV2 is enabled.

View solution in original post

9 REPLIES 9

brytox
New Contributor III

We suffered this issue as well, we did a in place upgrade to 10.12.6, I believe this is a bug in the os. We did come up with a answer on this.

Sorry it's not a more helpful response!

MrP
Contributor III

This started happening with us on macos 10.13.2. Prior to that, as long as we used both institutional and individual recovery keys it worked. The bug in this case appears to be related to a number of other issues with FV that is on apple to fix as is indicated by apple's own tools not working as expected with FV. For instance using apple's built in tools you cannot add a user account to the machine from the terminal and have it be added to FV anymore. If you change a user's password from the terminal using apple's built in tools, FV is not updated with the new password. All of those worked in <= 10.13.1. JAMF might be able to figure out a work-around, but I wouldn't hold your breath.

easyedc
Valued Contributor II

What OS are you seeing this on? There's been some massive changes with 10.13... le sigh

tcandela
Valued Contributor II

must be with 10.13, looks to me that the JAMF crew doesn't test enough when new macOS are released.

easyedc
Valued Contributor II

I don't 100% pass the blame to JAMF on this. I see 10.13 as a step away from enterprise and towards consumer only from Apple. There are a number of things, FV2 being one, that being enrolled in an MDM doesn't help, not even DEP. Some things have to be done via GUI and can't be done via automated processes. Sure. Great. Definitely more secure, however, it sort of defeats a lot of things that I've put in place over the last few years.

kyleblanc
New Contributor III

Seeing something similar to this in our environment. No machines on 10.13. We have a policy that is set to run an authenticated reboot immediately if a user is logged in. We get as far as:

Blessing i386 macOS System on /... Creating Reboot Script...

And then the machine just sits there and does not reboot unless hard reset by the user. Anyone else seeing this behavior?

HNTIT
Contributor II

Found the Issue.

Apple Lied, anything Pre 10.12 we have found, requires a reboot to start the FileVault Encryption, and until then you cannot add extra users.

As filevault is not actually enabled until next boot the reboot script wont work so you need to authenticate on the first reboot, rubbish and totally contrary to the APple documentation, but thats what we have found across our estate.

Machines that cant take 10.12 are being done very carefully, those that can are being upgraded to Sierra before FV2 is enabled.

tim_porter
New Contributor

Anyone have any luck with this lately? I'm still struggling getting it working. Tried 10.10 and 10.13 OS and neither works with the checkbox in the policy.

therealmacjeezy
New Contributor III

I have two authenticated reboots that occur during enrollment (macOS 10.12 is our production) and have only seen this occur when corestorage isn’t enabled. After making sure corestorage is enabled it seems to function just fine.

I even have it working with 10.13 non-apfs volumes...that securetoken is giving me issues at the moment.

"Saying 'uhh..' is the human equivalent to buffering."