Bootstrap Token Escrowed: No & Bootstrap Token is not supported.

[mani2care]

Please find the log bootstrap token
Bootstrap Token Allowed:
Yes
Bootstrap Token Escrowed:
No

post pushing the package and restarted getting still the same issue.

2025-02-26 11:18:40.423133+0100  localhost authorizationhosthelper.x86_64[974]: (Bootstrap Buddy) [com.inetum.Bootstrap-Buddy:BBMechanism] • initWithMechanismRecord
2025-02-26 11:18:40.423157+0100  localhost authorizationhosthelper.x86_64[974]: (Bootstrap Buddy) [com.inetum.Bootstrap-Buddy:Invoke] Starting Bootstrap Buddy:Invoke
2025-02-26 11:18:40.423234+0100  localhost authorizationhosthelper.x86_64[974]: (Bootstrap Buddy) [com.inetum.Bootstrap-Buddy:BBMechanism] Getting Bootstrap Token status…
2025-02-26 11:18:40.553984+0100  localhost authorizationhosthelper.x86_64[974]: (Bootstrap Buddy) [com.inetum.Bootstrap-Buddy:BBMechanism] Bootstrap Token is not supported.
2025-02-26 11:18:40.553991+0100  localhost authorizationhosthelper.x86_64[974]: (Bootstrap Buddy) [com.inetum.Bootstrap-Buddy:BBMechanism] Checking Bootstrap Token validity…
2025-02-26 11:18:51.674625+0100  localhost authorizationhosthelper.x86_64[974]: (Bootstrap Buddy) [com.inetum.Bootstrap-Buddy:BBMechanism] Bootstrap Token is valid.
2025-02-26 11:18:51.674629+0100  localhost authorizationhosthelper.x86_64[974]: (Bootstrap Buddy) [com.inetum.Bootstrap-Buddy:BBMechanism] allowLogin called
2025-02-26 11:18:51.674778+0100  localhost authorizationhosthelper.x86_64[974]: (Bootstrap Buddy) [com.inetum.Bootstrap-Buddy:BBMechanism] Proceeding with login.

[bsojka]

Hi @mani2care!

Could you please run sudo profiles status -vt bootstraptoken on that Mac and provide the output? Also, what device architecture and OS version is that?
Since BT validation was successful, it doesn’t seem to be due to lack of network connection at the login screen, so it might be an MDM server issue 🤷🏻‍♂️.
But just in case, please provide the output of sudo /usr/libexec/mdmclient QueryDeviceInformation | grep EACS as well.

You can also try logout instead of a reboot as it is much less prone to issues.

[mani2care]

Find the results

[colorenz]

There is a PI:

Finally made it to Known Issues: PI101743 - PI-007824: Bootstrap Tokens may fail to automatically be escrowed in Jamf Pro.

And also a fix script here:

https://macadmins.slack.com/archives/C04QVP86E/p1738927099891099?thread_ts=1732056305.860989&cid=C04QVP86E

[mani2care]

Yes I tried it says escrow but the status not yet changed

[mani2care]

looks its unknown issue

[bsojka]

Sorry @mani2care, but I was unable to reproduce that and just as you said, it looks like it may be some kind of anomaly.

Bootstrap Buddy plugin will log Bootstrap Token is not supported. error only if the profiles status command does not return Bootstrap Token supported on server: YES. The screenshot you’ve provided shows such output, so it’s hard to tell what happened exactly.

If you still have an issue with the token, could you please give the latest 1.1.0 version a try?

[mani2care]

I have observed an issue with Bootstrap Token handling in Jamf Pro.

Issue Details:
After re-enrolling a device into Jamf Pro, the following status was displayed in jamf pro page as
Bootstrap Token Allowed: Yes # but this false info from jamf pro
Bootstrap Token Escrowed: Yes

However, this information was incorrect as per the info from device.
To verify, I connected to the user's device and ran the following command:
sudo profiles status -type bootstraptoken
Result:
profiles: Bootstrap Token supported on server: NO
When attempting to renew the token manually:
sudo profiles install -type bootstraptoken
Result:
profiles: Bootstrap Token functionality is not supported on the server.

Why Is that profiles: Bootstrap Token supported on server is No?

Steps Taken to Resolve:
I sent an API command to the user's device to re-issue the Bootstrap Token Allowed status:

echo "Sending Bootstrap Token re-escrow command..."
RESPONSE=$(curl -s -X 'POST'
"${JAMF_URL}/api/v2/mdm/commands"
-H 'accept: application/json'
-H "Authorization: Bearer ${TOKEN}"
-H 'Content-Type: application/json'
-d '{
"clientData": [
{
"managementId": "'"${MANAGEMENT_ID}"'"
}
],
"commandData": {
"commandType": "SETTINGS",
"bootstrapTokenAllowed": true
}
}')
After executing this, I manually escrowed the token or using the Bootstrap buddy for the reissue the new token, and the issue was resolved pos that I can able to see the server status and escrow status from user device.

sudo profiles status -type bootstraptoken
Result:
profiles: Bootstrap Token supported on server: YES
profiles: Bootstrap Token escrowed to server: NO
Escrowing the token manually:
sudo profiles install -type bootstraptoken
Result:
profiles: Bootstrap Token created
profiles: Bootstrap Token escrowing to server...
profiles: Bootstrap Token escrowed

Conclusion & Request:
This issue appears to be a Jamf bug. When a device is re-enrolled, Jamf should validate and send the correct Bootstrap Token Allowed status automatically, rather than requiring manual intervention. Additionally, during re-enrollment, authentication is performed—so the token should be allowed by default.

sure i will try with the new version

[bsojka]

Have you been able to reproduce that more than once for re–enrolled device?
Can you confirm it is limited to re–enrolled computers only, i.e. deleting inventory record and enrolling would avoid the issue?

As it is now much more clear to me what is it you are experiencing, I’ll reopen this issue to remind me to update Troubleshooting Wiki with this one, if the time allows and more testing is done.

[staze]

have had ticket with Jamf about this. can confirm the issue is fixed when you have Jamf push that MDM command saying it supports Bootstrap escrow. We fixed several computers this way that were saying MDM didn't support bootstrap.

it DOES seem to be related to re-enrolling devices, or possibly some issue during initial enrollment. Jamf's typical "you should delete records before re-enrolling" answer isn't really feasible. =/