Secure Token

[GPS-IT]

We are having an issue with Secure Tokens.

JAMF creates an admin account by default, which is created before setup assistant and almost always the fist account we log into. From my understanding, the fist logged in account is the one that gets the secure token. However, in many case (not always) a generic standard account we push through policy is the one that gets the token. This causes issues with running updates and changing passwords. I am able to resolve it through a series of terminal commands but wondering what is causing in the first place. I originally thought it was an issue with Catalina but am still seeing it currently with Ventura. 

 

  

[ajanicke]

Bit of a necro but I'm noticing this too with our Ventura M1 fleet. TL;DR we have an admin account at startup and then at enrollment have another hidden admin account for when our stuff goes in for repairs. So we have Admin1 and Admin2

Admin1 is created at PreStage as and admin. Admin2 is created at enrollment and then is granted the token, problem is no one else after that gets the token.

Much like you we log into our Admin1 account 9/10 times to make sure things are running as intended.

Policies are shot off in alphabetical order at their trigger point, login, enrollment, startup etc.., so I have the Admin2 account named 01-Admin2 so when the user logs in the first thing it does is create the Admin2 account. What I can see now is that Admin1 gets the secure token then the rest of the users now get the secure token as well. 

I'm still testing this but if you never got to a conclusion this might be it.

[kacey3]

We are seeing a similar situation in which we deploy computers to our labs and classrooms with a generic standard account that is used to auto-login to the computer. So while we have as many as three admin accounts (all created by prestage or policy), it is the auto-login account that receives the secure token since is the first account to actually log in.

I don't believe there is any way to force the secure token to be applied to one of our other accounts first. I am definitely looking for a solution to this because I'm not about to go manually logging in to every computer before applying the auto-login account just to assure that our admin account is the secure token holder.

I do wish that the account creation policy had a check-mark as to whether the account should receive the secure token or not. I don't know if this is a limitation from Apple or an oversight by Jamf.

[ajanicke]

So I've slightly delved into this for our student carts since we don't want them updating. Not letting the students have a secure token is a pretty sure fire way if they find any way around restrictions.

What I've found is the pre-stage admin account does NOT get a token unless you physically sign into the account on the device. Simply SSH'ing into the device does not count.

However if you create another admin account with a policy at enrollment that admin account WILL get the secure token but none of the other accounts will get a token. Take this with a grain of salt as the admin account we create here is a hidden account under /private/var/{user}

You can't force an account to get a secure token, as far as I'm aware, but a simple script can prompt the user for their password, run the sysadminctl command to grant a token from a token holder to a non-token holder and that will give them the token, making them a volume owner, and allowing them to update.

Insane that we have to go through all of this when you look at windows and we can just push updates to devices with no user interaction.

[kacey3]

This has not been our experience. We have been creating our "local admin" account with a policy triggered at enrollment, and it still isn't getting the Secure Token... unless of course, we actually sign in with that local admin account.

Furthermore, since 11.1.1, we aren't even receiving the Secure Token when we sign in with that local admin account that was created by the policy. It is only if we actually create an account locally with system preferences that we get an account with the secure token. I have a ticket in with Jamf for this glitch, since I can't imagine this is intended, and is affecting literally all of our deployments.

[sculligan]

We have been testing logging in via an admin account we create in a policy as part of a script to ensure it gets the first secure token and escrows it. We had this working, but after updating it to 11.1.2, this workflow is no longer working. It sounds similar to the issues you report. I've thought about opening a case as well.

[kbreed27]

It sounds like maybe your computers aren't escrowing the bootstrap token from Jamf? 

I think my workflow is a little janky but it does work on Sonoma and Ventura.

My workflow is:

1. Prestage creates an admin account

2. The first policy that runs at enrollment Creates another Admin account and delete's the admin account created by the prestage.

3. The account created by the enrollment policy gets secure token and then I have script that escrows an MDM bootstrap token. Once the bootstrap token is in place, anyone who logs in after that gets a secure token.

For what it's worth, I inherited a really messy Jamf instance that I've been putting bandaids and finding janky fixes for. I lucked into this workflow because my organization has like 200 prestages and I didn't want to update the admin account credentials on all of them. Also my org won't pony up the cash for Jamf Connect so we're still binding to AD.

Also we're also still on Jamf 11.0.1 so take everything I say with a grain of salt.

@kacey3 can you share how you are auto logging in an account during enrollment?  

[kacey3]

It was in fact determined that there was a quirk in 11.2 that changed how the secure token was deployed, restricting it to the first account to officially log into the computer ... unless that account was created by a Jamf Policy. 
After much testing with Jamf support, a new checkbox was added to the Account Creation policy to allow for an account created by that payload to actually receive the secure token. Once that was changed, my issue was fully resolved.