A secure journey with tokens

About managing FileVault and Secure Tokens on macOS Mojave 10.14.1

Print Friendly, PDF & Email
Update 06/12/18: After reading this, have a look at my new post regarding Mojave 10.14.2

macOS Mojave and Secure Tokens…? If you have been managing Macs since High Sierra and Mojave came around, you must have heard about “Secure Tokens” before 🙂

Most likely you have already hit your head multiple times against the wall while trying to fix your FileVault workflows. Well, to be honest, join the club as I still find the whole Secure Token story very confusing. Depending the deployment and environment, the journey through managing FileVault and Secure Tokens might be straight forward and hassle free, or a big nightmare inducing experience.

I’ve been reading so many articles and tech blogs about the matter and each time I tell myself  “Yes, now I completely know how it works”… followed by some hands on in different scenario’s proving me otherwise again!

Amongst the articles I’ve been reading, as well as advice I got from certain people, there are sources I would never, not in a 100 years, dare to question. Nevertheless, I’ve seen Secure Tokens behave in a very confusing  and inconsistent ways. At least that’s how I experienced it, because there might be things I’ve been overlooking or maybe the fact that “Apple just changed things in the last update”…

Hence I decided to go through another journey of experimenting with Secure Tokens, in order to validate my assumptions on how it actually works… So, this is another ultimate attempt to understand how the bloody Secure Token system works. Let’s set some hypotheses first, when should secure tokens be created?

  • First of all, macOS creates Secure tokens even when FileVault is not enabled
  • Only the FIRST user on the system gets a Secure Token
  • On 10.14 this first user needs to be a local administrator
  • Mobile accounts only get a secure token when another tokenised user exists on the Mac.
  • Binding to AD through MDM (in a Jamf Prestage) and binding via Jamf Policy @Enrollment Complete triggers different behaviours regarding “the first user on the system” – UNCONFIRMED (see end of post)
  • Authenticating to the ‘Security and Privacy’ pane in system preferences, with an administrator account, and enabling FileVault provides the authenticating account with a Secure Token if no tokenised account exists
  • Creating a user via the Users & Groups pref pane will add a token to the newly created user when the user used to authenticate to the User & Groups pref pane already has a secure token.

NOTE: The following statements and conclusions are only based on my own tests and observations. I’d strongly suggest to test it out yourself before putting anything into production. Also, PLEASE, let me know if you find anything which is inaccurate or wrong, as well as other experiences you had in your test/production environment.

Following tests are performed with:

– Jamf Pro 10.8
– macOS 10.14.1
– MacBook Air (MacBookAir7,1)

I did not use any Virtual Machines as VM’s are not reliable for testing FileVault related deployments and I noticed inconsistent behaviour with macOS not honouring the “Standard” user limitation in the prestage when using VM’s. Instead I used “tmutil snapshot” at the setup screen on a physical test device to revert back when testing different deployments. One additional note on this however: when a Secure Token has been granted it persists post reverting back to the snapshot. In that case a full wipe/reinstall of the disk is required to have accurate test results on the next run!

That said, let’s go! First of all, let’s start easy and assume we create an admin account with setup assistant or, in this case totally unnecessary, have the Account Settings payload in Jamf Pro pre-stage set to “Administrator Account”.

During the Automated MDM enrollment process we create our local admin account.
Eh voila! Totally as expected, we have a secure token for our local admin user.

Now let’s do the test with a standard account setting in our pre-stage.

As expected, no Secure Token as in 10.14 we need the first account to be a local administrator.

So, this is already one important thing to remember. If you want to do zero touch deployment, with standard user accounts instead of admin users… no secure token! The standard user will of course not be able to enable FileVault in the System Preferences, but even when you’d try to enforce FileVault with a configuration profile, the end user would run into the following error message because he/she hasn’t got a secure token:

I’ll come back to this below, but regarding our journey to understand Secure Tokens, so far we’re good:
admin user = secure token, standard user = no secure token.

Let’s now skip the account creation and bind the Mac to AD with a policy and the @ enrollment complete trigger.

After completing the setup assistent, the Mac binds to AD and we are able to login with our non-admin AD user. As expected, no Secure Token.

Let’s do the same but now allow some AD accounts to be Administrator.

Adding the security group with the admin AD users.
First user to log in to the Mac is a member of the AD admin group, but no Secure token either.

Now, let’s change our game by creating an additional administrator account in our Jamf Pro pre-stage, while keeping the account creation on “standard”:

The setup assistant will create the “standard” account and automatically login.

As it’s the “standard” users which is logging in, again expected that there is no secure token.

Ok, no problem, our “Standard account” does not get a Secure Token, we know that by now… so let’s fix it by logging in with the admin account now… no?

Well NO! No secure token for our Admin user! Wait, log out, log in again… nope!

So it’s indeed only when a local administrator logs in FIRST that the creation of a Secure Token get’s triggered! This means that if we restrict the creation of the local account to “Standard” there is NO secure token on the system, even if an administrator logs in afterwards…

Let’s try it with logging in with a mobile account first… Let’s skip the account creation, create an additional admin user and bind the Mac @ enrollment complete again.

As said before, no Secure Token for the Mobile account logging in first…
But also no Secure Token for the additional admin user logging in afterwards!

As said above, a mobile account (standard and/or admin) does not get a Secure Token either, but even if we log in with a local administrator account afterwards… it does not trigger the creation of a Secure Token. So in these scenarios we end up with a system with NO Secure Token… and trying to enable FileVault with a configuration profile will fail (see above).

Other ways of checking if we have users with a Secure Token are ‘sysadminctl’ or ‘dscl’…

