Automatic Secure Token from Enrollment

dcappelle
New Contributor II

Hey Everyone,

 

I know how secure tokens work, I know how to give them out. I have a particular question about having them automatically enabled without having to log into the account manually on each machine.

 

I have it enabled so that every account can have a secure token, when they login. The issue I'm having, is my Local Administrator account.

I have my management account as JAMFADMIN, and my local administrator is just "administrator". That's the account I use to reimage machines and do maintenance/updates. As we know, M1 machines need to have the account doing updates/OS installs to have a secure token. I have this account being made on Enrollment, so it should get one. The account is on the machine, but if I do a remote command to do an update, the secure token isn't enabled until I physically go to the computer and log into the account. Then it's available.

 

Does anyone know how to make this token appear, without logging in?

If anyone needs any other information, please let me know.

 

Thanks,

Dominic

6 REPLIES 6

Tribruin
Valued Contributor
Valued Contributor

Whenever the topic of Secure Tokens come up, I refer back to Traveling Tech Guy's blog. He has come great blog posts arounds ST. 

This is a longer discussion of whether your local admin should or should not have an ST, but here is an important callout:

Important: Bootstrap only gives an account a SecureToken when that account is logging in via the LoginWindow (after Bootstrap was enabled). Yes, a login though the login window. Important for the rest of the discussion.

Here is the whole article:

Additional admin with SecureToken, or not? - Travelling Tech Guy

I believe you can also grant a secure token using the sysadminctl command. 

sysadminctl -secureTokenOn <user name> -password <password> (interactive || -adminUser <administrator user name> -adminPassword <administrator password>)

But you would need to know the password of an existing ST user (i.e. the first user.) You could prompt the user for their password via a policy in Jamf to grant the token. 

 

dcappelle
New Contributor II

@Tribruin wrote:

But you would need to know the password of an existing ST user (i.e. the first user.) You could prompt the user for their password via a policy in Jamf to grant the token. 

 


That's half the battle. This is after enrollment, when the computer first turns on, so there wouldn't be an account with a password that I know, that has a token. These are shared machines, so there isn't an account being created through setup assistant. I know how to set tokens.

Tribruin
Valued Contributor
Valued Contributor

Can you help me understand your enrollment workflow? You are creating an admin user via PreStage? What about the actual user account? Are you skipping account creation? So, when you get the login page, the only user account is your admin account? Do you then shut the machine off?

 

The admin account created via a PreStage is not granted a Secure Token. As mentioned, to be given a Secure Token, the user must authenticate at the login screen, since there is no other user with a secure token. 

I don't think there is a workflow that will accomplish what you are trying to accomplish (grant a Secure Token without logging on with the Administrator account.) 

dcappelle
New Contributor II

Yeah, that's what I was curious about. I didn't think it was possible, but never hurts to ask.


The admin account gets created via the prestage enrollment. Also on the prestage is my Jamf Connect, so when the computer gets past the automated enrollment, it's immediately ready to log into our Azure services.

mhasman
Valued Contributor

With similar setup, the biggest issue I am facing is service "administrator" account password rotation. Without secure token, there is no possibility /yet/ to change password by Jamf PRO policy 

I HIGHLY recommend Delinea Privilege Manager (formerly Thycotic) for this. We just implemented it and it’s doing our password rotation on our main admin account. The ONLY disadvantage to this is that you must have one admin account that never has a password rotation (so that the account can change other account passwords). This is one we made an incredibly long and complex random password that JAMF deploys as part of pre-stage. The software then automatically rotated the other admin passwords on a scheduled basis.