macOS and iOS management with a twist of Jamf (less travel, a lot more tech)

macOS Catalina – Secure Tokens part 1: Local Accounts

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.

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:

jamfadmin account created with UID 501

ttg created with UID 502

Secure Token for jamfadmin: NO

Secure Token for ttg: NOSECURE TOKEN for ttg: YES

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.

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…

Note: After testing skip user creation and deploying Jamf Connect, I found out that only admin accounts created via Jamf Connect receive a Secure Token. This matches Apple’s documentation saying that only when the account is demoted to Standard in the setup assistance, it automatically get a token. Standards accounts deployed programmatically, like Jamf Connect DON’T !

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!

I have seen similar behaviour on Catalina where, if the policy executes while being on the login window of jamf connect it indeed defers to unknown user. This because no account logged in yet and complete the account setup. Even the account created as additional admin would go through finalizing account setup at first login. I only recently discovered this, so I would advise to enable Filevault via jamf connect: https://www.jamf.com/jamf-nation/articles/708/enabling-filevault-with-jamf-connect-login-on-macos-10-15-or-later Pro Tip: save the additional config profile as .mobileconfig and sign it prior to uploading to jamf pro

OK . I actually not signed it but still seems to work as far I can see?

Is there somehow an option to edit the the message when encrypting.It just show “fdesetup would like to enable filevault” I also really don´t like that users just can click “cancel” on encryption option, but guess that is part of the apple user protection that they have to accept every single thing – not very good in enterprise

Jamf Connect does not escrow the key like jamf pro policy does. You need to add a config profile with the escrow option enabled. A custom one or the one from jamf pro without require filevault would work as well. But set it prior to encrypting