DEP Mojave Macs - No SecureToken created for management account

That’s expected behavior for the management account to not get securetoken because it’s a hidden user. As you mentioned, creating an additional local admin in the PreStage will receive a securetoken.

If the Mac is running 10.14.2, then that additional local account gets securetoken. If you’re on 10.14.1 (or earlier), AND you skip user creation in PreStage, AND it’s the first user to login, you get securetoken.

10.14.2 does not automatically give Secure Token to the additional prestage account either.

You can grant the additional account a token if no user has a token (because the first user logging in was a standard or Mobile account) or use the end user admin account to grant your additional admin account or management account a token. If the end user is admin and logged in as first user it will have a token.

The changes in 10.14.2 compared to .1 are:

• sysadminctl will create tokens for both admin and other account if NO token holder exists (was not possible in 10.14.1)
• policies and profiles will grant token to whatever user is enabling filevault. Did not work in 10.14.1
• fdesetup will do the same (bug in 10.14.1)

For the rest, if a token holder exists, you need it to be ADMIN to be able to further manipulate tokens.

Prestage with account creation set to standard, or skip account creation, and mobile managed (non admin) or standard local account logs in first still gives you the issue that you will NOT be able to manipulate tokens later.

I tested all possible scenarios over and over again:

10.14.2 blog

Script

Apple release notes also only say 10.14.2 allows to enable Filevault for MDM created users... = not created in system preferences.

Which is correct as you can now enable filevault with profile/policy without having a token. The user enabling it at logout or login will get one.

It does not say it gives it a token. But sysadminctl -adminUser adminaccount -adminPassword password -secureToken anyuser -password password will give you both the admin and the other user a token if NO token holder exists.

If there is any user with a token on the machine the adminuser in the command above need to be tokenised. If it’s not an admin and you don’t have an admin with a token it’s still game over

The fact that the management account is hidden doesn’t change anything imo.

I even tested giving the maanagement account a secure token and it even shows up at preBoot! This if you gave it a token before enabling filevault (all token holders get enabled for Fv when you enable Fv afterwards) or after enabling Fv if you run diskutil apfs updatePreboot /

See my notes on the blog.

Anyway, this is all based on my own testing with 10.14.2 by doing different scenarios over and over again with all possible combinations of account types, which account logs in first, profiles and policies etc.

@frederick.abeloos thank you for this!

@sshort You actually made me think about something!

Imagine you do end up with a Mac with only 1 Token holder... a non admin.

This is a problem, as this user can't give a token to your admin account. You can avoid this by logging in with an Admin at first login, or use a script to sort the tokens out before enabling FileVault.

But what if you do end up with FileVault enabled and only a non-admin token holder. I've been saying it's game over...

Well actually not really, sometimes the solution can be soo simple you overlook it!

I just tested it and it works: just promote your end user to admin, use sysadminctl to give your admin account a secure token and demote it again! Does not harm the Secure Token of the promoted/demoted end user.

Problem solved and you can easily script it.

Add the promote/demote the enduser part in the script: Script SecureTokens

So you need secure token to enable secure token... who's responsible for the failure making this chicken and egg situation? Apple or JAMF? If Apple won't let JAMF make a proper first admin account, they need to fix this. If JAMF is missing the code that should be doing it, they really need to fix this. Not being able to have a fully serviceable machine with DEP is a real problem.

@ebonweaver not realy. First of all, Jamf has no impact this, the way Secure Tokens is designed is how it is.

But it’s not really a chicken or egg situation.

In normal workflows you configure a Mac and you become Admin by default. You’ll automatically log in after conpleting the setup assistant. By doing so you are automatically granted a secure token. No problem.

Now, when you do things with DEP and prestages, the situation changes but it all depends which user account is logging in as the very first user.

If the end user is granted admin rights in the prestage... no problem... end user logs in as first user and is granted secure token... no problem.

