DEP Mojave Macs - No SecureToken created for management account

tomgluver
New Contributor III

At my organization, I've been getting new Macs out of box with Mojave, and the last two weeks or so, the admin account created at prestage (configured in user-initiated enrollment settings) is not getting a secure token. The only way i've seen a way around this is to either re-enable account creation in the prestage and manually create a second account that will have a secure token at the setup assistant, or run it through the normal prestage, delete the .AppleSetupDone, reboot, create a new account, and then use that account to enable a secure token on our primary account.

Is anyone else seeing this issue? Or a way to ensure our management account gets the secure token?

38 REPLIES 38

sshort
Valued Contributor

That’s expected behavior for the management account to not get securetoken because it’s a hidden user. As you mentioned, creating an additional local admin in the PreStage will receive a securetoken.

If the Mac is running 10.14.2, then that additional local account gets securetoken. If you’re on 10.14.1 (or earlier), AND you skip user creation in PreStage, AND it’s the first user to login, you get securetoken.

TTG
Contributor
Contributor

10.14.2 does not automatically give Secure Token to the additional prestage account either.

You can grant the additional account a token if no user has a token (because the first user logging in was a standard or Mobile account) or use the end user admin account to grant your additional admin account or management account a token. If the end user is admin and logged in as first user it will have a token.

The changes in 10.14.2 compared to .1 are:

  • sysadminctl will create tokens for both admin and other account if NO token holder exists (was not possible in 10.14.1)
  • policies and profiles will grant token to whatever user is enabling filevault. Did not work in 10.14.1
  • fdesetup will do the same (bug in 10.14.1)

For the rest, if a token holder exists, you need it to be ADMIN to be able to further manipulate tokens.

Prestage with account creation set to standard, or skip account creation, and mobile managed (non admin) or standard local account logs in first still gives you the issue that you will NOT be able to manipulate tokens later.

I tested all possible scenarios over and over again:

10.14.2 blog

Script

Malcolm
Contributor II

Great blog, i just tweeted you, the following question, but thought it might get seen faster.

The password used on our first logged on user account had a space in it, and was wondering if the script can be rewritten to use the expect command where using - 

e.g. -password -

-adminPassword -

 

I have read passwords starting with - and other characters are also likely to not work in the standard command.

TTG
Contributor
Contributor

Apple release notes also only say 10.14.2 allows to enable Filevault for MDM created users... = not created in system preferences.

Which is correct as you can now enable filevault with profile/policy without having a token. The user enabling it at logout or login will get one.

It does not say it gives it a token. But sysadminctl -adminUser adminaccount -adminPassword password -secureToken anyuser -password password will give you both the admin and the other user a token if NO token holder exists.

If there is any user with a token on the machine the adminuser in the command above need to be tokenised. If it’s not an admin and you don’t have an admin with a token it’s still game over

TTG
Contributor
Contributor

The fact that the management account is hidden doesn’t change anything imo.

I even tested giving the maanagement account a secure token and it even shows up at preBoot! This if you gave it a token before enabling filevault (all token holders get enabled for Fv when you enable Fv afterwards) or after enabling Fv if you run diskutil apfs updatePreboot /

See my notes on the blog.

Anyway, this is all based on my own testing with 10.14.2 by doing different scenarios over and over again with all possible combinations of account types, which account logs in first, profiles and policies etc.

sshort
Valued Contributor

@frederick.abeloos thank you for this!

TTG
Contributor
Contributor

@sshort You actually made me think about something!

Imagine you do end up with a Mac with only 1 Token holder... a non admin.

This is a problem, as this user can't give a token to your admin account. You can avoid this by logging in with an Admin at first login, or use a script to sort the tokens out before enabling FileVault.

But what if you do end up with FileVault enabled and only a non-admin token holder. I've been saying it's game over...

Well actually not really, sometimes the solution can be soo simple you overlook it!

