SecureToken and sysadminctl in 10.13 (based on 10.13.4)

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

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 🤔