UPDATE 13th of May 2018: 

I investigated the issue with Jamf Pro creating the management account when enrolling devices with DEP.

It seems that, both in my test Jamf Cloud instance, as in a fresh on-prem Jamf Pro server, the DEP pre-stage does not honour the setting of "NOT creating the management account".

When doing User Initiated enrolment, you can define the "create management account" setting. If I choose not to create the management account, enrolling devices via UIE honours it. However, the UIE settings are required in order to create a DEP pre-stage, but it seems that the Jamf Pro pre-stage enrolment creates the management account regardless of the UIE setting. I will investigate further to see if this is a PI or not.

(Only when adding the "account" payload however. It also does not seem to honour the "hidden account" option, and creates is as UID 501 instead of 80... while DEP pre-stage without the account payload does honour the hidden management account setting from UIE. Without that payload in the pre-stage, the pre-stage honours the UIE settings and does indeed not create the management account. This situation is out of the discussion however, as the end user will end up with a normal admin account... and a Secure Token :-) )

This means that, as discussed below, there will be a 501 user on the machine while the end user is creating his/her account in the Setup Assistant. Hence, according to Apple's document, causing standard accounts NOT to get a secure token at their first login. This, I do confirm.

Now, because Jamf Pro creates the management account anyway during DEP enrolments, I had to do a little trick to get rid of it before the end user finishes the Setup Assistant.

For this I created an "@ enrolment complete" policy to delete the management, which has just been created. In order to avoid finishing the Setup Assistant, triggering the Secure Token grant (or not), I stopped progressing in the Setup Assistant and let the mac sit at the "choose your look" screen. This until the @ enrolment policy to delete the management account executed (check in the Jamf Pro policy logs). Once that was done, I clicked continue and ended up at the desktop.

At the very end of the Setup Assistant, macOS seems to check if there is another +500 UID user, and decides whether or not the Standard account should be granted a Secure Token.

GOOD NEWS! With this little trickery to get rid of the Management account before the end of the Setup Assistant, I was able to get my STANDARD account a secure token at initial deployment! See below for further discussion.

For many months macadmins have been struggling to understand how Secure Tokens work. During those months, I have been testing all possible scenarios, trying to share my findings, conclusions and workarounds. Have a look here to find my previous post on the matter, because even with Apple’s official documentation you might end up in situations where you’ll either need to change your deployment strategy or create a fix.

But finally, with some delay, Apple recently released an official guide for FileVault Secure Tokens. This made me think that we would finally be able to wrap up the saga of figuring out how those things actually work. Or at least, how they are supposed to work…

With full motivation to validate how I have been experiencing them, I dived into the official guide, and to be honest, compared to the total lack of any documentation until now, it’s decent. Nicely explaining the existence of Secure Tokens (No, we have not been dreaming! They officially exists now!), as well as how they are designed to work.

But! Yes, there is a “but”, or a “one more thing” so to say, because there is one sentence in the document stating: “Some MDM solutions may use agent tools to create additional users before a device exits Setup. This behaviour varies depending on configuration”. So, what’s that all about? Let’s have a look!

DISCLAIMER: some of my statements below might trigger the impression that I'm saying "Apple is wrong". Well, they designed the Secure Tokens, so who am I to challenge them. However, I do like to challenge official documentation, whoever wrote it! Especially if the way I'm experiencing things trigger me to do so. Everything you'll read below is only based on my own testing, and might be specific to deploying macs with Jamf Pro ~ see comment above about "This behaviour varies depending on configuration".It all depends how the device is initially configured, which account get's created, and which account signs in at the very first interactive login on the machine.

That said, let’s dive into the matter. In all my previous Secure Token discussions my statement has always been:

You only automatically get a Secure Token at initial deployment, if the very first account signing in is a LOCAL ADMIN account. If the first ever login is done with a local standard account, or a Mobile Account (AD bind), the account does not get a Secure Token.

This has been my experience for all my Jamf Pro deployments so far, but let’s see how this stands against Apple’s official documentation now!

This is what Apple’s document says:

When a user sets up a Mac on their own, they use Setup Assistant to create the initial local administrator account. If the Mac is enrolled in an MDM solution, the initial account may not be a local administrator account but rather a local standard user account. In both of these scenarios, the user is granted a SecureToken when they log in to the Mac if the user is the only user with a user ID greater than or equal to the value 500. This is true in most cases, however, because some MDM solutions may use agent tools to create additional users before a device exits Setup This behaviour varies depending on configuration.

