Confused about Secure Token (High Sierra)

I was just watching his presentation on it FV2, at the attached link's he starts to talk about Secure Token and when it's created vs not.

What is your configuration going to look like when it's all done? You have the account you created with Setup Assistant that should be FV enabled and then do users log into lab computers with AD accounts or do they use local accounts that you create for them?

@dnelson2813 , for these particular lab computers we aren't going to be turning on FileVault so it's not that big of a deal right now. But we're planning on using this same process for provisioning non-lab computers, and those would have FileVault turned on (we use the FV Helper script). Users on those computers would login with AD accounts, so the FV Helper would pop up after they'd logged in saying the computer needed to encrypt and then log the user out and have them login to start the encryption.

@jwojda thanks, I will take a look at that to see if it has any information that I misunderstood or missed.

I had this issue a couple of days ago and couldn't get around it. I logged in with the FV enabled account and tried to enable all of the AD accounts on the machine to unlock the computer through the System Preferences pane, but the OS didn't respond to any of my clicks. I couldn't even turn FV off with the account that it was enabled on because the "Turn Off" button in the pane didn't respond either.

@dnelson2813 that's what I'm afraid is going to happen if I can't figure this out. It's also annoying because I set up a new computer for myself about 2 months ago and turned on FileVault, and the first account that I'd created through Setup Assistant did (and still does) have a secure token, and I used it to turn on tokens for other accounts.

It seems like it should work as rtrouton says, but it's buggy? And it would be a pain to have to run the command on EVERY account on the computer to make sure it has the token. We have FV turned on for laptops that our faculty use, but they're not shared. They each get their own laptop. So the setup assistant account always has the token but no one else needs to unlock the computer. None of our lab computers or shared laptops have FV on, but none of the shared ones really have data saved to them either so we don't need to encrypt them.

@el2493 do you have any jamf policies running that change/reset the original admin user password created in Setup Assistant? I ran into a similar issue earlier this week, I just joined an org that uses a LAPS script in a policy that changes the local admin account pw. Saw weird issues where secureToken was "stripped" from the user after previously shown as enabled for secureToken. A breakdown of the 2 scenarios is on my GitHub: https://github.com/ducksrfr/LAPSforMac

Example error I was getting when attempting to enable FileVault:

@sshort I've actually been working on this over a few computers, so to give a rundown:

Computer 1: There actually was a policy that created the admin account. We're switching over from Jamf Imaging-based deployment to a provisioning method based on a tech running a policy from Self Service, and in the Jamf Imaging deployments we did have a policy/PKG that created the admin account on Enrollment. With our new process rather than having the policy create the account we're just creating the account through Setup Assistant. I hadn't turned off the policy so I assumed that's probably what broke the token connection.

Computer 2: Turned off the policy to create the admin account, and in one of the policies triggered by a Self Service policy it was supposed to hide the admin account that was created by Setup Assistant and then use the account to give a secure token to our Jamf management account. I noticed that it was failing (saying something to the extent that the provided credentials couldn't add tokens), and thought that maybe by hiding the admin account it may have affected the token.

Computer 3: #ed out the command to hide the admin account before attempting to grant token. I also meant to run the sysadminctl -secureTokenStatus [account name I just created] command as soon as I had logged into the computer, but forgot to do it until I'd installed the CA certificate from Jamf (I hadn't yet installed the MDM profile). By that point it gave the message that the token was disabled.

Computer 4: Checked token status as soon as I logged into the computer after Setup Assistant, it gave the message that token was DISABLED. So it's definitely not a Jamf issue since it's happening prior to enrollment (we don't use DEP).

@el2493 Ah ok, yeah hiding the admin account will def cause issues with secureToken. I'm relatively new to jamf, and just came from an org that used Meraki Systems Manager. That system had no support for user account creation in a PreStage type environment, so we always made the first admin in Setup Assistant, without issues. Any reason you're using 10.13.4 and not 10.13.6? There could be some undocumented bug fixes with secureToken that would resolve the problem.

It's also worth testing FileVault enrollment using a configuration profile vs a script/policy now that profiles support escrowing the recovery key. There were definitely some changes in how FileVault works with APFS/High Sierra that may not be accounted for in the script you linked to earlier, which shows an "last update" in 2015. You mentioned a lab, so I realize they might all be spinning disks in iMacs (and so still on HFS+, in which case you can ignore this suggestion).

@sshort , yeah, they're all spinning disks and HFS+. Using 10.13.4 just because that's what was on the computers when we got them, I don't think that upgrading OS would then give a token to an account that doesn't currently have an account, but I guess it doesn't hurt to try. And you're right about the FileVault/Jamf needing to change with High Sierra (Escrow instead of Key Redirection), but the FV Helper script/policy still works correctly with High Sierra in terms of just prompting a user to turn it on and then turn it on. We do also use Configuration Profiles to Redirect Key or Escrow.

We hide the original account that was created with Setup Assistant as well so that would definitely explain it.

The flow that I'd like to have is that the Setup Assistant account grants a secure token to the Jamf management account before hiding the Setup Assistant account. Then potentially the Jamf management account could grant a secure token back to the hidden account. But since the Setup Assistant account doesn't have any token (without having done anything Jamf-related, it just shows DISABLED as soon as I've logged into the OS), I'm hitting that wall. I know for a fact that hidden accounts CAN have secure tokens (on my personal computer multiple hidden accounts do), though I understand that having a token and THEN hiding an account could potentially cause issues.

Just to make sure I'm not fundamentally misunderstanding something, will the -secureTokenStatus command only show ENABLED if the account has a token and FileVault is also enabled, or would it show ENABLED as long as the account was created by Setup Assistant (even if FileVault isn't yet enabled)? Even if both have to be true, I still had an issue where after enabling FileVault (though not waiting for it to finish encrypting) it still said that the account I'd used to enable it was DISABLED.