Automatic Secure Token from Enrollment

dcappelle
New Contributor III

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

1 ACCEPTED SOLUTION

I can even share one of the prototype scripts that is up and running in our dev environment and working good so far, please keep in mind that i am not used to expect so the script is still rather noobish. Not sure about sharing the other Versions of the script since this Prototype is the only one that only I worked on and i would not share versions from my Colleges without asking them before.

First of all this script is scoped to every computer that enrols  trough an PreStage Enrollment that is creating one Admin account but is skipping the Account creation in the Setup.
The policy itself is using the Enrollment Complete Trigger, since the first Trigger that every Computer enrolled into Jamf via PreStage will send is this one at the moment it is reaching the login screen.
And so far no User was able to physically login in a few seconds after reaching this screen. If one however would be fast than the script.... well in that case i think he deserves the Token 😱

This script is at  no point elegant or even especially good designed it is just there to get the job done.
We are using the fact that on MacOS the expect language is already installed, if in the future this is changing you may need to consider installing expect in the PreStage Enrollment.
In this one we did not even considered the chance that a bootstraptoken is already installed, so please see it as a Basis to work on. Beside that we will also share some of our Experience on the Community Page of the Berlin Mac Admins: https://berlinmacadmins.github.io/ in the near feature. Alongside the script.

 

#!/usr/bin/expect
#argument number in expect is JAMFArgumentnumber-1
#getting credentials from arguments
set admin [lindex $argv 3]
set pass [lindex $argv 4]

#starting login process
spawn login $admin
#waiting for password question and entering password
expect "Password:"
send -- "$pass\r"
#waiting since logout without a short wait did not worked as i tought.
sleep 1
expect "\r"
# creating and escrowing the bootstraptoken
send --"sudo profiles install -type bootstraptoken"
expect "Password:"
send -- "$pass\r"
expect "Enter the admin user name:"
send -- "$admin\r"
expect "Enter the password for user '$admin':"
send -- "$pass\r"
expect "Bootstrap Token escrowed"
#login out of terminal
send -- "logout\r"
exit

 

View solution in original post

47 REPLIES 47

it is in our case running without any secure token user, and getting it for the login. so i am not sure why it will not run in your envoirement for now. is it the lindex 3 or lindex 4 that is creating a problem? lindex 3 would be pattern problem in admin account and lindex 4 in the password....
I tried the old one from here and the new one and both were still fully functional in our envoirement without any pattern error....

anelson11
New Contributor II

it was lindex 5

there should not be a lindex 5 in the script since lindex 3 is param 4 in jamf and lindex 4 ist param 5 in jamf.
This problem is resulting from the fact that expect is counting the parameters from 0 and shell from 1

what i mean with this is that the lines:

set admin [lindex $argv 3]
set pass [lindex $argv 4]

will not be changed. you will have to enter the admin account in the param 4 in jamf and the password in param 5 in jamf.

anelson11
New Contributor II

Hi All!!

I wanted to share a quick fix for this issue. Seems that escrowing the bootstrap token also grants the admin a secure token. use this: profiles install -type bootstraptoken -user "user" -password "password"

Put your credentials in the quotes. 

Hope this helps my fellow admins!

Keith__Myers
New Contributor III

I had something like @Ismere's script running for a while. We were able to initiate a wipe command, and since a bootstrap token was escrowed, it performed an Erase all Content and Settings nicely, then automatically re-enrolled itself and it was ready for a student to sit down and log on with their Azure credentials via Jamf Connect.

 

Now that we have implemented LAPS,  when the computer enrolls, the script to escrow the bootstrap token fails because the admin credentials aren't known. Then if the computer is wiped, it will not re-enroll because the OS was completely erased. I can't even manually escrow the token because when I initiate sudo profiles install -type bootstraptoken I get "profiles: Error returned = -69581". The admin account that I am connected with DOES have a Secure Token.

 

Is there no longer a way to fully automate this workflow without an admin logging onto the computer before any non-admin accounts? Have we reverted back to a time when a technician needs to sit down in front of each computer to wipe/enroll them?

--- Keith Myers

We have not implemented LAPS yet but there is a solution. JAMF offers an API Endpoint for getting the current LAPS Password. You have to get it from there before entering the expect part for the login.

I will update my script after the holidays.

Keith__Myers
New Contributor III

Thank you. I wrote and tested a script to do that last night, and it works as far as passing the credentials to the expect script. I still receive the "profiles: Error returned = -69581" error. The issue doesn't appear to be the script to escrow the bootstraptoken entirely.

 

I get this error when manually running profiles install -type bootstraptoken as well. My client doesn't wipe and re-enroll these often, so I'm not sure how long it has been broken. This is the first one since the LAPS implementation, and the first one since the jss 10.x to 11.x upgrade.

 

I wiped this iMac and started from scratch with a Sonoma install disk and it still ends up in this condition. I'm going to test with a non-production machine. Maybe it's just this computer. 🤞

 

Jamf Pro 11.1.3 on-prem / macOS 14.1. Unable to update the OS due to missing bootstraptoken. 

 

profiles status -type bootstraptoken
  profiles: Bootstrap Token supported on server: YES
  profiles: Bootstrap Token escrowed to server: NO

profiles install -type bootstraptoken
  Enter the admin user name:admin
  Enter the password for user 'admin':
  profiles: Error returned = -69581

sysadminctl -secureTokenStatus admin
  [redacted] Secure token is ENABLED for user admin

 

 


 

--- Keith Myers