Yes, there they are again our beloved Secure Tokens! Well, they actually never went away but after my final wrap up post a while ago, I decided to leave them as they are. Nothing really changed anyway. Most about them have been said anyway.

However, in this post I want to go back to a very specific situation. Imagine the following conditions:

  • You want a local admin on the Mac which is FileVault enabled (and hence has a Secure Token).
  • You want your end users to be Standard Accounts, but also FileVault enabled. Hence again, with Secure Token.
  • You are not demoting your users via any script, but actually skipping account creation via a Jamf Pro prestage – Accounts Settings.
  • You provision your Macs with Standard Account using Jamf Connect Login
  • You are creating the Jamf Management account to fit the purpose of the local admin here above.

As discussed in my previous post, the fact of adding the ‘Accounts Settings’ payload in the prestage, changes the behaviour of the Management Account creation. When you don’t have the Account Settings payload in the prestage, the prestage will honor the ‘Management Account settings’ you define in the User Initiated Enrolment settings of Jamf Pro. If not set to create, it will not create it. If set to hidden, it will hide it.

Note: Hidden account should get UID 80.

However, when we do have the Account Settings payload, things behave a little different. (I was told that this is linked to a requirement from Apple MDM specs, where if the account creation is tweaked by MDM, an MDM provisioned admin account is mandatory… but I’ll leave that discussion for another time). The fact is, with this Account Payload added to the prestage, the following things happen:

  • The management account is created, regardless of potential settings under User Initiated Enrolment settings disabling the ‘Create Management Account’
  • The account does not get UID 80, but UID 501
Note: it does not matter if you skip account creation, or just limit it to Standard or if you are even creating additional admin accounts.... it does not matter. Account Setting Payload configured in the prestage = the behaviour above.

Now, in our scenario above, we create STANDARD accounts by logging into Jamf Connect Login. This means that, in line with Apple’s documentation, this Standard Account DOES NOT get a Secure Token… Why? Well, because of the existance of another local user with a UID above 500 ! Again, for the reasons linked to the prestage above: our Management Account!

Our UID 501 user, being our Jamf Management account, although being an LOCAL ADMIN does NOT get a Secure Token either! Why? Because it’s not the first account interactively signing in into the Mac!

Hence we end up with a system with NO Secure Token Holders. Is that a problem? Yes and No, it depends.

If you don’t care about having a local admin with a Secure Token, hence you don’t care about having a local admin which is FileVault enabled, and you don’t care about potentially needing to manipulate tokens (as in granting other accounts a Secure Token to enable them for FileVault) in the future… all is good! Remember that since macOS 10.14.2 enabling FileVault via any possible method, on a system with NO Secure Token was fixed. It will just grant a token to the user actually enabling FileVault at that moment.

But, in our scenario above, we DO want a local admin with a Secure Token! So how do we fix this situation? Well, I already discussed some options in the past:

  • Provision the Macs with Admin users, manipulate tokens by granting your Management or IT Admin account a token and demote your end user…. Dirty scripting indeed.
  • Make sure you log in with a local admin on the Mac before your Standard account end user logs in (or is created via Jamf Connect)…. bye bye zero touch
  • Make sure you do not enable FileVault, promote your end user to admin, enable FileVault, grant your admin a token, demote your end user… again scripting madness…
  • Whatever other possible option or voodoo script you might find
  • etc.

The good news however is, that Jamf Connect Login actually has a nice little setting which you can enable to avoid all the above: LAPS !

<key>LAPSUser</key>
<string>AdminUser</string>

What does it do?

First of all, as always: the official documentation and reference to this feature can be found here. As you can see, the first section is talking about approving FileVault enablement on devices with macOS 10.15 or above. While this is very valid as more and more of you will be upgrading your Mac environment, this is outside the scope of my post here. The LAPS feature actually works on older macOS versions as well.

That said, yes, what does it do? Well, I could not describe it better than what’s in the official documentation:

"This setting randomizes an already existing local administrator account password, uses the password to enable FileVault and create a personal recovery key, and then cycles the personal recovery key to become the local administrator password. This results in the configured LAPS user account and standard user account being FileVault enabled."

So, ‘an already existing local administrator account’… this can actually be any existing local admin on the Mac, but as discussed above, our scenario and the discribed behaviour of our prestage actually makes or forces us to have the ‘Jamf Management Account’ on the system. So to me it makes sense we just use that. Afterall, this gives our Jamf Management a real usecase, because as you might know it’s actually used for… nothing else (binary of Jamf runs in the root context since many Jamf Pro versions).

How does it work?

That’s actually the good part! It’s so easy! The only thing it needs is the above ‘LAPSUser’ key in the Jamf Connect Login plists… AND (that’s where the gotcha might be) the key to enable FileVault via Jamf Connect: EnableFDE ! It can’t just create tokens without enabling FileVault, hence you need to enable FV via Jamf Connect. Actually a good start to have things nicely secured and FV in place as from the moment the end user starts using the Mac!

    <key>LAPSUser</key>
    <string>jamfadmin</string>
    <key>EnableFDE</key>
    <true/>

Add the above 2 keys to your JCL plists and you’re all set. Deploy a Mac via a prestage enrolment, provision it with Jamf Connect Login, skip account creation and your Standard User, as well as your Jamf Management Account will be tokenized and FileVault enabled! MAGIC !

But wait… we are enabling FileVault via Jamf Connect? So where does our recovery key go? Well, no panic! Although, according to the KB above, you could store it locally, there is a better way. Just enable the escrow functionality for FileVault via a profile, and the key will be nicely send to Jamf upon creation! Actually where it should be for secure safekeeping 🙂

Hereby some screenshots to make this all a bit more visual:

First all, make sure you create the management account in the ‘User-Initiated Enrollment settings’:

A prestage with ‘Account Settings’ payload and skip user creation:

Make sure a config profile is ready and scoped to all devices to enforce FileVault and Escrow the recovery key:

Note: It's axctually only the escrow tickbox you need for this LAPS solution to store the key in Jamf, but you need the 'Require FV2' anyway to avoid end users disabling it.

Configure Jamf Connect Login according to your iDP, and make sure to add the LAPSUser and EnableFDE keys !

IMPORTANT: FOR macOS 10.15 CATALINA OR LATER YOU MUST ALSO DEPLOY THE CONFIG PROFILE DESCRIBED HERE -- to allow enablement of FileVault by Jamf Connect Login

(I'm just testing this with MacOS Mojave as there should not be any difference regarding Secure Tokens in Catalina. I will of course test 10.15 as well and report back later)

DEPLOY YOUR MAC 🙂

Moment of truth! “diskutil apfs listcryptousers /” to see who has tokens !!!

HOORAY! 2 users with tokens… let’s check to be sure!

Our Jamf Connect Login provisioned STANDARD Account:

And our Management Account:

But wait, what about the part saying it cycles the management account password to the recovery key…? Let’s check in Jamf!

Yes, our recovery key is there…

Note: escrowing the personal recovery key might require an additional inventory update to send it to the Jamf Pro inventory.

But is it now really the password of our Management Account? Yes it is:

And just to confirm, yes we unlocked admin privileges with our Management Account, while our end user is Standard:

Finally, yes the Mac is encrypting right after being provisioned…

And Jamf Pro also confirms we have 2 FileVault enabled users:

That’s it! As always, if you like this blog hit the like button, tell your friends about it and leave a message down below!

Brgds,

TTG

(PS: If you don’t like it, fine, we live in a free world. Just remember this is a personal blog, and not official documentation of any mentioned company or product. Doing this out of free will: sharing is caring.)

Print Friendly, PDF & Email