I just tested it and it works: just promote your end user to admin, use sysadminctl to give your admin account a secure token and demote it again! Does not harm the Secure Token of the promoted/demoted end user.

Problem solved and you can easily script it.

TTG
Contributor
Contributor

Add the promote/demote the enduser part in the script: Script SecureTokens

yadin
Contributor

So you need secure token to enable secure token... who's responsible for the failure making this chicken and egg situation? Apple or JAMF? If Apple won't let JAMF make a proper first admin account, they need to fix this. If JAMF is missing the code that should be doing it, they really need to fix this. Not being able to have a fully serviceable machine with DEP is a real problem.

TTG
Contributor
Contributor

@ebonweaver not realy. First of all, Jamf has no impact this, the way Secure Tokens is designed is how it is.

But it’s not really a chicken or egg situation.

In normal workflows you configure a Mac and you become Admin by default. You’ll automatically log in after conpleting the setup assistant. By doing so you are automatically granted a secure token. No problem.

Now, when you do things with DEP and prestages, the situation changes but it all depends which user account is logging in as the very first user.

If the end user is granted admin rights in the prestage... no problem... end user logs in as first user and is granted secure token... no problem.

The problem starts when you are logging in with a non admin (standard) account as very first user, or a mobile account. Because these won’t get a secure token. But this is actually not a problem, because you can just enable filevault eith policy or profile and both will generate a token for the user enabling FV. This was broken in 10.14 and 10.14.1 due to a bug and fixed in 10.14.2. In 10.14.2 or later if nobody has a secure token, enabling FV will generate one... so no problem no chicken no egg.

But when you first login with a local admin (or the management account), and afterwards the end user log in (local standard or mobile account), there is a problem. In this case the admin will have a secure token and the end user will not. This is a big problem because in order to grand the end user a token you need both the admin and the end user password. Hence you need to intervene manually or script something like I did in my script. Asking the end user for the password and fix the secure token issue.

So, ling story short, there is only a real problem when the local admin logs in before the enduser, if the end user is not admin or if the end user is mobile account.

This is actually a reason to say:

1) don’t log in with an admin account before your end user logs in. There is no reason to do that, as you should be able to do everything remotely with policies and profiles. (why would you really need to log in with an admin before the end user????)

2) stop binding your macs to AD, if you don’t really need to... hence no problems with secure tokens, keychain and filevault password sync issues whcih you could cause with mobile accounts

My point of view is that there is actually no chicken or egg situation if you optimise your deployment strategy.

TTG
Contributor
Contributor

And if you are in a situation where you have secure token issues, script the fix and adjust future deployments to avoid it.

yadin
Contributor

Sorry but your assertions do not match experience. The first account logged in to after setup is the "additional admin" account made by the pre-stage enrollment policy. That account does NOT get a token, and is therefore not able to do anything, and secure boot utility does not work as it claims there are no admin accounts on the system. No users are ever involved at that stage, and that's not part of the issue for us at this point. There in fact is a lot of reasons the admin logs in immediately after enrollment as part of setup in preparation for deployment, because we can not do everything remotely, nor is the machine fully ready for use "out of the box". We also should not have to code work arounds for the product not working properly. If your assertion was correct that the first admin logged in after boot/prestage/config got securetoken, we wouldn't have an issue, but that's not the case.

TTG
Contributor
Contributor

@ebonweaver I just tested again, although I was 100% sure about my statement.

So I created a new prestage, skipped the account creation, and created an additional admin user. I log in with this user as the very first user ever logging in to the Mac... and it DOES get a secure token..

eec2ce3edaf340be8b7f704b1484df54
8534126edfde403e83151edd18d09600

TTG
Contributor
Contributor

Can you test again on a clean machine, don't use any previously snapshotted VM's. Secure tokens survive snapshots.

Run: diskutil apfs listcryptousers / and you will get a list of all the UUID's of the users with a secure token...

yadin
Contributor

