How are you creating the AD account?
By the user logging in....
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.
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.
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.
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.
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....
@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.
Ahhhh yes. You are correct. I’ll play around.
@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.
@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.
oooooh I thought you had to specify a lot of options with it like a password and such.
@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]
So I've tried that where I create an additional account and I've seen the additional account not get a secure token.
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
@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.
@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.
@CasperSally I’ve tried hidden and not hidden.
@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.
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?
@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
Ya filevault is no longer an option to check for us either.
Weird. I'll try checking everything.
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.
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.
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?
