Using Sysadminctl On MacOS
Aracely Oubre
Administer system user accounts. sysadminctl can be used to change user passwords, create new users (including automatically provisioning the user home folder) or to check the status of a user's SecureToken.
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.
Both sysadminctl and System Preferences prevent the deletion of the last administrator or secure token-enabled user on a Mac. If the creation of additional local users is scripted using sysadminctl, for those users to be enabled for secure token, current secure token-enabled administrator credentials are required to be supplied either using the interactive option or directly with the -adminUser and -adminPassword flags.
Grant SecureToken to the user User64 (must be run on the local machine using the GUI to authenticate)
This will allow the account to login after a reboot on a FileVaulted Mac:
$ sudo sysadminctl interactive -secureTokenOn user64 -password newpassword
Suppose that your MDM solution supports bootstrap tokens. In macOS 10.15.4 or later, when a user who is secure token enabled logs in for the first time, a bootstrap token is generated and escrowed to MDM. A bootstrap token can also be generated and escrowed to MDM using the profiles command-line tool, if needed.
In macOS 11 or later, the bootstrap token may also be used for more than just granting secure token to user accounts. On a Mac computer with Apple silicon, the bootstrap token, if available, can be used to authorize the installation of both kernel extensions and software updates when managed using MDM. The bootstrap token is also used to silently authorize an Erase All Content and Settings command when triggered through MDM on macOS 12.0.1 or later.
This isn't really helpful post-deployment, but this is what I have planned for my deployment:
I'm using a script to activate FileVault as my admin user (with EncryptedStrings for the password) which so far has reliably given the admin user the SecureToken as long it is run before a user signs in (my DEP process has the Account Settings configured to skip account creation, just creates the management account and my admin user). So i'm taking over the login window for a few seconds before they sign in.
The admin account created by JAMF on first boot during DEP enrollment in MDM is not created with securetoken. Because no account has a token, you can't add a token. This catch22 should not be possible, which is Apple's fault, and the account made by JAMF should have a token which I want to say is JAMF's fault, unless Apple is once again not giving sauce to the product they indicate we should be using.... Either way, until this is fixed all our new hardware is half bricked, has service limits, and can't dual boot. Or, we ditch JAMF and do entirely manual deployments to get full operation. Lose lose.
The sysadminctl command doesn't output proper return codes. So even if the command fails with the standard "Operation is not permitted without secure token unlock.", the exit code is still 0 and always is 0 which is bad. (At least in 10.13)
3. I install a custom .pkg app using Systems Manager that doesn't create a user account, it just places a script (that will later create the account) in the file location that matches the file path of the login item in the profile you previously pushed
It is not entirely simple or straight forward. A quick search reveals this post which using the "sysadminctl" command, but you still need to perform other steps. Most instructions use an older method of using "dscl", but this involves dozens of steps (one post mentioned issues in Monterey). In the linked post, read some of the later comments as it mentions one or two other steps which may be needed when using "sysadminctl". Don't just blindly enter any of the commands...make sure you understand them and what they are doing (this includes being careful about the scripts offered in other posts).
A similar tool to useradd is /usr/sbin/sysadminctl on macOS . There isn't a manual but /usr/sbin/sysadminctl -h is explanatory. You should be aware that the command and options will be stored in your shell's history. Note the last line of the help output so that the user password is not stored in your shell's history.
Just migrated to a new 2018 MacBook Pro, and somehow my original account (an admin user) was created without a secure token during the migration. I even tried creating a new admin user, logging into that user and trying to run sysadminctl -secureTokenOn justin -password - but getting:
2018-07-30 14:31:05.262 sysadminctl[998:49031] setSecureTokenAuthorizationEnabled error Error Domain=com.apple.OpenDirectory Code=5101 "Authentication server refused operation because the current credentials are not authorized for the requested operation." UserInfo=NSLocalizedDescription=Authentication server refused operation because the current credentials are not authorized for the requested operation., NSLocalizedFailureReason=Authentication server refused operation because the current credentials are not authorized for the requested operation.
Accordingly, System Preferences complained "Some users are not able to unlock the disk" but clicking "Enable Users" did nothing, sysadminctl -secureTokenStatus jrc (my main user) said "DISABLED", and sysadminctl -secureTokenOn ... was useless.
A clue came from the fact that fdesetup list -extended reported a "Unknown User" entry. So I solved the problem by creating a new user, changing the UUID of that user to that of the unknown user, and using that new user to fix up my existing user. This required a trip to recovery mode (or single user mode) as the Directory Services store is protected by System Integrity Protection (SIP).
with administrator privileges is the same as using sudo.
SO one or the other
The advantage of with administrator privileges is you can use any username/password combo that is in the sudoers file.
Let's say I have a password abc!!!!123 for an admin account with a ST (Secure Token) that I need to pass thru sysadminctl to grant another admin account a ST. I already have the abc!!!!123 in a variable: $ST_admin_Pass. Here's the statement in my sh script:
None of this has been documented in the man page for fdesetup or in the usage for sysadminctl. But hopefully this is helpful to you if you rely on either of these 2 command line tools and are still working out your deployment strategy for 10.13.
If you run sysadminctl -secureTokenStatus firstuseraccount and see a secure token is enabled for that first account but run sysadminctl -secureTokenStatus seconduseraccount and see a secure token is not enabled for that second account, you can try adding a secure token to the second account, so it can turn on FileVault or become a FileVault-enabled account.
Try logging out of the second account and logging into the first account, and then running this command: sudo sysadminctl -secureTokenOn seconduseraccount -password - -adminUser firstuseraccount -adminPassword -
The problem with using fdesetup to add an additional user to FileVault is, the account does not show the securetoken as enabled. Instead you should really should use diskutil apfs listCryptoUsers / or sudo fdesetup list -extended to get a proper list of enabled CryptoUsers. I am just pointing out that we are still having non consistent results when checking the FV2 status of a user when using sysadminctl.
In OSX 10.10+ use "sysadminctl" instead of "dscl"
blog.the-mac-trainer.com sysadminctl: our new friend The Mac TrainerWhile Mac OS X grew out of NetInfo into Opendirectory with bringing the not so obvious dscl-Commands, Yosemite got even more improvements with a new User-Management-Command: sysadminctl. The command creates a user, sets home directory, updates a passw...
This is killing me: Users that i created using Terminal commands don't allow their passwords to be changed in the System Settings. The "change password" button is not greyed out, but after filling in the old and new passwords I get an error message "Your system administrator does not allow you to change the password".
User accounts that are created using the GUI don't have this problem. The exact commands I am using to create the accounts are:
I tried using a Profile (.mobileconfig) to hopefully overwrite this somehow but it didn't work.
Then I found the "pwpolicy" command and was hopeful that this was the source of my headache, but apparently not. I was able to get a pop-up at first login to change password but when I enter a new password the input mask just mocks me with its "error-WIGGLE" x'( I also set "canModifyPasswordforSelf=1" (I THOUGHT THIS WAS IT), but nada. It doesn't work. The man page also shows many of the commands to be DEPRECATED. Setting the pwpoliy User to "isAdmin=1" also doesn't work.
In 10.13 FileVault authentication for FileVault encrypted volumes requires a user to have a secure token. This Secure Token should be added to the first Admin account created during the Setup Assistant which unfortunately was the account I was using. I remembered reading an Article by Rich Trouton on his derflounder blog about this new system for FileVault authentication.
Using the sysadminctl command I checked whether the securetoken was applied to my setup assistant created Admin account.
One solution would be to simply enable File Vault as the local admin, before you hand the Mac over to the user. But they would still probably want the ability to make changes to encryption, or add other authorized users. Plus they are probably going to want to, you know... decrypt their Macs and log in. So youre going to have to give them Secure Token. And here's where we introduce the new sysadminctl command.
0aad45d008