We have tested many times on many machines fresh out of the box 10.14.3. There are no VMs involved. That command and the sysadminctl command to query users with tokens returns none. It would seem you have already "scripted a fix" that is resolving this issue for you.

TTG
Contributor
Contributor

:-) no sir, I did not and I would not know why I would do that. I can replicate exactly the same scenario on physical machines.

Clean Mac (VM or Physical) -> Jamf Pro prestage -> DEP -> NO other user logs in -> the additional admin or the Jamf management account logs in as very first users: it gets a token.

If that is not working for you, there must be something your are doing in between the steps above to break it. It's as simple as that. The first LOCAL admin account logging in to a CLEAN Mac gets a secure token.

I did not script any fix to trick you with some screenshots. Only trying to help you identify the real root cause, but it is definitely not the Jamf Pro server or the local admin you are using.

TTG
Contributor
Contributor

And only if that local admin is really the first user logging in.

yadin
Contributor

I think I may have found the issue. Our enterprise instance is 10.8 which we were told supported Mojave. I'm seeing information that indicates you need 10.9 minimum to actually support Mojave's security features. I've inquired with the enterprise admins when they plan to update, hopefully to 10.10 since I see that's been released now too.

TTG
Contributor
Contributor

@ebonweaver No, the version of Jamf does not impact anything regarding secure tokens. The only variable playing a role is the first user logging in.

First user ever logging in to the Mac = local admin = gets a secure token
First user ever logging in to the Mac = local standard = no secure token
First user ever logging in to the Mac = mobile account = no secure token

That said, having NO secure token holder at all is NOT a problem. Just enable Filevault with policy or profile, and the user actually enabling it (at logout for profile, at login for policy) WILL get a token. Whatever account type it is.

Jamf Pro version compatibility with Mojave security features, is completely irrelevant. That's for KEXT and PPPC.

It's really as simple as it is: if the first user is a local admin, whether that is the management account created by Jamf, or the additional admin account you create in the prestige, or a local admin account created by the end user in the setup assistant does NOT matter.

MacOS doesn't know anything like "a Management account". There is no such thing. macOS only knows admin or standard. How it was created does NOT matter. Again, if the very first user logging in is a local admin, it gets a token.

The "management account" created by Jamf is only a local admin, nothing special about it, no difference with any other local admin. The only reason Jamf calls it "management accounts" is because, if created by Jamf Pro, Jamf Pro knows the password (encrypted in the Jamf Pro Database). This either "a known password" or a Randomly Generated password (see User Initiated Enrollment Settings in Jamf Pro).

The only purpose of that "Management account" is to use Jamf Remote... as Jamf Pro knows the password, even if randomly generated... it can just remote into the Mac. No other purpose at all, NO impact on Secure Tokens or whatsoever.

Again, I'm sorry to repeat it: it's only the first ever user logging in impacting your Secure Token situation.

Just to be sure, with logging in I mean physically logging in... not remoting in via ssh or so...

yadin
Contributor

"Again, if the very first user logging in is a local admin, it gets a token"

You're obviously very convinced of what you're saying, so there's clearly no way I can convince you it's not true, but I'm sorry to say it's not true. If it was, there would be no problem, and I would not have dozens of machines with no securetoken on the admin account.

TTG
Contributor
Contributor

@ebonweaver well, I'm only trying to help, and I can only say I'm deploying Jamf on a daily basis. Yes, I'm positive about the following statements:

  • I have no reason not to believe you. Just trying to help.
  • Jamf Pro on it own does not have any influence on whether the first local admin account logging in, before ANY other user ever logs in, gets a token or not. It just does.
  • It does not matter if it's the "management account", the extra DEP Prestage admin account, or the admin account created by the end user during the setup assistant. First user logging in = local admin = token

