Beating a deadhorse - SecureTokens, Management Accounts, and Filevault

[boberito]

I imagine I'm not alone on this. I set up a 10.13.4 machine with DEP.

In the prestage enrollment, I have it create our admin account(account ID of 501, not a hidden account). Skip the setup user stuff and most the setup assistant.

I thought I figured out how to get a secureToken, that if I logged in as our local management admin account as the first user instead of an AD account(which creates a managed mobile account). It would give the management account the secureToken and no problems and I could then use FileVault on the machine. I swear this was working. And now it isnt....

Has anyone figured out a workaround or solution?

I've thought about when I redo a machine from scratch we could install 10.12, set everything up then upgrade to 10.13. This will work with machines we currently own but not newly purchased. I've also thought about squeezing the last life out of imaging since you can(but shouldn't) image using HFS+.

[MacSysAdmin]

How are you creating the AD account?

[boberito]

By the user logging in....

[andrew_nicholas]

You might want to check out the createmobileaccount tool as it looks like there is CLI support adding tokens at the accounts creation and you may be able to script this out depending on workflow.

/System/Library/CoreServices/ManagedClient.app/Contents/Resources/createmobileaccount -help

In our DEP instance we create an elevated account for use with the machine during DEP setup and then have a policy run 2 days after the machine has been enrolled to remove it. You may be able to leverage this sort of thing so that you can create a simple SS policy that prompts for desired userID and then makes the call with the SecureTokenAccount username/password hard coded. This isn't ideal as a first run of course but if you are touching the machines prior to setup then it may accomplish what you're looking for.

[walt]

We are looking to deploy our service account post-enrollment, so the first local user account should in fact obtains the secure token. We do not bind so that suggestion may not be relevant to you, but is similar where DEP will allow the user to create their account first and any subsequent accounts should receive the token.

[boberito]

So what if no account ends up with a secureToken. Our management account that’s created by Jamf doesn’t get the secureToken. That’s what I’ve noticed has happened. If no account gets a token, then additionally created accounts I believe won’t get a token.

[walt]

My take, Apple seems to imply a 1:1 configuration (1 user for 1 Mac). We started to rethink our process, as it was similar to yours and noticed similar issues.
We have a light DEP process, user's account gets created during the set-up assistant and then once in the user account the rest of our profiles and policies deploy, depending on their scope. Then our management account would get deployed/created.
We first tested this in a "manual" set-up without DEP and it has been working favorably.

[boberito]

Ya so we're totally 1-to-1. But, we don't want to let users create their own account through the setup assistant(we've definitely toyed with the idea). 802.1x isn't the happiest to auto-connect to the wireless when it isn't an AD account. Also there's not really an easy way to enforce passwords or change it easily if they don't remember it.

Hopefully the createmobileaccount does the trick....

[andrew_nicholas]

@boberito Are you creating an additional local account at the time of creation or just the management account and using that for everything localized? My bet is that your management account is being created with the jamf binary call and so it does not have a token granted. The account I was referring to is in additional to our management account, so there may be some Apple logic in there that is successfully granting it a secure token and might be worth a test.

[boberito]

Ahhhh yes. You are correct. I’ll play around.

[boberito]

@andrew.nicholas are you scripting the creation of that elevated account? If so can you share your script? I started playing with that command it doesn't seem as straightforward as I was hoping.

[mm2270]

@boberito For createmobileaccount to work, the Mac must first be joined to your domain (AD). I assume that is in place from early on, and if so, the basic syntax is something like this

/System/Library/CoreServices/ManagedClient.app/Contents/Resources/createmobileaccount -n <accountname>

If you want, you can throw in the password, but it's not strictly necessary if the first login to that account happens while the Mac is connected to your internal network. The password will get cached on first login in that case. Also, the home folder doesn't need to be specified unless there is a reason to. It should get created automatically at login.

[boberito]

oooooh I thought you had to specify a lot of options with it like a password and such.

[andrew_nicholas]

@boberito Not scripting it for this particular account though we do for other. I've included a pic from one of our DEP setups that shows where we create the additional account.

And your createmobileaccount call might look like the following.

/System/Library/CoreServices/ManagedClient.app/Contents/Resources/createmobileaccount -n [ADUSERNAME] -a [SecureTokenAdminName] -U [SecureTokenAdminPassword]

[boberito]

So I've tried that where I create an additional account and I've seen the additional account not get a secure token.

[boberito]

So tried the additional account...didnt work. No secure token granted to it
Tried the createmobileaccount....also no token.

womp womp womp

I think we may just throw fresh autodmg created deploys of 10.13.4 on machines with HFS+ for now

[apizz]

@boberito in my experience testing (we still bind as well) I could not skip the Setup Assistant user creation as part of DEP enrollment and get an AD user to receive the secure token. I know I've read somewhere that theoretically the first user created on an APFS High Sierra machine should receive the secure token, including an AD account, but in my own experience and anecdotally from others this appears to not be the case.

What we've done is not skip the setup assistant account creation as part of DEP and created a user with a simple username and password so we can script transferring this secure token to our local admin account we create as part of enrollment. It appears the only way to script this is to provide the username and password for both the account with a secure token and the account to receive it in the script, which isn't great for security reasons. However, once this is done we delete the user we created as part of DEP and change the password of our local admin account to something secure.

However, at this time we can't actually get this DEP-created user to fully delete without doing it manually.

[CasperSally]

@boberito @aporlebeke we are wiping our drives and installing 10.13.4 (all SSD so should be all APFS) and skipping all steps in set up assistant and have our prestage creating an admin user (NOT hidden) and that admin user appears to get secure token fine.

On slack someone else was trying to hide admin user and was having issues. Not sure if you all have tried not hiding admin user, or if that's an option for you.

[boberito]

@CasperSally I’ve tried hidden and not hidden.

[CasperSally]

@boberito my prestage matches the screenshot that @andrew.nicholas posted above. sorry if that's not helpful. weird it would work for us and not you? I am testing with 10.13.4 though, not with the supplemental update.. was holding off on rebuilding my installer until 10.13.5 was released.. I should probably test with supplemental just in case asap.

[boberito]

This sounds silly but since I've tried that where I create an additional admin account and it doesn't work.

What's checked or unchecked in your Prestage enrollment --> General --> Setup Assistant.

I wonder if that may have something to do with it?

[CasperSally]

@boberito i check everything. jss 10.4 but was working same in 10.2.1. Filevault is no longer an option to check or uncheck in 10.4

[boberito]

Ya filevault is no longer an option to check for us either.

Weird. I'll try checking everything.

[boberito]

Also our JSS is 10.3.1

I haven't heard of any major issues with 10.4. I'll try upgrading today and see if that makes a difference. I don't remember seeing anything in the bug fixes about this but maybe it magically fixes secure token stuff.

[YoshiiZee]

Hmm so our setup is slightly different. Our machines are all through DEP. We have it set to the user being the default account as an Admin and our management account is added behind the scenes. I then have a script in Self Service which grants the management account a SecureToken based on the 501 user. Once granted we have a script to remove admin for everyone but our management account.

This was working for everyone but this morning we noticed a weird "illegal command" error on one machine, flushed it out and attempting to rerun everything.

[omegazero]

We're running into all the same issues mentioned above. An EA I put together has provided an alarming number of devices without secureTokens. Previously we were able to run the sysadminctl -secureTokenOn $user command without passing the interactive mode argument. Now we get an "Operation is not permitted without secure token unlock." error. Does anybody know how the secureToken unlock is actually controlled?

OOC..@YoshiiZee would you mind sharing your script?

[szultzie]

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

[wolftech]

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...

[wolftech]

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).

[apizz]

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?

[wolftech]

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. )

[apizz]

@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 ...