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:
- 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
Do not expect any accounts to automatically get a secure token other than the very first account ever interactively logging in to the Mac
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.
