Skip to content

Instantly share code, notes, and snippets.

Show Gist options
  • Star 10 You must be signed in to star a gist
  • Fork 1 You must be signed in to fork a gist
  • Save zoocoup/268be15bf5164c8359441397659b5abd to your computer and use it in GitHub Desktop.
Save zoocoup/268be15bf5164c8359441397659b5abd to your computer and use it in GitHub Desktop.
### Updated to reflect changes introduced with 10.13.4. Update to 10.13.4 if needed before attempting to make
SecureToken-related changes. ###
sysadminctl is a tool Apple introduced in 10.10 for working with system user accounts. In 10.13, sysadminctl is Apple's
recommended tool for working with user accounts in the CLI, replacing functionality that has long been provided by dscl
and adds new features available only in 10.13. sysadminctl can be used to change user passwords, create new users or
check the status of a new-to-10.13 security feature named SecureToken.
SecureToken is a non-visible APFS file system attribute, unlike the SIP protected flag or file creation date, that triggers
the creation of a new AuthenticationAuthority entry in a user's local account record
(e.g. sudo dscl . -read /Users/[user name] AuthenticationAuthority). SecureToken is not publicly documented by Apple so it is
not possible to provide a full technical description, but in practice one needs only to know if a user has SecureToken or not.
Having SecureToken set signifies that a user can unlock a FileVault-encrypted container on an APFS-formatted volume. Without the
SecureToken bit on a user account, that user will not be able to authenticate at the FileVault pre-OS login screen.
The SecureToken attribute should be automatically granted:
- To the first user created by SetupAssistant on a new machine/fresh OS install
- For a user created by the MDM createuser command for machines enrolled in DEP
- For existing FileVault users on a machine that has been upgraded to 10.13
- To directory users on a properly bound machine
Users created in the GUI via System Preferences > Accounts should be automatically granted SecureToken but users created
via the CLI (dscl, sysadminctl or via policy from the JSS) do not automatically get SecureToken. For all CLI-created users
you need to explicitly grant them SecureToken using an admin account that itself has SecureToken.
On machines with FileVault enabled, it is imperative that any user using the machine have SecureToken set or else they will
not be able to unlock the encrypted drive.
Check a User's SecureToken Status
sudo sysadminctl -secureTokenStatus [user being checked]
_Grant SecureToken to a User v1 (must be done on the machine in a GUI login)_
The admin user running this command must have SecureToken themselves. Granting SecureToken is a chain-of-trust process.
sudo sysadminctl interactive -secureTokenOn [user being granted SecureToken] -password -
When prompted, authenticate as the admin running the command and then provide the user's password.
_Grant SecureToken to a User v2_
sudo sysadminctl -adminUser [admin user] -adminPassword [admin's password] -secureTokenOn [user being granted SecureToken] -password [password of user being granted SecureToken]
or
sudo sysadminctl -adminUser [admin user] -adminPassword - -secureTokenOn [user being granted SecureToken] -password -
This second version will prompt you, at the CLI, to first enter the admin user's password and then the user's password.
@chilcote
Copy link

  • To directory users on a properly bound machine

I think this is only true if that user is also the first user to log into the system.

@chilcote
Copy link

chilcote commented Dec 14, 2017

sudo sysadminctl -secureTokenStatus

this will fail too. Apple wants you to use sysadminctl interactive -secureTokenStatus foo and then auth in the GUI with the admin user like an animal.

@zoocoup
Copy link
Author

zoocoup commented May 17, 2018

n.b. Chilcote's helpful comments above applied to pre-10.13.4 SecureToken. This gist has been rewritten post-10.13.4

@zoocoup
Copy link
Author

zoocoup commented May 18, 2018

Updated again after tip from Mike aka @pudquick, aka @mikeymikey, aka @Frogor Lynn

@peteostro
Copy link

This also seems to effect the security utility (when booting into restore, command r) on Mac's with T2 chip. If an admin account does not have a security token it will not show up in a list of users able to use the Security Utility. Also it seems if an admin account does have a security token and you use the command line to change the password of the admin account it will not allow you to login to the Security Utility (though the account will be listed)

@bvanpeski
Copy link

This was super helpful! Thank you!

@BBGuy
Copy link

BBGuy commented Feb 12, 2019

On my MacBook Pro (13-inch, Mid 2012) none of my users have a secure token. Anything I can do to get one ?

@zoocoup
Copy link
Author

zoocoup commented May 27, 2019

@BBGuy Unfortunately no. If no users have SecureToken there's no one to grant it

@pythoninthegrass
Copy link

Know this is an old post, but I've successfully re-granted a secure token via resetFileVaultpassword under recovery:

As part of the password reset process, the resetFileVaultpassword tool also resyncs the Secure Token attribute for the account. That should allow FileVault to work normally again.

Note: If you have multiple accounts on this Mac, the Reset Password tool requires all accounts’ passwords to be changed.

Thanks for the writeup @zoocoup -- testing our sysadminctl script that runs interactively for some reason 🤔

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment