Sysadminctl Command Not Found

[Elia Khensamphanh]

LinkedInand 3rd parties use essential and non-essential cookies to provide, secure, analyze and improve our Services, and to show you relevant ads (including professional and job ads) on and off LinkedIn. Learn more in our Cookie Policy.

I've been wrestling with High Sierra and getting it to play nice with our existing security procedures. I have been especially troubled by a the new Secure Token feature, and I wanted to share what I've learned...

So as you can imagine, users in high security environments, or really ANY lab, classroom or other environment that requires network login is going to have to make some changes. otherwise, your AD users will discover that they can't enable File Vault!

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.

If you've been following along, you are realizing that you had to enter the admin's name and password, AND the user's name & password. So you're going to have to be there with the user, so you can both enter your passwords, kind of like needing two keys to launch the nuke. Unless you want to make the passwords part of the command, but that would leave them in .bash_history in cleartext, and this is such a terrible idea I refuse to tell you how to do it. In other words, no more leaving a new Mac on a user's desk when they're not there.

If you have a huge number of Macs to deploy, or you drop ship them and rely in DEP to set them up, I have some good news: Remember that first bullet point I mentioned up above? The first user on a new Mac has Secure Token. Usually, this would be the local admin you create with Setup Assistant. HOWEVER, if you are utilizing DEP to automatically enroll and bind new Macs, they will already be bound to your AD domain, so the first user who logs in CAN be an AD user, and they WILL get Secure Token. So you have that going for you, which is nice.

As a part of standard security audits, we like to rotate the local admin password we have on our mac computers every so often. This worked well enough a year ago, however I did notice some outlier computers where there was an error saying that the admin password could not be changed due to the Secure Token. When I most recently tried to run the same script that previously worked, not only did it not change the local admin password, it seems to wipe it completely where I can no longer login using either the new or old passwords.

I've tried many different workarounds to try and get the local password to change, including using Jamf's built in Local Account Management policy, and using scripts with the sysadminctl command and have thus far been unsuccessful. Some things I found in my reserach are that there must always be an admin account present on a mac, and one client must always have a SecureToken assigned before login. The most recent workaround I tried is listed below, wherein I created a new local admin account using Local Account Management (admintemp), and then tried to use that admin account to turn off the SecureToken for the administrator before changing the password and re-enabling it.

My plan was to just delete the admintemp account once I was done, but I can't even get the local admin password to change no matter what I do. I also tried to just delete the local admin account and re-create it with the new password I want, but that didn't work either because the account has a secure token.

Finally figured out a solution to this! After many attempts to get the sysadminctl command to work, I had zero success and it would always either wipe the password without changing it, give me the secureToken error, or just hang up and never complete. Using the Files and Processes payload though, I was finally able to rotate our local admin password. To do so, use the below CLI command in the Files and Processes payload.

You cannot rotate the password on a Secure Token holding account with JAMF. When you are creating the "new" local admin account, it does not have a Secure Token. So, Your "new" admin account cannot rotate the "main" admin accounts password as it has a secure token.

You would need to acquire a tool specifically designed for account Maintenance like CyberArk EPM that can use a secure token (providing it is given a token) to rotate passwords. This kind of account maintenance is really outside of JAMFs wheelhouse.

I checked the admintemp account I created via Jamf policy using terminal and confirmed that it also did have a Secure Token applied to it. Can an account with a Secure Token also not modify another account with a Secure Token?

An account with a secure token, can rotate the password of another account with a secure token. However, keep in mind. Anything you do in CLI is in plaintext, so the user name and password can be picked up by lots of network tools and on the device itself.

Once you know what if any users have a secure token, if you know. there password, you could use the commands that you reference abnbove or other scripting solutions to use the account that has a token to grant one to the accounts that do not.

Thank you for this tool. I've gotten to the point where I can get the script I run to "succeed" on the client computer, however it doesn't actually set a new password. The below script doesn't actually set a new password, it just wipes out the existing one without setting a new one.

I'm thinking maybe just remove the reset portion and see if -newPassword alone will set a new password. It's really annoying as right now I'm having to re-image my test station after every attempt since the account keeps getting its password wiped out.

Jamf's purpose is to simplify work by helping organizations manage and secure an Apple experience that end users love and organizations trust. Jamf is the only company in the world that provides a complete management and security solution for an Apple-first environment that is enterprise secure, consumer simple and protects personal privacy. Learn about Jamf.

This site contains User Content submitted by Jamf Nation community members. Jamf does not review User Content submitted by members or other third parties before it is posted. All content on Jamf Nation is for informational purposes only. Information and posts may be out of date when you view them. Jamf is not responsible for, nor assumes any liability for any User Content or other third-party content appearing on Jamf Nation.

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 -

I have recently upgraded one my Macs to Ventura. Normally I create users using the sysadminctl command as I would like to control the UID/GID of some of users I create for file sharing purposes. I have always been able to do this with the below command

This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.

Use a good text editor like VS Code and open your .zshrc file (should be in your home directory. if you don't see it, be sure to right-click in the file folder when opening and choose option to 'show hidden files').

If the error disappears after you type this into the terminal and your terminal functions normally, the above solution will work. If it doesn't, you'll have to find the folder where your reference error is located (the thing not found), and replace the PATH above with the PATH-TO-THAT-FOLDER.

If you like me, you will have two terminals app, one is the default terminal with bash as the default shell and another iTerm 2 with zsh as its shell. To have both commands and zsh in iTerm 2 from bash, you need to do the following:

At this point you will have the zsh as your default shell ONLY for iTerm 2 and you will have bash as the global default shell on default mac terminal app. Next, we are still missing the commands from bash in zsh. So to do this, you need to go on your bash (where you have your commands working) and get the PATH variable from env (use this command to do that: env grep PATH).

(2) If you did make any change, like adding some new PATH, then simply remove exactly that PATH.In my case, I used to have a homebrew path as well, so I deleted it. So, now it looks the same as in the step 4 (1).

I just posted this here so someone might find this helpful. Because it's just start of the line and might be deleted by mistake like I had done. And seems there's no solution after trying several ways.

So in /etc/profile.d I was running a script that made use of the variable path. Because it was in lowercase I never thought it could mess up with the actual variable PATH. Be careful and do not use the variable path on your scripts.

3a8082e126