Update: my flowchart below is only talking about whether or not you end up with a secure token holder at initial deployment. This taking into account we are NOT yet enabling FileVault. Some readers had some confusion about the mobile accounts, but yes, enabling FV will grant a token to the enabling user... if no other token holder exists on the mac, but this is outside the scope of this flowchart. I’m only showing what happens at initial deployment WITHOUT enabling FV by any means.
Yes, I could not resists. After having a chat with some people, I still felt like there is soo much confusion on Secure Tokens, so I decided to try to put in into a flow chart.
I’m going to keep this post short. I only want to share the flow chart I made. Against based on all my testing and observations over the last few months, and cross checking my statements with Apple’s Official guide.
As said in my previous post, Apple should tweak their document to mention that if the very first interactive logging on the machine, or at the end of the Setup Assistant, is done by a LOCAL ADMIN, this account always gets a Secure Token. Regardless of whether or not there is another user with UID greater than 500 present on the mac (created by MDM during the DEP pre-stage, such as the Jamf Pro Management Account or any additional Admin).
IMO, based on all my testing, the additional +500 UID user only impacts Standard Users at the very first interactive login.
Apart from that, we have the behaviour of the Jamf Pro Pre-Stage Enrolment, which does not honour the User Initiated Enrolment settings as discussed in my previous post.
So, with that knowledge, here is my final wrap up on Secure Tokens. First flow chart showing how it should be. Second with Jamf Pro Pre-stage behaving a little different.
That’s it! On this note, mic drop, Secure Token out.
Brgds,
TTG
Apple ecosystem enthusiast, geek, tech gadget freak, Belgian living in the Netherlands
Manager Technical Support | Jamf
So how would the Jamf connect or nomad login work with secure tokens in your diagram? Now that you finally understand all of the secure tokens. ????
Same as any local account 🙂 see it as “skip account creation”. If no other local admin is created, or hidden that is (taking into account the behavior of the account payload in prestage), and hence no +500 uid account exists on the mac, the Jamf Connect / Nomad created standard account will get secure token if first account ever to log in. If the jamf connect / nomad account is admin, and first ever account to log in, it gets a secure token (regardless of other accounts in the mac), if it’s the first ever account loggin in.
I’m still a little confused……We create a local admin account via JAMF in PreStage named locadmin (501). It’s an admin account, that is not hidden. We do NOT skip account creation. The account created at setup (502) DOES get secure token, but my PreStage Admin (501) does not get a token. Did I read the diagram wrong? I was expecting my 501 account to have a secure token. In the explanation above, is there any way for my 501 prestage admin account to get a token?
It’s always only the very first interactive login which triggers a secure token, and only for that account logging in. There is no way to go through a prestage at initial deployment and end up with having more than one account with a token. Only the very very first login triggers it automatically… if the conditions in the flowchart are met. ALL other existing accounts will need to get a token via that initial token holder. Furthermore, any accounts created afterwards will only get one when created manually, by a token holder in the system preferences. All other account creations (script, policy,…) will need to get a token manually or scripted via another token holder.
Long story short, no you can’t automatically get your 501 and 502 user tokenized by just going through the prestage.
Frederick:
Any updates on this we move into Monterey and Jamf Pro 10.33? Has Apple made this any easier to manage in the enterprise? Has Jamf figured out any work-arounds for us?
Thanks for the info!
– Scott in Toronto
HI Scott. Have you checked the other posts since I wrote this? A lot changed already for more than 12 months and since Big Sur. This was a post related macOS Catalina 2 years ago!
Blogposts on FileVault
Monterey should be like Big Sur in view of Secure Tokens.
Well, no, (he admits sheepishly) I had bookmarked this one and was coming back to it.
I’ll browse around and see what the rest of your posts tell me.
Thank you for them.
– Scott
No worries 😉 let met know if there is anything I can help with!
Frederick,
Secure Tokens are a absolute beast, an enigma…
I thought they were finally solved / addressed with macOS Monterey… as in any subsequent user created in Monterey, automatically gets a Secure Token, whether admin or not. I believe that is true.
But a user account created in, say in the Jamf Pro PreStage enrollment > Accounts does not have the Secure Token “enabled” unless that user ever logs in…
Indeed, and that is 100% expected and per Apple Design. The managed admin (prestage) does not get a Secure Token on initial creation, such as also the Jamf Management account which we create with the Secure Token disabled flag. Subsequent logins do trigger it if Bootstrap is enabled. 100% as per design and expected.