If local user account creation in the macOS Setup Assistant is skipped using MDM and a directory service with mobile accounts is used instead, the directory user won’t be granted SecureToken when logging in to the Mac.

In the first paragraph they claim that BOTH a local ADMIN as a local STANDARD account SHOULD get a Secure Token, if they are the first account logging in, BUT only if there is no other account on the mac with a UID greater than 500.

Aha! That’s new to me, because I have never seen a STANDARD accounts getting Secure Tokens at the very first login at initial deployment… so what’s the secret ingredient here? Yes, the “no other account with UID greater than 500…”. Hmmm, yes, that’s it! With Jamf Pro you can create “a management account” at enrolment, and yes, this account gets UID 501.

A quick note about the Jamf Pro Management account... what is it exactly? Well, it's a local ADMIN account, and it's used for... NOTHING! Well, kind of... see below.

Yes, don't panic if this statement is new to you, because it took me some time to realise that as well.

The "Jamf Pro Management Account" is just a local admin account which is used by Jamf Remote, the screen sharing and remote management tool in the Jamf Pro apps suite. Having the management account on the enrolled macs is handy if you are using a "randomly generated password" for this account, unique on each enrolled mac. This password is stored in the Jamf Pro database, and Jamf Remote uses it to SSH into the machine.

Apart from that, the Jamf Binary or MDM enrolment does not need the "management account" at all. Everything Jamf Pro does with policies is executed by ROOT.

That said, back to Secure Tokens. So, if Jamf Pro creates this “management account” during DEP enrolments, you end up with a local admin with UID 501, before the user creates his/her account at the Setup Assistent.

Apple says “if the user is the only user with a user ID greater than or equal to the value 500” the user created during the setup assistant gets a secure token. Well, first of all, in my opinion this statement is either not entirely accurate or not complete.

In ALL my tests, having the management account created by Jamf Pro at enrolment, DID NOT block my LOCAL ADMIN created during the setup assistant from getting a Secure Token. So even with the 501 user created by Jamf Pro, the end user setting up the mac, creating a local admin and automatically logging in at the end of the setup assistant… gets a Secure Token!

The presence of an account with UID greater than 500, in my opinion, only plays a role when the end user is limited to create a STANDARD account (Jamf Pro -> Pre-stage Enrolment settings -> Accounts Settings).

Unless I'm missing something, the statement should be something like (my edit in italic):

"The first local admin account interactively logging in, or the first standard account if this standard user is the only user with a user ID greater than or equal to the value 500", is granted a Secure Token.

or maybe it's coming back to that one sentence saying "This behaviour varies depending on configuration", and the behaviour I see is very specific to deploying macs with Jamf Pro.

I’m really confident about my statement about the local admin account, as this has been the behaviour I’ve seen in ALL my deployments, and I haven’t been able to create another situation. This with and without creating a management account with Jamf Pro.

Now, what about that Standard Account. Well, as said I’ve haven’t seen a single STANDARD account with a Secure Token post initial setup, and I’m very positive about the fact that I have tried with and without creating the management account. But, as we should never take things for granted, we have to test, test and test again.

So I verified my Jamf Pro settings (even for DEP you define the Management Account under “User Initiated Enrollment”), and WAIT… what??? “Create the Management Account” is … DISABLED. Ok, but wait, I just enrolled a Mac and it had a management account… let’s check the mac again… positive… the management account is there, nicely created with UID 501… Ok, wipe the mac, re-enrol, check again… yep, the management account get’s created even while the creation is disabled in Jamf Pro…

This obviously confirms Apple’s statement about “Standard Accounts not getting a Secure Token if there is an 501 user on the machine”, but I really want to check if I can reproduce their statement on getting a Secure Token for my initial Standard Account if there is no +500 UID user on the mac…

I cycled the setting in Jamf Pro, saving in between (maybe a database glitch), but to no avail, it keeps creating the Management Account… Confused… maybe I found a PI, I have to check, but yeah, I can’t test the Standard Account for now as I can’t get rid of creating the management account.