This taking into account:
- we are talking about macOS 10.14.2 or later
- we are talking about CLEAN macOS deployments, wiped devices going through a clean DEP workflow
- there are no @enrolment triggered policies with scripts or things happening which might break things. I would not immediately know what could break it, but I just be sure, you tested with a prestage, skipping account creation and logging in with the additional account without anything else. Obviously you would be deploying things post enrolment etc... but just to make sure you tested the exact same basic scenario. From there you would be able to isolate potential reasons for trouble

Just too show you I'm not inventing anything, doing some trickery, I hereby give you a screen recording. Yes, it's a VM, but I have no reason to lie about it, it's exactly the same on my physical machine. Just in case... I added the running clock to the screen to show I'm not editing the video. Its a bit slow... it's running on an old virtualised Mac Mini, but yet again, same result on physical device.

VIDEO

Hope you find the reason for the trouble.

brobbins
New Contributor II

Hello everyone, we have fresh out of the box MacMini(s); going throughDEP; going through Pre-Stage; Prestage creates the "management" account, keep in mind it is a hidden account. Our Pre-stage also creates and second account.

We are running 10.14.4 (we re-installed the OS as well from the internet), and we log in to our JAMF management account first thing. It does NOT create a secure token for that user.

There is nothing else out of the ordinary we are doing.
Any thoughts?

TTG
Contributor
Contributor

Hi brobbins, I did not try with 10.14.4 yet but, which Mac Mini’s are those? The ‘diskutil apfs listcryptousers /‘ command is returning “no cryptousers?

applesupport
New Contributor

Hallo Frederick, what's happens if you hide the 501 user? does it also create a secure token for this hidden user?

TTG
Contributor
Contributor

