Admin user created during PreStage Enrollment doesn't have Secure Token enabled

[lisanelson2]

I have run into a problem whereby apparently no users have a Secure Token, and there appear to be operations you can't perform unless you are Secure Token-enabled.

All the documentation says that the admin user created during pre-stage enrollment should get the secure token, but it just flat-out doesn't. Multiple reinstalls, never does.

I have found other people saying that they have the same problem, but that if they use a JAMF policy to create another user (as admin) and check the box to say that it's eligible to receive the secure token, they find that that works. It doesn't for me.

And of course I can't use command line utilities to enable secure token because nobody is enabled.

Secure Token-wise, our machines appear to be basically orphaned.

Anyone have any ideas about how to fix this?

Thanks,
Lisa.

[AJPinto]

The secure token is generated as the account logs in to macOS. For the local admin account to get a secure token, you need to log in with it. Jamf does not use the generate first secure token flag when creating the account in prestage, using that flag actuall prevents other users from getting a secure token so its a good thing they dont use it.

However, if your environment is setup correctly the users should have secure tokens when they log in (this does not need admin access).

[Tribruin]

By default the Admin created by the Prestage enrollment does NOT get a Secure Token. That is by design. I suspect you are reading incorrectly. 

As @AJPinto mention, the first Secure Token is granted to the first account to login to macOS. Typically that is either an account created in a the User setup screen OR a user created at a login screen like Jamf Connect. After that, additional Secure Tokens are granted either from the first user OR when a new user account is logged in to the computer, assuming the computer has a Bootstrap token escrowed in the MDM. 

What is your enrollment and deployment workflow? That might point to why you are having trouble with Secure Tokens. In theory, macOS should always have at least one account with a SecureToken. It is not supposed to allow you to delete the last user with a Secure Token. However, it does happen occasionally and that generally means wiping the computer and starting over. 

[acloseshave]

Not the OP, but you just saved me some headache troubleshooting this on a test device we're working on for the macOS Sequoia Beta. I shouldn't keep forgetting that accounts don't get a secure token until they initiate the login process, but I did!

[lisanelson2]

So as with most things, it turned out to be a bit more complicated than that.

Turns out there *was* one user who had a Secure Token. That was panopto_upload, a service account created during the installation of Panopto. Needless to say, nobody has ever logged in interactively as that user and never will.

When I did a test install without Panopto (so that that user never got created), suddenly, my admin user created during the pre-stage enrollment *did* get a Secure Token – as soon I logged on interactively with it.

I don't understand how the existence of panopto_upload seems to have blocked other users getting secure tokens, but it probably doesn't matter; it just means I have to be very sure not to install Panopto as part of our normal deployment process, but rather wait until it is certain that secure tokens are already working, and only install it after that.

Thanks,
Lisa.