The problem starts when you are logging in with a non admin (standard) account as very first user, or a mobile account. Because these won’t get a secure token. But this is actually not a problem, because you can just enable filevault eith policy or profile and both will generate a token for the user enabling FV. This was broken in 10.14 and 10.14.1 due to a bug and fixed in 10.14.2. In 10.14.2 or later if nobody has a secure token, enabling FV will generate one... so no problem no chicken no egg.

But when you first login with a local admin (or the management account), and afterwards the end user log in (local standard or mobile account), there is a problem. In this case the admin will have a secure token and the end user will not. This is a big problem because in order to grand the end user a token you need both the admin and the end user password. Hence you need to intervene manually or script something like I did in my script. Asking the end user for the password and fix the secure token issue.

So, ling story short, there is only a real problem when the local admin logs in before the enduser, if the end user is not admin or if the end user is mobile account.

This is actually a reason to say:

1) don’t log in with an admin account before your end user logs in. There is no reason to do that, as you should be able to do everything remotely with policies and profiles. (why would you really need to log in with an admin before the end user????)

2) stop binding your macs to AD, if you don’t really need to... hence no problems with secure tokens, keychain and filevault password sync issues whcih you could cause with mobile accounts

My point of view is that there is actually no chicken or egg situation if you optimise your deployment strategy.

And if you are in a situation where you have secure token issues, script the fix and adjust future deployments to avoid it.

Sorry but your assertions do not match experience. The first account logged in to after setup is the "additional admin" account made by the pre-stage enrollment policy. That account does NOT get a token, and is therefore not able to do anything, and secure boot utility does not work as it claims there are no admin accounts on the system. No users are ever involved at that stage, and that's not part of the issue for us at this point. There in fact is a lot of reasons the admin logs in immediately after enrollment as part of setup in preparation for deployment, because we can not do everything remotely, nor is the machine fully ready for use "out of the box". We also should not have to code work arounds for the product not working properly. If your assertion was correct that the first admin logged in after boot/prestage/config got securetoken, we wouldn't have an issue, but that's not the case.

@ebonweaver I just tested again, although I was 100% sure about my statement.

So I created a new prestage, skipped the account creation, and created an additional admin user. I log in with this user as the very first user ever logging in to the Mac... and it DOES get a secure token..

Can you test again on a clean machine, don't use any previously snapshotted VM's. Secure tokens survive snapshots.

Run: diskutil apfs listcryptousers / and you will get a list of all the UUID's of the users with a secure token...

We have tested many times on many machines fresh out of the box 10.14.3. There are no VMs involved. That command and the sysadminctl command to query users with tokens returns none. It would seem you have already "scripted a fix" that is resolving this issue for you.

:-) no sir, I did not and I would not know why I would do that. I can replicate exactly the same scenario on physical machines.

Clean Mac (VM or Physical) -> Jamf Pro prestage -> DEP -> NO other user logs in -> the additional admin or the Jamf management account logs in as very first users: it gets a token.

If that is not working for you, there must be something your are doing in between the steps above to break it. It's as simple as that. The first LOCAL admin account logging in to a CLEAN Mac gets a secure token.

I did not script any fix to trick you with some screenshots. Only trying to help you identify the real root cause, but it is definitely not the Jamf Pro server or the local admin you are using.

And only if that local admin is really the first user logging in.

I think I may have found the issue. Our enterprise instance is 10.8 which we were told supported Mojave. I'm seeing information that indicates you need 10.9 minimum to actually support Mojave's security features. I've inquired with the enterprise admins when they plan to update, hopefully to 10.10 since I see that's been released now too.

@ebonweaver No, the version of Jamf does not impact anything regarding secure tokens. The only variable playing a role is the first user logging in.

First user ever logging in to the Mac = local admin = gets a secure token
First user ever logging in to the Mac = local standard = no secure token
First user ever logging in to the Mac = mobile account = no secure token

That said, having NO secure token holder at all is NOT a problem. Just enable Filevault with policy or profile, and the user actually enabling it (at logout for profile, at login for policy) WILL get a token. Whatever account type it is.

Jamf Pro version compatibility with Mojave security features, is completely irrelevant. That's for KEXT and PPPC.

