Beating a deadhorse - SecureTokens, Management Accounts, and Filevault

So just a follow up, turns out I hit this PI.

(PI-005185) macOS DEP management account creation variations

"Management account home directory is created in /Users/ and UID is set to 501 (first account created)

If you enable the Account Settings payload none of the accounts created get a secureToken which should be granted to the first account created and is needed for filevault functionality."

So hopefully it gets fixed in the next version of Jamf Pro.

-Peter

I'm running JSS 10.5.0... I've just confirmed that using the "Change Account Password" option under the Management Accounts payload in a JAMF policy will both change the management account's password AND enable the secureToken for that account.

Tested on a couple machines.

Still need a way to deal with our local admin account as "Change Account Password" isn't an option under the Local Accounts payload... still, progress...

huzzah!... and now that the Management account has secureToken, able to write a script that will then turn it on for our local admin account as well... with zero interaction with the user (who already has the token since they're the one who either logged in first or did the upgrade from 10.12).

That's fantastic news! So theoretically, machine gets enrolled, you change the password on the management account to get it the secureToken, and then you create your local user accounts so that they get the secureToken as well?

Hrm... caveats... the computers I'm testing on were upgraded to 10.13 -- but originally were 10.12.6 machines with FV2 enabled (IRK + PRK) which already had local account, local admin, and management account all FV2 enabled.

Beginning tests on new 10.13 machines now. Initial test failed.

Trying to get my new FV2 for 10.13 machines ConfProf setup correctly to mirror my old 10.12 setup. I'm hoping the IRK might be the diff.

But I'm worried that its the fact that the management account was already FV2 enabled -- even though it didn't have the SecureToken and thus was behaving like it wasn't FV2 enabled -- that allowed the change paswd option to work.

(update: Confirmed that the machines where this is working does list all of the users when running sudo fdesetup list -- even though two of them don't have secureToken enabled. )

@wolftech hmmm ... I'm wondering then if the initial efforts regarding the secureToken should be getting it to the management account so that subsequent users created via policy also get it ...