macOS and iOS management with a twist of Jamf (less travel, a lot more tech)

Jamf Connect and LAPS (& Secure Tokens)

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 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:

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.

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 than having an Admin account to connect to the Mac via Jamf Remote. Nothing else, because the binary of Jamf actually runs in the root context since many Jamf Pro versions ago. Still Jamf Pro needs to have this ‘managed by account ‘ info in the inventory to be able to ‘manage it’ and send MDM commands and profiles. A legacy thing…

Note: on the other hand, if you do intend to use Jamf Remote, you might want to choose the 'additional admin account' created in the prestage for the LAPS solutions. Otherwise, you'll need to update the Management Account info to match the password with the Recovery Key... not handy.

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!

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.)

Super interested in this! Thanks for the write up! Question: does this reconcile the password if the FV key changes? So for example: if the need is there to rotate the FV key, will Jamf Connect update the management password as well?

Hi kat. Depends. LAPS is one solution to give 1 admin a token apart from the en user getting one too. Bootstrap is another solution which also gives Secure Tokens to mobile accounts. Apart from that you will need to manually intervene or script it.

My dilemma is needing a routine “administrator account” that gets FileVault enabled. Since the recovery key gets recycled as the password, it kinda breaks administering the computers at a company level. I’ve tried to make the next admin account FileVault enabled and that doesn’t ever work.

Well not much you can do, one way or another you will need a script. If you leave the end user creation with JCL at standard, it won’g get a token. In Catalina this is a big problem because that standard account without a token can’t even enable FileVault. Compare to Mojave where it would get a token at FileVault enablement if the system was still tokenless. So with JCL creating a standard account without Laps, you will need a script anyway. If you do use laps all is fine for the standard account, filevault can be enabled, even by JCL immediately, and your admin of choice (can be any admin account) will get a token too. The only thing is, the account needs to exist already. All other, 3rd, 4th,… account will need a script or manual intervention but you will need the password of a token holder. No way around that. However, because the admin which got a token via laps has the password set ti the recovery key, you can fully automate the creation of a second admin and give it a token via the recovery key as password for the already tokenised account… remember that jamf connect enablefde feature can write the recovery key to a specified path via EnableFDERecoveryKeyPath key. Your script can read it there and use it as password to tokenize your 2nd admin… question is… is all this really needed depending how often an admin really needs physical access to a machine… for which it would need a tokenized admin account. In view of what is happening to the world nowadays… with most people working remotely, how often doe you really need a tokenized admin… anyway, the above is possible to script

No worries. Jamf can technically not reset passwords of accounts which have a SecureToken. This because you need an account with a secure token to reset the password of an account with a secure token. As Jamf binary does not use any account to run policies (not even the Jamf Managed account) it is technically impossible. Jamf runs from within a privileged binary. A script will be the only way if laps or bootstrap is not enough to achieve the goal. But the script to read the recovery key stored by jamf connect made me think of some things. Definitely possible, and quite easy. I’ll give it a night sleep and play with it tomorrow. It’s basically nothing more than a 2 line script. 1 to read the plist with the recovery key, a second do use sysadminctl command to pass the token. And the creation of the 3rd account is easy with jamf policy.

Hi kat. If an institution recovery key is deployed prior to enabling FileVault via Jamf Connect, that should work if the end user created via Jamf Connect is an admin. For standard account you still need to enable it via LAPS for which the additional admin password will change. Standard account can not enable FileVault without having a secure token and they don’t get one via Jamf Connect. An institutional recover key will nott help here.

Thanks for explaining that. Very helpful. This process is indeed frustrating. Re: using the script to read the plist and the path to recovery key. I’ve had no luck getting this to work. Seems like for some reason, my deployment doesn’t write the recovery key to the file. I’m banging my head back and forth with this.
Do you think I need to change the workflow with ‘escrowing the recovery key” could this be interfering with the writing of the recovery key to the path?

I’m opening a support case, as well. It’s not writing the key for us, either. We’re hoping to create a local admin account and granting it FV privileges using the account created via the LAPS process. Frustrating this isn’t working. Since opening, have you heard anything?

It’s indeed confirmed as a product issue. The laps process is writing 2x to the file. First time with the key but second run overwrites it with empty file. It should only run fdesetup once, so a product issue.