No SecureToken for prestage admin

[GPS-IT]

I've seen a lot of posts on this but none quite like I am experiencing. We have a laptop and a desktop prestage. Both create local admin account before setup assistant the laptop creates and admin during enrollment. The desktop skips it. However what we are seeing is the account that gets the SecureToken is a standard account thats pushed via policies. On desktops the prestage localadmin is the first account to login always but yet it doesnt get the securetoken.. The laptop an admin is created during the setup process and that seems to not get it either. This causes a problem when running OS updates or changing a forgotten pw from the localadmin account. 

Typically, I promote the standard account to admin, login and use a terminal command to give the localadmin a SecureToken.

Is there a way to ensure that the Prestage LocalAdmin gets a securetoken everytime?

[howie_isaacks]

Do you have a zero-touch workflow in place after enrollment? Something like DEPNotify, or the really awesome Setup Your Mac created by @dan-snelson ? Personally, I like to create the additional admin account using a policy. I want the user to go through the new account creation process after the Mac has enrolled through PreStage. This ensures that they will be granted the secure token, and macOS considers them a volume owner. I also enforce FileVault at enrollment too. Only the actual assigned user is authorized for FileVault. Why would you need for the PreStage local admin to get the secure token? You don't need it for software updates. I have a profile deployed to my Macs that allows non-admin users to run software updates. I'm also using Nudge to prompt for macOS updates. When the non-admin users launch Software Update after being prompted by Nudge, they can run the updates. They can't do major upgrades though since they're not admin users.

[GPS-IT]

An example I can think of, like I said our desktops skip setup assistant account creation, so once the other portion of setup assistant completes you will see the login screen with just the admin account. Our desktops are setup by the technician and they add a standard account manually for the teacher. However, we have a policies that create two additional standard accounts on  all computers the first we call offline user the second student user. What will happen on occasion is the “offline user” account ends up with the secure token. When the tech logs in admin to say do a major OS upgrade ( say Big Sur to Monterey) there is an endless loop of prompting for admin cress and hitting continue. If I elevate offline user to admin, login and assign admin a secure token I can then upgrade normally. 

my thought since writing this post is that if you don’t sign into the local admin prior to the “offline user” account policy completing then offline user gets the secure token. I will test this theory. My skepticism is that on our laptops we do the user account creation during setup and this is an admin account though this “symptom” will sometimes occur on them as well. 

And just as a random piece of info, my limited testing with Sonoma, I have found that any admin account to login will enable ST for that account. 

[GPS-IT]

To expand a bit more, the offline user account is for a substitute teacher, or someone who needs access for a limited time. Almost like a guest account. So it’s never the first account logged into. My reasoning is the policies run in alphabetical order so it’s the first account created. If the pre stage admin doesn’t login prior to that maybe that’s triggering the enable secure token. Student User never gets it. Always offline user 

[tmundy]

I’ve been having the same issue. It’s probably cause I don’t fully understand the process.

[howie_isaacks]

The best approach to learning the process is to start first with the basics. Add new things as you learn. Setup all of the things needed for a PreStage. Always make the MDM profile mandatory so that none of your users with admin rights can remove the profile. With every change you make test, test, test, and then test again to make sure it's working right. Create a really great zero-touch process so that when the users reach the desktop after going through the setup assistant, they will be dazzled as all of their apps get installed automatically while they wait. This is the best Zero Touch solution I have ever seen. I'm working on getting it ready to replace what I have working right now. There's a Slack channel for it too.

Setup Your Mac via Swift Dialog

https://snelson.us/2023/05/setup-your-mac-1-10-0-via-swiftdialog/

[PaulHazelden]

I have found, with some of my Macs, that the Secure Token is issued to the first account to log in after enrollment.
I have an account that is created in my Prestage, this gets the Bootstrap token. I then use during set up a profile to make an admin account, on some Macs this has the Secure token, but on others it does not. On these I simply log in and then recon the Mac and it then has the Secure token sorted out.
I have been experimenting with, as a part of my set up, having an auto login session with the admin account logging in and then out. This does work, but not all of the Macs are happy to auto login, not sure why yet - I suspect a configuration profile. I use JAMF notify to lock out the mac whilst the admin user is logged in. I have an app that gets installed very early in the setup process that has to have its own reboot, I use this to turn off auto login and then the reboot logs the account out.

[howie_isaacks]

At my company we're using an enrollment customization in Settings - Global - Enrollment customization. The settings link to our AD domain. When a user goes through a PreStage or user initiated enrollment, they are prompted to login with their AD username and password. This associates the Mac with the user and fills in the details in the User & Location section of the computer inventory. When this is done through PreStage, it auto-fills the username during the account setup step during the setup assistant. Later on, a single sign-on profile installs that prompts the user to synchronize their Mac local login password with their AD account. This works really well. It enforces our password rules. Most users get demoted to standard accounts during the ZTP process. An admin account gets created during ZTP. This whole process ensures that the actual user of the computer is the FIRST user account that gets created. This solves the secure token issue, and it also means that only the user's account gets authorized for FileVault. If your company uses AD or another compatible IdP, I recommend using the enrollment customization.