sysadminctl -secureTokenOn broken?

Yep have seen that on a few Macs here randomly. Still trying to narrow it down to a specific build version. I suspect a clean build of 10.13.2 doesn't have the issue but possibly a patched 10.13.1 does?

Got the same exact issue on 10.13.3. This is the error I get when trying to give secureToken from a local admin account that has secureToken to a new local admin account:

sysadminctl[24996:1651628] setSecureTokenAuthorizationEnabled error Error Domain=com.apple.OpenDirectory Code=5000 "Credentials could not be verified, username or password is invalid." UserInfo={NSLocalizedDescription=Credentials could not be verified, username or password is invalid., NSLocalizedFailureReason=Credentials could not be verified, username or password is invalid.}

Are you using the interactive switch ?

sudo sysadminctl interactive -secureTokenStatus username

sudo sysadminctl interactive -secureTokenOn username -password –

they are working for me.

[DELETED - wrong thread]

Did anybody find a fix for this, or at least why it's happening? It just came up in my environment.

To be clear, I ran it as a local admin with SecureToken trying to give SecureToken to a mobile account user, and got that ouput. All passwords are correct.

@tchawaga I'm revisiting SecureToken again. My setup is similar to yours.

I was getting the following error in terminal:
setSecureTokenAuthorizationEnabled error Error Domain=com.apple.OpenDirectory Code=5000 "Credentials could not be verified, username or password is invalid." UserInfo={NSLocalizedDescription=Credentials could not be verified, username or password is invalid., NSLocalizedFailureReason=Credentials could not be verified, username or password is invalid.}

all passwords were correct. I tried it again, but this time doing it in interactive mode. Like so:

sysadminctl interactive -adminUser adminaccount -adminPassword - -secureTokenOn account_with_no_token -password -

This appeared to work for me. Although in the grand scheme of things I don't feel like I'm getting any closer to having an automated workflow for DEP that assigns SecureTokens to accounts - unless I create an account with the Setup Assistant initially.

We use AD managed mobile accounts and FV is enabled for all devices.

@ewinterbourne Unless Apple clarifies secureToken with some documentation it's kind of difficult to create a truly zero-touch/automated workflow when you're bound to AD. Our org creates a local account in PreStage and skips user creation in Setup Assistant. The first user to login is this local admin (which gets secureToken), then any AD user that logs in for the first time gets prompted with the enable secureToken dialog window (which requires the admin to supply the password).

Most of the time an admin has to physically be present to enter the password, but we have a LAPS script set to change it on a regular basis, so that mitigates the occasional situation where a remote user has to setup their Mac without IT present.

Thanks for the clarification @sshort and for sharing your method. I used to automate the creation of a local admin account (using CreateUserPkg), which I had been using for a quickadd enrolled workflow. I started to see the secure token issue earlier in the year after it was introduced and only when I had started testing it on a new MBP with apfs format. This made me change the workflow so that our tech was creating the account in the setup assistant. It's only now that I am revisiting this as I am also looking into LAPS to replace the admin account created at the setup assistant. Instead, like you, I am creating the LAPS account via the prestage payloads. I'm still playing around with this new workflow. I'm not quite there yet, but it is promising that you have got it to work.

I use a similar method as @sshort which works reliably well but take it a step further. When our local admin account is created during prestige and a laptop is detected the first policy to run will enable FileVault at next login and reboot the machine. This way we are ensured our local account is the first one to have FV enabled (since it is the only one on the machine) and in turn gets a secure token.
Once the machine reboots a launch agents resumes our DEP setup (or user initiated enrollment process) from where it left off and the machine finishes its configuration, gets bound to AD, and other users can log in and get added to FV.
Also looking a at more LAPS like methodology to rotate the local user account password for better security but so far so good.
Unfortunately due to other internal requirements we need to be remain bound so this workflow sort of keeps things in check,