Ensuring Bootstrap Tokens are Enabled and Functional on macOS 10.15 or above

kyle_erickson
New Contributor III

I'm posting this in case others encountered this issue with bootstrap tokens on macOS 10.15. Particularly, we were running Jamf Pro 10.23.0 but were still seeing our devices show that tokens were not supported on the server.

Checking the status:
sudo profiles status -type bootstraptoken

Results:
profiles: Bootstrap Token supported on server: NO

Our devices met all the requirements, namely:
1. Registered in Apple Business / School Manager
2. Enrolled via pre-stage enrollment.
3. Running macOS 10.15.4 or later.
4. Enrolled after Jamf was upgraded to 10.18.0

The issue was that an undocumented requirement (possibly a bug) is that the pre-stage enrollment must have the following option checked:

Prevent user from enabling Activation Lock

Once changed, we were able to fix existing devices by issuing the Remove MDM Profile command, then on the device enrolling again with the following command:

sudo profiles renew -type enrollment

Once the device re-enrolled the results showed as expected that the tokens were supported, and we were able to manually install the bootstrap token with the following command:

sudo profiles install -type bootstraptoken

Hopefully that helps someone else!

28 REPLIES 28

djdavetrouble
Contributor III

THANKS KYLE, have been chasing my tail for the past 24 hours and was lucky enough to find your wisdom! +1 Beer at JNUC 2022 or whenever on prem conventions resume....

ImAMacGuy
Valued Contributor II

This is great @kyle.erickson ! Thank you.

Is this something we need to do manually for all 10.15.x devices? Will we need to do the the sudo profiles install -type bootstraptoken for new/reprovisioned devices or will it be automagically be done?

jmariani
Contributor

Why isn't the bootstrap token automatically coming down during enrollment if we do have the option checked: Prevent user from enabling Activation Lock?

On an M1 MacBook Air, attempting to enroll to Jamf 10.26 we see the following:

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

To move the bootstrap token to the server side you need to do sudo profiles install -type bootstraptoken

kyle_erickson
New Contributor III

Sorry for the delayed response as I didn't have notifications enabled (my mistake).
@jwojda You might have to unenroll and re-enroll (not scriptable).

I am seeing on newer versions of Jamf (currently 10.26.1) that at least with macOS 11 even devices that aren't part of Apple's Automated Device Enrollment program are getting a token as well.

@jmariani I believe the token is escrowed automatically (possibly after a recon), but you can do the following to trigger it:

#!/usr/bin/env bash
profiles install -type bootstraptoken

You could use an extension attribute to check if it's present:

#!/usr/bin/env bash
export PATH=/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin

# Checks on if the bootstrap token is supported and escrowed by MDM

# Validating minimum OS version for attribute (10.15.0 or later)
OSVersion=$(sw_vers -productVersion)
OSVersionMajor=$(echo $OSVersion | cut -d '.' -f 1)
OSVersionMinor=$(echo $OSVersion | cut -d '.' -f 2)
if [[ $OSVersionMajor -eq 10 ]] && [[ $OSVersionMinor -lt 15 ]]; then
    echo "<result>Collected for macOS 10.15.0 or later</result>"
    exit 0
fi

StatusBootstrapToken=$(profiles status -type bootstraptoken 2>/dev/null)
if [[ -n $StatusBootstrapToken ]]; then
    Supported=$(echo $StatusBootstrapToken | awk '/supported/{print $NF}')
    Escrowed=$(echo $StatusBootstrapToken | awk '/escrowed/{print $NF}')
    if [[ "$Supported" == "YES" ]] && [[ "$Escrowed" == "YES" ]]; then
        Result="Escrowed"
    elif [[ "$Supported" == "YES" ]]; then
        Result="Supported"
    else
        Result="Not Supported"
    fi
fi

echo "<result>$Result</result>"

mlavine
Contributor

