No secureToken present

easyedc
Valued Contributor II

Having a problem and I wonder if others are having similar issues. In our early testing, we imaged 10.13 with an erase and install, and then enrolled in our JAMF Pro server. The initial account created on the computers we deleted, because they were dummy accounts, and our JAMF server created all necessary accounts by policy for the last almost decade. Fast forward a bit, and we get past initial OS testing and realize that we don't have an account which has secureToken enabled. And we can't turn on secureToken without an enabled account. So we're in a catch-22. Do I pretty much have zero choice but to delete these workstations and start over? It's only affecting a small population, but no one wants to go through the process of an E&I...

I have a ticket open with Apple on this, but they've been less than helpful with suggestions. Anyone else having this issue, or figured out a work around? DEP doesn't help, since some think that is Apple's answer to everything lately.

1 ACCEPTED SOLUTION

easyedc
Valued Contributor II

My AppleCare ticket has come back to me with

If the imaging process you're using right now does not create an initial account that is secureToken enabled to begin with, then no user's will be able to be secureToken enabled and there will be no accounts on the client that can provide secureToken to other accounts and FileVault cannot be enabled. At this point, if you have a client where no accounts are secureToken enabled, the only option is to erase and install or re-image create an account with secureToken enabled. I am not aware of any other work arounds at this time.

Looks like some E&I's are in our future.

View solution in original post

21 REPLIES 21

chestick
New Contributor

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

easyedc
Valued Contributor II

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.

koalatee
Contributor II

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.

blairb
New Contributor III

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.

therealmacjeezy
New Contributor III

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.

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

easyedc
Valued Contributor II

My AppleCare ticket has come back to me with

If the imaging process you're using right now does not create an initial account that is secureToken enabled to begin with, then no user's will be able to be secureToken enabled and there will be no accounts on the client that can provide secureToken to other accounts and FileVault cannot be enabled. At this point, if you have a client where no accounts are secureToken enabled, the only option is to erase and install or re-image create an account with secureToken enabled. I am not aware of any other work arounds at this time.

Looks like some E&I's are in our future.

mm2270
Legendary Contributor III

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.

maxbehr
Contributor II

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

kstrick
Contributor III

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*

dstranathan
Valued Contributor II

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

seann
Contributor

@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.

dstranathan
Valued Contributor II

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.

seann
Contributor

@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.

dstranathan
Valued Contributor II

Thanks @seann

achmelvic
New Contributor III

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!

seann
Contributor

@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. :)

allanp81
Valued Contributor

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.

seann
Contributor

@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.

robby_c137
New Contributor III

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!

japplecore
New Contributor

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.

B_Hanson
New Contributor III
New Contributor III

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.