It's really as simple as it is: if the first user is a local admin, whether that is the management account created by Jamf, or the additional admin account you create in the prestige, or a local admin account created by the end user in the setup assistant does NOT matter.

MacOS doesn't know anything like "a Management account". There is no such thing. macOS only knows admin or standard. How it was created does NOT matter. Again, if the very first user logging in is a local admin, it gets a token.

The "management account" created by Jamf is only a local admin, nothing special about it, no difference with any other local admin. The only reason Jamf calls it "management accounts" is because, if created by Jamf Pro, Jamf Pro knows the password (encrypted in the Jamf Pro Database). This either "a known password" or a Randomly Generated password (see User Initiated Enrollment Settings in Jamf Pro).

The only purpose of that "Management account" is to use Jamf Remote... as Jamf Pro knows the password, even if randomly generated... it can just remote into the Mac. No other purpose at all, NO impact on Secure Tokens or whatsoever.

Again, I'm sorry to repeat it: it's only the first ever user logging in impacting your Secure Token situation.

Just to be sure, with logging in I mean physically logging in... not remoting in via ssh or so...

"Again, if the very first user logging in is a local admin, it gets a token"

You're obviously very convinced of what you're saying, so there's clearly no way I can convince you it's not true, but I'm sorry to say it's not true. If it was, there would be no problem, and I would not have dozens of machines with no securetoken on the admin account.

@ebonweaver well, I'm only trying to help, and I can only say I'm deploying Jamf on a daily basis. Yes, I'm positive about the following statements:

• I have no reason not to believe you. Just trying to help.
• Jamf Pro on it own does not have any influence on whether the first local admin account logging in, before ANY other user ever logs in, gets a token or not. It just does.
• It does not matter if it's the "management account", the extra DEP Prestage admin account, or the admin account created by the end user during the setup assistant. First user logging in = local admin = token

This taking into account:
- we are talking about macOS 10.14.2 or later
- we are talking about CLEAN macOS deployments, wiped devices going through a clean DEP workflow
- there are no @enrolment triggered policies with scripts or things happening which might break things. I would not immediately know what could break it, but I just be sure, you tested with a prestage, skipping account creation and logging in with the additional account without anything else. Obviously you would be deploying things post enrolment etc... but just to make sure you tested the exact same basic scenario. From there you would be able to isolate potential reasons for trouble

Just too show you I'm not inventing anything, doing some trickery, I hereby give you a screen recording. Yes, it's a VM, but I have no reason to lie about it, it's exactly the same on my physical machine. Just in case... I added the running clock to the screen to show I'm not editing the video. Its a bit slow... it's running on an old virtualised Mac Mini, but yet again, same result on physical device.

VIDEO

Hope you find the reason for the trouble.

Hello everyone, we have fresh out of the box MacMini(s); going throughDEP; going through Pre-Stage; Prestage creates the "management" account, keep in mind it is a hidden account. Our Pre-stage also creates and second account.

We are running 10.14.4 (we re-installed the OS as well from the internet), and we log in to our JAMF management account first thing. It does NOT create a secure token for that user.

There is nothing else out of the ordinary we are doing.
Any thoughts?

Hi brobbins, I did not try with 10.14.4 yet but, which Mac Mini’s are those? The ‘diskutil apfs listcryptousers /‘ command is returning “no cryptousers?

Hallo Frederick, what's happens if you hide the 501 user? does it also create a secure token for this hidden user?

Hi @applesupport I just tested on macOS 10.14.3 (I need to update my vFuse VM for 10.14.4 but I would really be surprised if that would change anything, but I'll test again later).

I have a clean macOS, going through the pre-stage with "skip user creation". The only account being created is the "Management Account", which is set to be hidden in "User Initiated Enrolment" settings in Jamf Pro.

After the setup assistant I can confirm the account is hidden:

I log in with the Management Account and I DO have a Secure Token, while FileVault is NOT yet enabled:

After further testing for me, jamf management account and extra admin account both get disabled but when I set the policy to encrypt, the jamf management account then gets the secure Token.