Skip to main content

I've got a bunch of MBAs that I am upgrading to Big Sur, and then checking that the Bootstrap Token is enabled.  They typically have a user Admin account on which the Secure Token is enabled, or that I can get to the point that it's enabled.  The enabled user Admin account shows on the fdesetup list, as well as the cryptousers list.

However, the enabled Admin account is frequently a user account that will be removed at some point.  So I am also enabling the Secure Token on the system Admin account that's kept on the computer permanently.  Frequently the system Admin account is on the fdesetup list, so it's easy enough to use sudo profiles install -type bootstraptoken to enable the Token on the system Admin account.

I have successfully used the below command on several MBAs when the system Admin account was not on the fdesetup list:

sysadminctl -adminUser user -adminPassword “password” -secureTokenOn "admin account" -password “password”

This usually runs successfully.  Afterwards both Admin accounts are shown on the fdesetup list.  Then I am able to install the Token in the system Admin account.  This way we still have a Token enabled account when the local user changes (at which time we remove the old user account and and a new one).

However, I have encountered one computer (so far), a 2020 MBA (not M1) on Big Sur where the above workflow is failing.  I'm getting a "sysadminctl d2814:22576] Operation is not permitted without secure unlock token" error when I run it within the user Admin account that is Token enabled.

Any ideas/suggestions?

Thanks!

I've seen something similar on several Macs where the Secure Token turned out to be corrupt. In several of those cases the user had reverted back to earlier system settings using Time Machine or Migration Assistant which broke the users Secure Token even though it was listed in sudo fdesetup list
This also caused the user not to be able to change pw using System Preferences -> Users & Groups (for the user itself or other accounts) so if this is also the case with you it's a good indication that the Secure Token is broken. In one case I was able to fix the Secure Token by resetting user password in Terminal.app using 'passwd' when logged in as the user. You can also try to remove the .AppleSetupDone file to get a new admin with a Secure Token which you can the use to re-enable the Secure Token for the user. Last option I have used is to unenroll computer from Jamf and reset all user passwords using Recovery and then re-enroll. So if your users Secure Token is corrupt then basically finding a way to reset the users password should update/fix the Secure Token.

If your admin account is the volume owner (no other secure token users), my understanding is you cannot modify it's password by design. 

Depending if the bootstrap token is escrowed to Jamf, deploy a new account via MDM, then login on the device as that user. You should now have another token holder to complete your workflow. 

Good luck!

If your admin account is the volume owner (no other secure token users), my understanding is you cannot modify it's password by design. 

Depending if the bootstrap token is escrowed to Jamf, deploy a new account via MDM, then login on the device as that user. You should now have another token holder to complete your workflow. 

Good luck!


Thanks very much for the response.

There were two user accounts on the computer when it was upgraded to Big Sur.  The end user (admin) account was the only secure token user after the upgrade.  I needed to make the Jamf admin account a secure token user.

I was able to get around this problem by creating a new admin account while logged into the end user account.  The new (third) admin account was created as a secure token user.  Then, I was able to run the sysadminctl terminal command while logged into the new admin account to turn the SecureTokenOn on the Jamf admin account.

Not sure why this extra step was needed in this case.  But the issue is now resolved.

Reply


Terms & ConditionsCookie settings