Hi @applesupport I just tested on macOS 10.14.3 (I need to update my vFuse VM for 10.14.4 but I would really be surprised if that would change anything, but I'll test again later).

I have a clean macOS, going through the pre-stage with "skip user creation". The only account being created is the "Management Account", which is set to be hidden in "User Initiated Enrolment" settings in Jamf Pro.

After the setup assistant I can confirm the account is hidden:

7f34b01fd70d491fa10dce1e2b01d9df

I log in with the Management Account and I DO have a Secure Token, while FileVault is NOT yet enabled:

e06fc077148045d3a7bcafecd0e445c9

324af5f66c32439ebd86246f25b78e3c

pvcit
New Contributor III

After further testing for me, jamf management account and extra admin account both get disabled but when I set the policy to encrypt, the jamf management account then gets the secure Token.

TTG
Contributor
Contributor

Hi @pvcit

Yes. But step away from considering the management account as a special account. The management account in Jamf Pro is nothing different than any local admin account. In older versions of Jamf Pro the management account was used to do stuff with the Jamf Binary, but for many years now it is used for.... nothing. Nothing, except the Jamf Remote app who uses the credentials stored in the Jamf Pro database to connect (ssh) to devices. Policies are executed by root, not the management account. Apart from that it just a local admin account, which you actually don't need at all if you don't use Jamf Remote, or if you used this account as an IT Admin team backdoor into the Macs.

That said, there is no difference between the management account and the extra admin account. But, as I discussed in my latest blog post, the Jamf Pro prestage does act a bit inconsistent in the way it creates it. In theory it should respect the setting you defined in User Initiated Enrolment. I mean: creating the management account or not, and hide it - or not.

It does respect this settings if you DO NOT add the "accounts settings payload". So if you hide the management account, the Jamf Pro prestage creates it with UID 80. UID below 500, which means that the first local account ever logging in, and only at that very first login, gets a secure token. Because you don't add the "accounts settings payload", that account will be the user account created in the setup assistant, and hence an admin. But that does not really matter. Only that account will have a token because it's automatically logging in at the end of the setup assistant. The management account does not get a token because it's not the first account logging in.

Things get more complicated when you add the "accounts setting payload". In that case, the Jamf Pro prestage behaves differently. It creates the management account whether or not you said to create in in User Initiated Enrollment settings, and further more, it creates it as UID 501. Because there is an account with UID above 500, the presence of this account impacts the creation of a secure token for the first account logging in.

If you do not skip user creation, you have to options: the setup assistant creates a local admin or a local standard account. If you create a local admin, that user logs in automatically as an admin, and yet again is automatically the very first account logging in. Hence it gets a token. Apple does not really explain this very accurate in their recent document, but I've been contacted by a confidential source in Apple telling me that what I wrote in the blog is actually correct and the document will go through internal review again to be updated. This said, the very first account logging in, ALWAYS gets a secure token if it's a local admin, and only at that very first interactive login.

But, because the prestage creates a 501 management account if you add the "accounts setting payload", it impacts standard accounts. If you restrict the setup assistant to create a standard account... it does not get a token because the management with UID 502 exists. This is explained in Apple's document and fully accurate.

If you skip user account creation in the prestage... then it depends again who is logging in at the very first interactive login. If you log in with the management account, or any additional admin account.... it will get a token. If you login in with a mobile account (AD Bind), it does not. And because there will be no other accounts on the Mac there is no other option (unless you created an account via scipt or policy, but yet again that will follow the same behaviour as any other account).

Now, what about Nomad or Jamf Connect. Exactly the same: if admin account = token, if standard account = no token.

More info on Secure Tokens Flowchart

A few more considerations:

  1. Stop considering the management account as something special, and don't expect it to get a secure token in any other way as any other local account
  2. Do not expect any accounts to automatically get a secure token other than the very first account ever interactively logging in to the Mac

  3. BUT all this is only considering the automatic creation of secure tokens WITHOUT enabling FileVault

As you said, if there is NO token holder at all on the Mac, you can enable FileVault via sys prefs, a Jamf Pro policy or profile. The account enabling FileVault, by unlocking the FileVault settings in sys prefs, or logging out if you enforce FileVault with profile, or logging in if you enforce it by a policy.... the account actually enabling FileVault WILL get a secure token. But only if NO token holder exists. If there is a token holder for one reason or another, the account trying to enable FileVault with a token will see "unable to enable FileVault".

4 . Finally, when testing secure tokens and initial prestage deployments, DO NOT use local snapshots (as in running tmutil snapshot in terminal during the setup assistant). This completely makes you testing invalid as secure token holders, with their UID survive the snapshot as ghost token holder. Reference to the UID of the token holder will still be there after reverting back to the 'clean' snaphot... a UID of a non existing account but WITH a secure token. Virtual machine snapshots at the very first welcome screen of the setup assistant seem to be ok however.

derek_ritchison
Contributor

Not to resurrect a dead thread but I very recently discovered that this was affecting a large number of machines in my fleet: The admin user that is created during the new user set up process (ie: the employee getting the machine) gets a secureToken, sure. But the DEP-created "itsupport" admin profile is never (never never never never never) given a secureToken. Machine after machine, I have to run the "sysadminctl -adminUser user -adminPassword password -secureTokenOn itsupport -password -" and then enter my itsupport password just to enable the token. It is not automated, and it is a huge pain as I have over 100 MacBooks where my admin account is not FV enabled.

TTG
Contributor
Contributor

Hi @derek.ritchison

That’s 100% expected behavior and by Apple design. It’s only the very first account ever doing an interactive login which is eligible for automatically getting a secure token.

After this very first interactive login, whether or not a token is granted (see flowchart below), your chance to get a user tokenized automatically is gone...

Any next login will NOT generate a token anymore.

Only fdesetup, manually enabling FV or a Jamf Pro policy or profile will then grant a token for the FV enabling user.

Or any command line intervention or script like you mentioned.

https://travellingtechguy.eu/final-wrap-up-on-secure-tokens/

https://travellingtechguy.eu/script-secure-tokens-mojave/

TTG
Contributor
Contributor

The fact that your ItSupport admin account is DEP created or not is irrelevant. If you would log in as very first user ever logging in... when skipping account creation.... it WILL get a token.

This because it’s the first account logging in, and it’s an admin and hence other user accounts with UID above 500 existing on the mac or not does not impact it.

But then you end up with any end user account without a token...

derek_ritchison
Contributor

Got it. And thanks again for the response. IMO, Apple could redesign this so that a DEP-created admin user would be assigned a secure token and auto-enabled for FV. This just creates even more extra steps for IT "pre-onboarding" and makes me believe that "no touch onboarding" is still just a fool's dream.

TTG
Contributor
Contributor

For Mobile or ABM/ASM provisioned accounts, it will change in Catalina.

hectorlencina24
New Contributor

Hi, I could find the Solution for all the people that doesn't have a valid Secure Token Enabled in the local accounts or can't find anything related in how to enable the secure Token in your System (It doesn't require to re-install the computer).

What I did, was to create a partition in the disk, install MacOS in that partition, create a username for that partition with the same name that the local admin account in the partition that didn't work. Then after all the initial configuration was made, I linked the account to the Other partition's Home folder (with the same username that doesn't have the SecureToken Enabled).
Rebooted the computer, logged in in the partition that I had problems before with the local admin account. Went to filevault, turned on, it prompted me with the password of the account that was "enabled" and it started working, also let me Enable other local accounts.
The only comment that I'll do, is that I had a local user with the secure token enabled but didin't allow me to filevault from there or use any command of sysadminctl to enable other accounts. After I did this, it allowed me to enable other accounts to unlock the disk, and those accounts automatically had the SecureToken ENABLED.
I spend more than 5 hours testing this and I won, so I'm Hyped.
Any question (To clarify this because is 3 am in the Morning in Argentina) Write me an email to hectorlencina24@gmail.com

Thank you!

TTG
Contributor
Contributor

Of there is no user account with a Secure Token, than just enable FileVault will give the enabling user a Token. Since 10.14.2 this all works fine.

You also mention “You had a token”, so what was the problem/reason in that case to go through every thing you described?

Mkh
New Contributor III

Hey Fredrik,

you provided great info here, I'm still new to JAMF & still trying to find my feet here :) I have maybe a stupid question but need an answer.

all our end users have admin accounts and all of their accounts have SecureToken enabled BUT i need a way to enable secureToken on JAMF management account to be able to get FILEVAULT 2 RECOVERY KEY!

It's true I still can enable FileVault remotely and it's true that the management account is unhidden !

any recommendations or tips please?

Mkh
New Contributor III

Hey Fredrik,

you provided great info here, I'm still new to JAMF & still trying to find my feet here :) I have maybe a stupid question but need an answer.

all our end users have admin accounts and all of their accounts have SecureToken enabled BUT i need a way to enable secureToken on JAMF management account to be able to get FILEVAULT 2 RECOVERY KEY!

It's true I still can enable FileVault remotely and it's true that the management account is unhidden !

any recommendations or tips please?

TTG
Contributor
Contributor

Hi,

You should not need a Management Account with Secure Token in order to get a FV recovery key as such...

Enabling/enforcing FV for the end user will generate a recovery key for that user and escrow that in Jamf Pro ( if you configure that option that is).

Hence you should not need a special recovery key linked to the management account...

But if you really want to give the Management Account a token (and enable it for Filevault, and have a recovery key for it).... you can but that brings us back to the discussion of who gets a token Automatically.... and all other accounts need to be scripted into getting a secure token. Nothing special or different for the management account, as it’s just a local admin like any other.

So if your end users have a token and you really want the management account to have one too... script via a known local admin token holder will be the only way to go.

Mkh
New Contributor III

Two things :

-1 could you take me through it to get FV recovery key ? this is what I tried to do :

0f1968706eca455da1a112cc31356ed2

15fed394dd5a40e09aa7089a70ef6513

as long as I can get the recovery key to unlock the disk I don't need to enable SecureToken the management account.