No secureToken present

I have the same challenge as well. Really do not want to be rebuilding all these Macs from scratch.

In my case, it's a fairly low number, but it's computers we turned over for active use, so there's users data on it.

Sometimes you can still initialize FileVault when no users have securetoken, but that train might have departed since you deleted the original user. I think that case applies only (?) when upgrading from prior version or skipping account creation with DEP so the first user created will get securetoken (even if a mobile account).

Most likely you need to wipe though.

Based on my experience with my home iMac, you're going to have to wipe and install from scratch. None of the many workarounds I tried worked at all. Very frustrating experience.

I ran into this also when I was testing 10.13. I found the only fix was to wipe and start over. I wrote a script to capture the password of the “setup” user which will then issue the management account a secure token.

Then I have another script that will issue any new account a secure token using the management account.

Just more proof that Apple really doesn't think of or care about enterprise environments. It's kind of absurd that we need to go through the hassle of erase and install on systems already being used, all because of dumb items that Apple added in for reasons that no-one understands. They need to fix these messes. This craziness around the SecureToken crap has been going on too long. God forbid Apple actually spend a few bucks from the billions in their coffers to get someone working on fixing this. It's easier to just throw their hands up and go, oops. You'll need to wipe them, sorry.

Check out Rich's great article on SecureToken and APFS encryption at his blog

I have been told by Apple Enterprise that there will be some sort of Enterprise solution in a future release of High Sierra, but no ETA and I'm not holding my breath. This whole secureToken implementation is a clusterf*

Isn't there a way to provision a local admin account (i.e.; the Jamf service account) with a SecureToken at imaging/deployment time?

@dstranathan The very first account created will have securetoken. What we have done is to have a separate management-only account for Jamf (which gets on there during enrollment), and with a prestage we create our local interactive 'admin' account for the techs, which gets securetoken, and subsequently allows all other accounts to be granted securetoken via this.

Alas, I'm in a chicken-and-egg situation here.

What about 10.13 Macs already in production? How do I get my existing local admin account a SecureToken attribute? Soulds like it is impossible...?

PreStage Enrollment is only for DEP, correct? What about customers who don't use DEP yet?

What about older Macs running 10.10, 10.11, 10.12 that get upgraded in-place to 10.13 High Sierra? Do any exisiting accounts get the SecureToken attribute?

No way Im wiping/eraing all production Macs just to choehorn in a new local admin account for Secure Token.

I dont use FileVault (yet), but this could be a fairly big issue in the future if I can retrofit SecureToken.

@dstranathan If there is no account on a 10.13 with securetoken then you're out of luck right now, and would need to reimage AFAIK. Maybe Apple will come up with a solution in the future b/c I agree that it can be a show stopper for many.

Accounts on systems upgraded to 10.13 should be given secure token.

And yes you're right, lack of securetoken means you can't enable accounts to unlock fv2 which can be disastrous.

Trouton says here https://gist.github.com/rtrouton/c9e6290b3208aea1ac2740dade2aa994 that accounts made via MDM createuser command as well as directory accounts get securetoken. I don't think these two caveats works in practice, maybe others can attest to this. His syntax is also wrong for the sysadminctl commands, they must be run with an interactive flag set.

Thanks @seann

After much investigating with the secure token fun on multiple physical and virtual macs I've come to the conclusion that unless Apple change something soon then like @dstranathan we're facing the prospect of wiping and rebuilding in service machines, potentially up to about 30 which isn't the end of the world but getting the end users to agree to it might be fun...

@seann I've found that need use the interactive flag with sysadminctl seems to be either intermittent or Apple are changing it between point releases. I've run the sysadminctl -secureTokenStatis command on various different physical and virtual macs and as far as I can conclude in 10.13.3 it wants the interactive flag whereas in 10.13.4 (including this week's 2018-001 update) it doesn't! So @rtrouton's syntax may well be right depending upon which release of High Sierra he was running at the time.

We also have a push to roll out both High Sierra and FileVault to all our in service machines but the as far as I know complete lack documentation from Apple about secure token and the way they seem to keep tweaking and changing the spec is making it pretty hard to work with to say the least!

@achmelvic I think he referenced 10.13.2 in that post. Anyway, the interactive flag was definitely needed for me when granting secure token. Don't remember which point release I was working with at that time though, may have been .3

Basically the moral of the story is be very careful with what you do with initial account creation, and move to DEP for imaging. Otherwise you'll make your life very difficult, if not now then in the near future. :)

Can someone clarify something:

We are imaging the "old fashioned" way still as it works best for us. I'm using AutoDMG to create an image of 10.13.4 and then distributing this using Jamf Imaging with a full wipe and restore of the base image plus apps etc. One step during this also creates an admin account.

Doing it this way seems to mean I then can't ever have an account with secure token but as these devices will never have filevault on them will this actually cause me any issues long term? Apart from the MDM user approval annoyance, everything seems to be working just fine imaging this way, with no errors on login or anything.

@allanp81 Only Apple would be able to tell you, and I doubt they will comment on under the hood upcoming OS changes. I foresee this becoming more important in the future though, considering their other recent security moves.

As of 10.13.5, the rtrouton caveats seem to be working for me. That is, the admin user created via pre-stage on a DEP machine and subsequently the directory user on our AD bound machines do get the SecureToken attribute. I use a standard config profile with FileVault Escrow to scoop up the individual private key. Now, I just have to call back the 30 or so machines without SecureToken and wipe them. 😖

We've been on DEP and rarely use Jamf Imaging so it's just the inconvenience of the calling back those unsecured machines that got caught pre-10.13.5.

For those who don't bind this script might help make things easier to issue your users SecureToken with zero-touch provided you're creating a user via mdm createuser or setup assistant.

Hope this helps!

As long as the machines aren't already encrypted with FV, you can alternatively re-initiate the Apple setup, thus creating a new admin account with a secure token. That account can be used to provide tokens to the affected accounts and can be deleted once the token administration process has been completed. In terminal simply:

rm /var/db/.AppleSetupDone

This trick also works if you have a non-admin user with a secure token but need an admin user to provide tokens to other users.

Sorry if this is old news, I found this thread from a google search.

Not sure when this became available, but in macOS 10.15.7 if you have no SecureToken user and you boot into Recovery, you will be prompted to "Set a password for all users on this Mac". This may also require that "Find My Mac" is enabled, which "sees" there is no SecureToken holder when in Recovery so it forces you to set a password for all users before getting all the way into Recovery. After this, rebooted and I had SecureToken granted to both admins and was able to turn on FileVault.