|
### 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. |
This comment has been minimized.
I think this is only true if that user is also the first user to log into the system.