Summary: the sysadminctl -secureTokenOn command seems to let me reset any user's password to whatever I want, instead of doing what it should be doing and verifying the user's password while granting them a Secure Token.
So I've been doing some testing after reading rtrouton's post about secure tokens.
I imaged a computer fresh and enrolled it in my JSS via a standard DEP enrollment. The first user created was a local user, and running sysadminctl -secureTokenStatus returned that the user was "ENABLED" for secure token.
I then had JAMF create a local admin user called "test" via policy. Checking the secure token status for this new user returned "DISABLED" as expected.
However, I then ran, as my first user with the secure token, 'syadminctl interactive -secureTokenOn test -password -' and then it prompted me for the first user's password via GUI interface, which I entered, then it prompted me in terminal for the "test" user's password. Instead of typing the password, I just hit the return key. The command finished without error, even though I didn't type in the password! Running the -secureTokenStatus for the "test" user returned "ENABLED" this time.
When I tried to login as the "test" user, the password I had set no longer worked. The account's password had been reset to be blank - I didn't have to enter anything and I could login as the user. I could then go into system prefs and reset the account's password, entering nothing as the "old password" and entering whatever I'd like as the new password. I then was able to enable file vault as this test user, using the new password i created in system prefs, not the original password set when the JAMF policy ran to create the user.
This is very weird and seems like a bug! I can, as a local admin, create a user via script (jamf policy), enable the secure token for that user while resetting its password, then login as that user and change the password to whatever I want, then enable FileVault. This goes against how I understood SecureToken to work.
I tested this further. From the "test" user account, I checked the -secureTokenStatus for the jss_mgmt account that got created during DEP enrollment. It's status was "DISABLED" as well. During enrollment, we have the JSS assign a random password to the jss_mgmt account, so I have no idea what the password was for that account. I then did the 'sysadminctl interactive -secureTokenOn jss_mgmt -password -' and entered nothing for the jss_mgmt account. The command finished successfully, and then I was able to enable filevault for the jss_mgmt user via fdesetup!
On reboot, I saw jss_mgmt, my original user, and the "test" user as login options on the Filevault screen. I clicked on jss_mgmt, entered nothing as the password, and was able to get past FileVault, but it didn't log me into the computer. logging-in as "test" from FileVault, though, let me get all the way into the user's desktop.
I created another test user (test2) via JSS policy with the password "password". I then logged-in to the user account to create the profile. I then logged-out and logged-in as the original user with the SecureToken. Checking secureTokenStatus for test2 returned "DISABLED". I then ran 'sudo sysadminctl -secureTokenOn test2 -password 12345 -adminUser [username] -adminPassword [password]'
This command, even though I specified the wrong password for "test2" complete successfully. I then tried to login again as "test2" and it would not work with the original password. Instead, the password had been changed to 12345.
I've tried this twice now with freshly-installed High Sierra 10.13.3 computers. Anyone know what's going on?
Yeah that does sound similar. It was a surprise when I ran across it while doing some other testing, then tried to reproduce the issue in a number of different ways. That poster said that the user was not able to enable FV because of the password mismatch, but in my situation FV was already enabled, and these test users were all able to be added to the FV login screen successfully with the modified passwords.
SecureToken / Sysadminctl is definitely still really buggy... I have a freshly imaged machine with 10.13.3, had an account with a secure token... after a reboot, it was gone for that user. fortunately, i still have one user with a token, so i used it to re-enabled. But who is to say it would stick