‘diskutil apfs listcryptousers / ‘ will list all users with a Secure Token
‘sysadminctl -secureTokenStatus username’ will check the Secure Token for a specific user,
as well as ‘dscl . -read /Users/username AuthenticationAuthority’

or by checking if “Secure Token” appears amongst the user attributes in Directory Utility:

Check the attributes under ‘AuthenticationAuthority’.

To fix the lack of a Secure Token there are multiple options which I’ll come back to at the end of this post, but one solution would be to unlock the FileVault settings in System Preferences with an administrator account and click on “enable FileVault”. Before actually confirming the FileVault Settings a Secure Token is created instantly for the authenticating administrator account.

Now, while we said that a mobile account does not automatically get a Secure Token (valid for both standard as admin mobile account), would we be able to create one via the system preferences if we authenticate with the admin mobile account? Let’s try it!

Redeployed the Mac, first login with the admin mobile account, checked if there is a Secure Token (no, as expected). Authenticate to the Security and Privacy pane of the system preferences, checked the Secure Token again (still no token), clicked on ‘Enable FileVault’…oh a Secure Token!!!

Looking at all the above, this means that if the FIRST account logging into the Mac is a Standard (local or mobile) account, an administrator intervention will be needed to create a Secure Token and enable FileVault…

If however the first account logging in is an Admin mobile user, that user can actually enable FileVault in System Preferences and get a token!

Earlier I mentioned that trying to enforce FileVault (via a configuration profile) to a Mac with only a standard account and no Secure Token results in an error saying “There was a problem enabling FileVault…”. So what happens if we try this with a mobile account (standard/admin) or a local admin which, for any of the above reasons doesn’t have a Secure Token? Well, I tested it and here are the results:

Standard Mobile Account: ‘There was a problem…’
Admin Mobile Account: ‘There was a problem…’
Local Admin Account: ‘There was a problem…’

So this actually re-confirms that we NEED a local admin account to log in FIRST before any other type of user account to avoid problems with enforcing FileVault! No Secure Token = NO remote FileVault enforcement.

Furthermore, I tried with the admin mobile account, ran into the ‘There was a problem issue’, forced a reboot the Mac (because I couldn’t even click on ‘OK’ to get rid of the error screen… ¯\_(ツ)_/¯ ), logged in with the local admin account and logged out again… guess what… macOS did not even re-trigger the “enable FileVault” pop-up. I had to unscope the profile, scope it again to re-trigger the pop-up but ended up with the exact same issue.

Knowing the importance of the local admin who has to log in as first user, we have the option to create an additional admin account in the Jamf Pro prestage and add a manual login with this account into the deployment workflow prior to handing over the Mac to the new user…

Logging in with the additional local admin gives us our precious Secure Token…

We also have the Jamf Management account, in case you haven’t set it to a random password. I would however avoid using the Jamf Management account for anything else than for what it has been intended, being to control the Jamf Binary.

Logging in to the Mac with the Jamf Management account on first login will obviously also provide us with a Secure Token. As expected as it is in fact nothing more than a local admin account.

Now, imagine a user with a Secure Token does exists and the Mac is bound to AD. In this scenario the Mobile accounts logging in will actually trigger a different scenario:

Mobile accounts logging in on a Mac on which a Secure Token has been granted to another user before, will be welcomed by this warning about the need for a Secure Token… still requiring Admin intervention however…

A few additional notes:

As said a user created in the System Preferences, created by another user who has a secure token, will also automatically be granted a Secure Token:

While remotely creating a new user (Jamf Pro) does not grant the user a Secure Token (same goes for user created manually in Terminal):

Finally, in case you have a user with a Secure Token, you can grant another user a Secure Token with ‘sysadminctl’ in Terminal (when logged in with a Secure Token enabled user) and the following command: ‘sysadminctl interactive -secureTokenOn otherusername -password -‘

The dash at the end is to blank the password, which is actually the ‘otherusername’ password. The fact that you need the other user’s password makes this workaround a bit of a pain to use…

One of my hypotheses at the beginning of this post stated that there is a difference between Macs bound to AD via MDM (Jamf Pro Prestage) and binding @Enrollment Complete with a policy. The reason I added this was because I read this statement a while ago on another tech blog, so I wanted to test this as well. This was however reffering to macOS High Sierra... things might have changed.

Unfortunately, I couldn't provision any mobile administrator accounts via the prestage Directory payload, as the "Allow administration by" key is currently not respected in Jamf Pro 10.8 (works fine when binding to AD with a policy). Presumably a product issue, but I have to check and will update this MDM binding hypotheses asap.

That’s all folks! Enough Secure Token for now. Next step would be adding NoMAD/ JamfConnect to the mix, but I’ll leave that for another post.

Please let me know what your findings and experiences with Secure Token are, especially if you have seen different behaviours in certain scenario’s, if I’m missing something or if something I wrote is horribly wrong. As said, all the above is the result of my testing and many many snapshot restores…

If you liked this post, hit the like button, tell your friends about it and leave a comment down below!

Update: 13th of November:

Just for the completeness quickly adding an additional screenshot regarding using fdesetup… as expected, trying to enable fdesetup without secure tokens on the system does change anything…

Apparently, a bug on 10.14.1 as, according the info I got, fdesetup should still be able to grant Secure Tokens while enabling FV. Will test on 10.13 again, and 10.14.2…

Update: 16th of November:

Grtz,

TTG

Oh yeah, one more thing… here is a token of good luck… you’ll need it for your FileVault deployments…

Print Friendly, PDF & Email

One thought on “A secure journey with tokens”

Leave a Reply

Your email address will not be published. Required fields are marked *