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

Can you explain how you do that?!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 argumentsset admin [lindex $argv 3]set pass [lindex $argv 4]#starting login processspawn login $admin#waiting for password question and entering passwordexpect "Password:"send -- "$pass\\r"#waiting since logout without a short wait did not worked as i tought.sleep 1expect "\\r"# creating and escrowing the bootstraptokensend --"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 terminalsend -- "logout\\r"exit

Automatic Secure Token from Enrollment

In our Envoirement it worked just fine. The newer one just incorprates an additional Extension Attribute and 2 Policies to give some more feedback and if , on the first try, the account is not working recreating it.
So it more or less just depends on your use case. If you just want to get a secureToken and Bootstraptoken in one try and collect the non working ones in a group afterwards that is ok.
Because at it is right not the old script does not send any exit beside exit 0 reaching its end.
It was the quick and dirty version but i tought it would already help a lot of people.

Weird...For some reason the policy doesn't want to execute after enrollment or at any check-in. I have the policy set up correctly, I think. I even put "*" in front to make sure it executes first but it skips right over it. Thoughts?

What are the Triggers and the Scope you are using?
Our biggest Problem at the beginning was to Scope to a Group that was not filled when the enrollment complete Trigger happend.
If the Policy is not executing at all there should be no log viewable via Jamf.

So, I have a test area at my office with lots of machines, we have a smart group for them. I basically scoped it to that group and excluded all the other machines except the one I am about to enroll. Triggers are check-in and enrollment. I was checking the policy logs of the machine in question and saw that it isn't executing the policy at all.

Hmmm did you also checked if the Policy is in Scope for the one you are trying it on?
Just go into its Inventory entry and under Management there is a Section for Policies in Scope.
If the Policy is not listed there then your Scope maybe a bit off... Scoping can be tricky from time to time...
But if it is not executing it at all then it normally boils down to Scoping Problems... eventually directly scoping one computer for a pure functionality check is an option at the beginning.

I don't think it is a scoping issue. For every machine I test on, it shows up in policies in scope, just doesn't execute. It's so weird, because it's just a policy with a script. If the policy is in scope, theoretically, that means it's enabled and will be installed at whatever the next trigger is.

One of ours is looking like this, the maintenance Task is to update the inventory.

If it is a script Issue then JAMF would try to execute the Policy and creates a log entry.
paramters for the script is param 4 account and param 5 password

One of ours is looking like this, the maintenance Task is to update the inventory.

If it is a script Issue then JAMF would try to execute the Policy and creates a log entry.
paramters for the script is param 4 account and param 5 password

Does it matter if the script runs "before" or "after"?

One of ours is looking like this, the maintenance Task is to update the inventory.

If it is a script Issue then JAMF would try to execute the Policy and creates a log entry.
paramters for the script is param 4 account and param 5 password

and mine looks exactly the same, inventory update too.

running as before. since the inventory collection should be the last action. normally for newer systems you would like to use the Bootstrap information from Jamf after it is created.

Just to make sure you are using the Script that is published here or the newer one?

At the moment i am using my workbreaks and freetime to finally open up a git about the scripts i created so far and even creating some variations to make them more suitable for more workflows

I am using the one mention in this thread. But that shouldnt matter as the policy isnt even running.

that was just me asking out of curiosity for myself...
beside that. do you have any access to the machine? if so you could check the local jamf log of the testing machine under /var/log/jamf.log
For testing issues triggering a check-in via terminal to view the live feedback is also an option.

I mean that would just grant the admin account secure token, no? I see though that might be the only way to diagnose.

yeah that would grant the admin account a secure token, but the script would run non the less. it will still install the bootstraptoken for this device. But for troubleshooting why JAMF is not even running your Policy logging in and verifying the local log on the machine is more or less the only option as long you do not collect the log via script and send it over to another network storage location.

Ok, it seem that the policy doesn't want to run without a secure token user, because I was able to manually execute the policy. It also failed with exit code 1. Mentioned that "bad pattern: [lindex

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....

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.

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!

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?

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?

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.

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.

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

Sign up

Login with SSO

Login to the community

Login with SSO

Scanning file for viruses.

This file cannot be downloaded