Managed FileVault much more complicated in High Sierra

Contributor III

Has anyone else run across an issue with turning on FileVault for AD accounts in High Sierra? I'm testing deploying now and our workflow is to use MNE to enforce FileVault once the user receives their computer so that on their first login they are prompted to restart. On restart they are prompted for their password, but the Mac gives an error saying to enable FileVault in system Preferences.

So I tried to create a Configuration Profile requiring FileVault and receive the same error.

So I tried enabling in System P{references and receive a different error:

Authentication server refused operation because the current credentials are not authorized for the requested operation.

I found this article: Seems like Apple no longer supports non-admin users or AD users enabling FileVault. This will be a complete PITA for government and enterprise customers and means that we can no longer deploy machines and expect the user to be able to encrypt the drive without intervention from the helpdesk.


Valued Contributor III

What I've always used is a script that runs once per day and performs a couple checks. Once it identifies that the currently logged in user is not our local administrator account (or another usual management-type account), it will enable FV for that user on next login with no deferment allowed.

The user doesn't have to do anything, and FV will be forced on next login. If for some reason I got the wrong account, the daily script will keep trying until it eventually encrypts the system. It would be really hard to avoid it and the user doesn't have to do anything.

You could also just make a Self Service policy to perform the action as root, so users could still do it manually.

Contributor III

Have you tried the script with High Sierra on a Mobile account? From the Apple document it sounds like FileVault can only be enabled by a local administrator. I am not even able to manually enable it with a mobile account that has admin rights.

New Contributor III


Could you post that script by any chance? I thought it was nigh-on impossible to do this via filevault as it requires the users password

Contributor II

Here's some info - basically the change is SecureToken. SecureToken is separate from admin + filevault, but is needed to enable Filevault or add the user to filevault. In order to give a mobile account SecureToken, you must have an admin account that has SecureToken.

AD mobile accounts do not get SecureToken by default. There are ways around it, and ways to give AD accounts SecureToken (manually), but really it depends on your environment as to what is best.

I'd recommend joining the macadmins slack and check out #filevault or #highsierra to look at some discussions.

Valued Contributor III

Yeah, I was wrong about the use case here, I hadn't been working with APFS and had been doing HFS+ imaging. I still might stick with HFS+ based on how horrible the workflows are for FV on APFS.


Snippet of code to give back a 0 or 1 if your console user has a SecureToken or not (why use sysadmctl and feed it admin passwords on the command line to find this out when dscl does it for free!)

grep -c SecureToken <<< $(dscl . read Users/$(stat -f %Su /dev/console) AuthenticationAuthority)

Valued Contributor III

Just a note: in 10.13.4, you no longer need admin credentials or sudo to use sysadminctl just to check a user's SecureToken status.

sysadminctl -secureTokenStatus username

...will give you the result. About time, Apple!

Valued Contributor

We are beginning to test Hi-C. We are testing on 10.13.4. we are 95% 1 to 1. localadmin has the securetoken and encrypts drive. Prior to sending out to user, we create the users AD/Mobile account based on this hint from a few years ago to add the user to FV. So once they power on they just login. This will also come in handy on those few shared use machines. Just ssh in and add the user(s)