Posted on 06-22-2022 12:27 PM
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
Solved! Go to Solution.
Posted on 08-16-2022 12:31 AM
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
Posted on 06-16-2023 04:59 AM
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....
Posted on 06-16-2023 05:11 AM
it was lindex 5
Posted on 06-16-2023 05:39 AM
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
Posted on 06-16-2023 05:51 AM
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.
Posted on 06-19-2023 05:06 PM
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!
Posted on 12-20-2023 02:40 PM
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?
Posted on 12-22-2023 01:08 AM
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.
Posted on 12-22-2023 10:53 AM
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