Hey @kyle.erickson, thanks for that extension attribute but after implementing it I noticed a little mistake that needed to be fixed. When the profiles command is run in that script it seems to be interpreted as one line which means that AWK sets both of the "Supported" and "Escrowed" variables to the value of whatever the "Escrowed" variable is supposed to be. This means that it is impossible for "Result" to ever return a value of "Supported" when it is supposed to. I updated your extension attribute script below to use grep instead to fix this issue:

#!/usr/bin/env bash
export PATH=/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin

# Checks on if the bootstrap token is supported and escrowed by MDM

# Validating minimum OS version for attribute (10.15.0 or later)
OSVersion=$(sw_vers -productVersion)
OSVersionMajor=$(echo $OSVersion | cut -d '.' -f 1)
OSVersionMinor=$(echo $OSVersion | cut -d '.' -f 2)
if [[ $OSVersionMajor -eq 10 ]] && [[ $OSVersionMinor -lt 15 ]]; then
    echo "<result>Collected for macOS 10.15.0 or later</result>"
    exit 0
fi


StatusBootstrapToken=$(profiles status -type bootstraptoken 2>/dev/null)

if [[ -n $StatusBootstrapToken ]]; then
    Supported='supported on server: YES'
    Escrowed='escrowed to server: YES'
    if [[ "$StatusBootstrapToken" == *"$Supported"* ]] && [[ "$StatusBootstrapToken" == *"$Escrowed"* ]]; then
        Result="Escrowed"
    elif [[ "$StatusBootstrapToken" == *"$Supported"* ]]; then
        Result="Supported"
    else
        Result="Not Supported"
    fi
fi

echo "<result>$Result</result>"

kyle_erickson
New Contributor III

That's interesting and I'll investigate further. When I was testing manually it wasn't showing as single line (as searching for supported returned only one result, escrowed one result, and searching for server returned 2.

I don't have many devices without a secure token anymore as we're using a LAPS account to add one on all devices where missing, but I appreciate the heads up and change, especially if it helps others as well.

ec057b62b4e544c6a5e2e023d262f9f7

kyle_erickson
New Contributor III

Correction, without a bootstrap token anymore. Sigh.

wakco
Contributor III

You may want to check what I have done here.

Is there a specific solution in that thread you found useful? 

I actually posted in that thread, the link is supposed to take you to it, however it seems the page no longer wants to do that.

kacey3
Contributor II

Are there any other suggestions as to why a computer might not escrow its Bootstrap Token at enrollment? We have met all of the conditions listed by the OP, including "Prevent user from enabling Activation Lock" and yet our M1 MacBook Airs are still not showing up in JAMF with a Bootstrap Token in Escrow.

Yes, we can script it to escrow after the fact, but it would be nice if they did it the first time around, instead.

snowfox
Contributor III

I've noticed if I have 'Make the Admin account MDM enabled' ticked in the prestage enrolment, a bootstrap token isn't escrowed until the Admin account logs-in to the machine.  Then suddenly its escrowed.  Not sure if just 'any' account needs to log-in or only the Admin account.  But after device deployment, as long as no account has logged-in yet, the device appears to have no bootstrap token escrowed.  And it appears to stay like that until someone logs in.  Only just started noticing this on a newly deployed lab of Apple Silicon iMacs (via ADE) that have a status of Bootstrap token escrowed = NO.  Yay fun times.

Hmm. Well this current test machine has not been logged in, but I planned to log in as a user created via the "Create Account" policy rather than the admin account created by enrollment. I guess I can check to see if that triggers the escrow.

I expect not, but it definitely defeats the purpose of minimal touch if we have to log in as the admin just to get the bootstrap token into escrow.

kacey3
Contributor II

It looks like logging in as a standard user after deployment does not successfully escrow the bootstrap token.

kyle_erickson
New Contributor III

My understanding is that once a device knows it can escrow the token, it will do so after an existing user with a token signs in.  There is an MDM command that is sent to devices that you can see in the history called "Settings - Bootstrap Token Allowed".  On devices where it is missing, there is also a "Set Activation Lock" MDM command you can send where you can configure it to Disable and prevent Activation Lock.