As I can’t check the JamfCloud Database tables to check the value for this setting on my own, I was going to spin up an on-prem Jamf Pro Server during the weekend… but I didn’t have the latest installer at hand and Jamf Nation is in maintenance till Monday…

I’ll check what’s going on with my Jamf Cloud instance (I might have broken things over time by changing settings for testing over and over again), and spin up an on-prem server if needed to confirm the issue with disabling the creation of the management account.

UPDATE: as said in the update statement at the beginning of this post, I can now confirm that Jamf Pro seems to create the management account during DEP, regardless of the setting in UIE.

This caused all my previous tests with STANDARD account (restricted in the DEP pre-stage) not to get a Secure Token...

But, as said in my update, I now can confirm that if there is NO other account with UID above 500, the STANDARD account login in, as very first interactive login (or end of Setup Assistant) DOES GET A SECURE TOKEN! HOORAY!

In the mean time, this leaves me with this current summary on Secure Tokens. As said, based on my observations and tests deploying macs with Jamf Pro:

  1. The very first interactive login will create a Secure Token if the user is a local admin. This is NOT mentioned in Apple’s document, as they only talk about “if there is no other account with UID greater than 500 already created”. For me, this is not the case if this first interactive login is done by a Local ADMIN. Even with another 501 user on the Machine, I always get a Secure Token (only for the local admin account logging in of course, not the other account).
  2. STANDARD account does not get a Secure Token at the first interactive login if there is another account with UID above 500. OK – CONFIRMED
  3. STANDARD account SHOULD get a Secure Token at the first interactive login, if there is no other account with UID above 500 ***UPDATE – CONFIRMED – but take the updated discussion about Jamf Pro creating the management account during DEP into account!***
  4. I did not mention anything about mobile accounts in this post yet, but in case you are still binding your macs, the statements in Apple’s document about mobile accounts are in line with my observations. “If local user account creation in the macOS Setup Assistant is skipped using MDM and a directory service with mobile accounts is used instead, the directory user won’t be granted SecureToken when logging in to the Mac.” OK -CONFIRMED
  5. One more thing, not mentioned in Apple’s document either, but based on my observations, if you skip user creation during DEP, but you create an additional local admin (or management account) during enrolment, this account DOES get a Secure Token if this account is the very first account logging into the mac. (They do kind of mention it under “When a Mac is provisioned by an organization”, but it’s not exactly the same situation.

Now that we know that Jamf Pro seems to create the management account during DEP (expected behaviour or PI... to be confirmed), we know that restricting the end user to a STANDARD account in the Jamf Pro pre-stage, will end up having NO Secure Tokens on the machine at initial deployment. But, more good news is that we actually don't care! Since 10.14.2 you don't need a Secure Token holder on the machine to enable FileVault via a Profile or a Policy. Just enforcing FileVault on a machine with NO Secure Token holder works!

That’s it! After all I’m happy to see that most of the behaviours I’ve been observing and sharing in the past months have been confirmed by Apple’s official document. This taking my comments about the local admin above into account, as well as the scenario with the standard account (an no management account) which I have to test again.

I’ll try to see if we can get my tweaks to the statement about the local admin confirmed by Apple… I’ll keep you posted!

NOTE: Just adding one more thing for those who are testing Secure Tokens deployments on a physical mac using local snapshots (tmutil snapshot)... dont't! 

If you create a local snapshot (at the first Setup Assistent Welcome screen), deploy the mac, test/check Secure Tokens and restore the snapshot... any Secure Token holder created AFTER you made the local snapshot WILL SURVIVE the snapshot.

After restoring the snapshot, you will end up with a 'ghost user' WITH SECURE TOKEN... a non existing user account will be listed with UUID in 'disktutil apfs listcryptousers /' and this will impact or influence the creation / manipulation of Secure Tokens in your next test!

Not granting a Secure Token for the first local admin logging in for instance... as another 'Ghost Secure Token holder' already exists!

I will update this post again whenever I get more info regarding Jamf Pro and the creation of the management account during DEP. In my opinion, it should honour the User Initiated Enrolment settings, as there is no other place where you can define that DEP should not create the management account… I’ll keep your posted.

If you have any thoughts, comments, observations to share, please leave a comment below! Please do challenge me if anything I wrote goes agains your observations! I’m definitely interested to check the details and deployment workflow with you, and maybe, if the stars align, we’ll be able to finally land our Secure Token journey!