NOTE: All my previous statements on previous post regarding macOS Mojave remain valid. And so is the Quiz (Mojave only questions).This post is only about crosschecking them in macOS 10.15.1 Catalina
UPDATE 4th of December 2019: It seems that the change of behaviour with standard accounts created through Setup Assistant (user creation limited to standard account) is intended.

Yes, indeed, again! Secure Tokens. “Apple did not change much regarding Secure Tokens in macOS 10.15… only added the bootstrap token”. Cool, that’s good, we can all keep our sanity and do business as usual…

But wait, no, that’s not how it works, we need to test things! And so I did! And guess what?! While I have been rock solid positive on everything I posted in the past 12 months… I did run into a different behaviour with Catalina… so yeah, there we go AGAIN: test each and every scenario over and over again to be sure about what’s going on.

I did not do enough testing on bootstrap token and Mobile Accounts so I’ll leave that for a second post (but it seems that there are some changes regarding local admin account created by MDM when the first user logging in is a Mobile Account -> my jamfadmin account got a token… probably linked to the new bootstrap token feature. I need to do additional testing with Mobile Accounts to fully understand, as it conflicts the logic I’m going to describe here today).

Anyway, for now, let’s focus on LOCAL accounts, and remember, I’m NOT enabling FileVault yet! I’m only doing Automated MDM enrollment and testing the different prestage settings. As we know since macOS 10.14.2 there is no problem enabling FileVault anymore, even if there are no token holders on the system. Enabling FileVault, via any possible method, generates a token for the user enabling it.

That said, Catalina here we come! Test results below are valid for Jamf Pro 10.17 and macOS 10.15.1.

Like I did before for macOS Mojave resulting in this flowchart here, I’ll go through the different ‘Account Payload settings’ in the pre-stage:

  • No Account Payload added to the pre-stage (hence user creates admin account through Setup Assistant)
  • Account payload added, with user creation limited to ‘Standard Account’
  • Account payload added, but user creation set to ‘Administrator’

This 3rd option would be used in a scenario where you still want the end user to be admin, but on top of the Jamf Management account, you want to create another additional Admin Account.

In all the above scenario’s I’m NOT creating an extra Admin account, because there is no difference in the way it is created compared to the Jamf Management account.

To avoid confusion, convention for the results below:

  • jamfadmin = management account
  • ttg = account created by the user

Also, important to understand is the behaviour I descripted with the flow chart, where Jamf Pro either creates the ‘Management Account’ with either UID 80 or 501 !

So let’s go, … let’s see if Catalina is giving me any surprices (spoiler alert: YES)

Scenario 1: NO ACCOUNT PAYLOAD in the prestage

Here I expect the following result:

  1. jamfadmin account created with UID 80
  2. ttg created with UID 501
  3. Secure Token for jamfadmin: NO
  4. Secure Token for ttg: YES
  5. Additionally: bootstrap token

Well… no surprices here!

Scenario 2: ACCOUNT PAYLOAD in the prestage – user creation limited to ‘Standard account’

Here I expect the following result:

  1. jamfadmin account created with UID 501
  2. ttg created with UID 502
  3. Secure Token for jamfadmin: NO
  4. Secure Token for ttg: NO
  5. No bootstrap token

And this is where I got a surprise!

My ttg account is indeed a ‘Standard Account’:

And has UID 502, while jamfadmin has UID 501:

BUT ttg has a token !

This is against the behaviour in macOS Mojave (yes this surprise made me check the same deployment a couple of times again on macOS 10.14.6 !) but also against what Apple is writing in their official guide:

"When a user sets up a Mac on their own, they use Setup Assistant to create the initial local administrator account. If the Mac is enrolled in an MDM solution, the initial account may not be a local administrator account but rather a local standard user account. In both of these scenarios, the user is granted a SecureToken when they log in to the Mac if the user is the only user with a user ID greater than or equal to the value 500. This is true in most cases, however, because some MDM solutions may use agent tools to create additional users before a device exits Setup This behavior varies depending on configuration."

–> “the user is granted a SecureToken when they log in to the Mac if the user is the only user with a user ID greater than or equal to the value 500

Not only did I mention in my previous post that this only seems to be valid for standard accounts, as for Mojave I’ve showed that admin accounts always get a token if they are the first account interactively logging in into the Mac. The existance of another account with UID > 500 does not play a role. But, this behaviour seems to have changed in macOS 10.15.1.

To further proof this:

So, although the rest of my expected results are honored, we have one difference:

  1. jamfadmin account created with UID 501
  2. ttg created with UID 502
  3. Secure Token for jamfadmin: NO
  4. Secure Token for ttg: NO SECURE TOKEN for ttg: YES
  5. No bootstrap token

A secure token for a local standard account while there is another account on the system with UID 501… a bug? Or an undocumented change? So it seems…

Also, the lack of bootstrap token is expected imo, but that’s for another post on Mobile Accounts.

Scenario 3: ACCOUNT PAYLOAD in the prestage – user creation set to ‘Admin account’

Expected results:

  1. jamfadmin account created with UID 501
  2. ttg created with UID 502
  3. Secure Token for jamfadmin: NO
  4. Secure Token for ttg: YES
  5. Additionally: bootstrap token

Nothing special here !

That’s it for now! After all, only one little surprise which might actually come in handy if this is intended. Although, yeah it does not change much to be honnest, it’s only a standard Secure Token holder… still not able to manipulate, grant or manage other tokens…

Which still brings us back to scripting or a solution like LAPS in Jamf Connect Login !

Note: I did not test 'skip user creation' in the prestage in combination with Jamf Connect Login yet. I will of course add this scenario to the test as well, but I don't expect any difference with the above results. Whether you create local standard/admin accounts with Jamf Connect Login or the Setup Assistance, the results should be the same as the above. But yes, only one way to know for sure: TEST IT !
I'll do and update HERE.

More coming up in next post: macOS 10.15 Catalina and Secure Tokens for Mobile Accounts!

As always, if you liked this post, hit the like button, tell your friends about it and leave a comment down below!

Especially for this kind of things, if you notice any different behaviour, specific to your setup/environment or not, maybe even with another MDM, please share!

Brgds,
TTG

Print Friendly, PDF & Email