That said, I can't say for sure if there is any other requirements as we currently are using a script to escrow the token automatically on our devices by using the password of an existing admin account with a secure token.

I ended up having to code a "profiles install -type bootstraptoken" command, which did ultimately, successfully escrow the token, but it seems excessive to have to specifically tell a computer that's been enrolled via DEP to escrow it's token. That should, in my opinion, be assumed when dealing with an MDM solution. I wouldn't be using JAMF if I wanted to touch/log-in to every computer just to ensure that it escrows it's token.

Did you have to do anything special to install the bootstrap token, or just run that command in a policy on machine that didn't have it?

Because it requires admin credentials, and is also a "call and response" command, I used an expect script. The policy does have to receive the admin credentials in some manner. In the basic version, I just used the script parameters within Jamf, but for better security, you could do things like create a temporary admin, use a hidden admin with rotating credentials, or other such options.

 

#! /usr/bin/expect

# Get required variables. Note that in EXPECT scripts, the variable arguments are one value lower (thus $argv 3 is actually $4).
set adminName "[lindex $argv 3]"
set adminPass "[lindex $argv 4]"

#This will create and escrow the bootstraptoken on the Jamf Pro Server

spawn /usr/bin/profiles install -type bootstraptoken

expect "Enter the admin user name:"
send "$adminName\r"
expect "Enter the password for user '$adminName':"
send "$adminPass\r"
expect eof

exit 0

manjunath
New Contributor II

This worked!

My script is long and does several things to validate if a bootstrap token is required, if our administrator account is there, has a secure token, etc., but once that's done to install the token I'm just using this:

echo "[Information] Attempting to add a bootstrap token ..."
profiles install -type bootstraptoken -user $LAPSAccountName -password $LAPSPassword



NPU-Casper
New Contributor III

Thanks for this, we were having issues FileVault encrypting a small population of our Macs and using your instructions helped us get them encrypted! : )

Left
New Contributor

hi friend.
I would like to know how running the command sudo profiles install -type bootstraptoken can prevent the user from participating in it.
Can it be done through a script?

New2ThisWorld
New Contributor III

It can be done by script but you'll have to send credentials through the script and that is not security wise.
Basically the bootstraptoken is attached to the first login of the equipment, to send to the bootstraptoken to the server side the user who has the bootstraptoken needs to be admin and then run that command to send it to the MDM in order to update remotely.

Hi, thank you very much for your reply friend.
My client needs to use kernel reboot when using security tools. This problem is common on M1 devices.

The registration they use is manual and the jamf pro version is: 10.37.2.
When the M1 device reinstalls the system, registration is performed. I was on jamf pro and found that the bootstraptoken was not hosted on the server. It is the administrator I confirmed.

I would like to push the script to the device via JAMF, but I test the script I found today.
It doesn't actually work. Do you have a similar one?
Sending the credentials through the script allows me to let the customer to evaluate if this works.

New2ThisWorld
New Contributor III

We have JAMF School instead of JAMF Pro, but Pro is way better with a lot more features.

I do not have a script because, as said previously, we do not want credentials hard coded in script that can be easily accessed. Since we have a small number of devices and we have to manually upgrade them to Monterey to fix the MDM upgrade issue we are going to do the bootstraptoken manually aswell. Check the answer from @kacey3 on @snowfox thread, that looks promising !

SFRANCIS004
New Contributor III

We don't use pre-stage enrollment for classroom computers.  Has anyone been successful in getting bootstrap tokens to work via user-initiated enrollment?

Yes, it should work after the device is enrolled and a user with a secure token logs in. We have a workflow right now though to create and grant an administrative user a secure token, and we're using that account with the commands I originally put above to add the bootstrap token. That said, you really need to look at getting your devices into Apple School/Business Manager and using a pre-stage. There are quite a few things that are more challenging without it.