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.

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.

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/

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

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.

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

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!

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?

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?

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?

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.

Two things :

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

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

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.