Hi all,

In this post I want to spend some time on a frequently returning discussion about having an additional administrator account on the Mac which has a SecureToken, as well as the challenges to get that.

The TLDR of this post is basically an answer to the following questions:

  • Do I need to have an additional admin which has a SecureToken?
  • Is it a good idea to have an additional admin which has a SecureToken?

My personal opinion on both questions is: NO. Let’s have a closer look to why I do believe you should not have an additional admin with a SecureToken on the Mac, meaning that only your end users should have an account with a SecureToken. At least, this is my opinion at the moment of writing this post, based on how things are now. Let’s have a look.

First of all, a quick recap on which account gets a SecureToken and when. Detailed saga on this can be found in my previous blogpost on that topic.

On macOS Catalina (10.15.4+) only an account created by the end user during the setup assistant automatically gets a SecureToken. When you skip account creation, the next local Admin which authenticates gets a SecureToken, and also, the act of enabling FileVault on a token-less system gives the (local admin or any mobile) account enabling FileVault a SecureToken. Problematic was the situation where a local standard account, created outside of the setup assistant (for instance via Jamf Connect), did not get a token. The fact that such local standard account did not get a token was not the problem in se, but more the fact that macOS Catalina did not allow a token-less local standard account to enable FileVault. See https://travellingtechguy.blog/macos-catalina-10-15-4-bootstrap-changes/. This was the reason why alternative solutions like Jamf Connect with LAPS saw the light, or scripted SecureToken manipulations like the script I created back when we were still on Mojave.

On macOS Big Sur things changed for the better as now also local standard accounts created outside of the setup assistant do get a SecureToken. Not only does this deprecate one of the reasons for solutions like Jamf Connect LAPS, it also made the feature not useable anymore. The standard account created by Jamf Connect now gets a token, which breaks the entire order of things in which the LAPS functionality plays with enabling FileVault and passing SecureTokens. See https://travellingtechguy.blog/filevault-securetoken-and-bootstrap-in-macos-11-0-1-big-sur/

Now, before we move on to the main topic of this post, one more thing. What about Bootstrap? Well, first of all I still have mixed feelings about the usefulness of the functionality as such, but in view of how things work we can summarise that on macOS Catalina only Mobile Accounts and ‘the Managed Administrator’ would be able to get a token via Bootstrap, while on macOS Big Sur, Bootstrap is a bit more generous as it gives any account logging in (after Bootstrap is enabled) a SecureToken. See above links for both macOS Catalina and Big Sur to review the details on this.

Important: Bootstrap only gives an account a SecureToken when that account is logging in via the LoginWindow (after Bootstrap was enabled). Yes, a login though the login window. Important for the rest of the discussion.

I mentioned the ‘Managed Administrator’, which can be set to the same account name as the ‘Jamf Management Account’, or not, but is technically a totally different concept. I plan on dedicating another blogpost on that matter, but the ‘Managed Administrator’ is the additional admin created by MDM during the setup assistant (defined in the Jamf Pro prestage), while the ‘Jamf Management Account’ is the legacy admin account the Jamf Binary needed for some functionality a long long time ago (long before Jamf Pro 10.x). The choice of configuring them as the the same or different account name is another topic, but important to remember is that Bootstrap on macOS Catalina only acted on the ‘Managed Administrator’ and not the ‘Jamf Management Account’ (if those are created as different accounts). I know, other discussion, so back to the topic of this post again. I’m only mentioning this here to be sure we are clear on which account you consider as the additional admin in view of this discussion.

After this ‘short’ review on how things are or were with SecureToken, why is the discussion on giving your additional admin a SecureToken – or not – important?

Well, first of all, I think we all agree on the fact that the most important user, who needs a SecureToken on his/her account, is the end user. With the exception of some lab setups, libraries, classrooms, etc… I guess we all agree that our end user needs to be able to reboot the Mac and unlock FileVault. (One thing I still see popping up frequently is the discussion about the difference between the FileVault Screen and the Login Window, which also plays an important part in the discussion of this post, so allow me to link to another post I made on that topic here: https://travellingtechguy.blog/understanding-the-macos-authentication-flow-with-filevault-and-or-jamf-connect/)

That said, our end user needs a SecureToken, that is obvious, and how we get that user a SecureToken depends on the initial deployment strategy and the summary on SecureToken I quickly reviewed here above. But when do we need an additional admin account with a SecureToken?

In my honest opinion, like I mentioned at the beginning of this post, we don’t. Even more, I think that giving the additional admin account a SecureToken even complicates other things later down the road, and could be even up for discussion in view of security. More on that below. Let’s first have a look at some scenarios and arguments I frequently hear advocating pro giving the additional admin a SecureToken.

The main reason I frequently hear is:

“If my end user has a SecureToken, I need my additional admin to have a token as well, in order to be able to reset the end user password”.

Ok, that is true, if you want to reset the password of a SecureToken holder manually (or scripted), you need an admin account with a SecureToken to do so. If your end user forgot his/her tokenised account password, you won’t be able to change the password (because it’s forgotten right…?!). To change a password you need the previous/current password. If that is unknown, you need to reset the password, and a reset of a tokenised account password can only be done by a tokenised admin.

I’ll come back to resetting passwords via a Jamf Pro policy below, but let’s first think a bit about the possible scenarios in which we would need to reset the end user’s password. And as much as I am getting a bit tired of the word (and the mess we are in for more than a year already…) let’s also take Covid (or maybe even any other future worldwide pandemic…) into account.

First of all, people do forget their passwords from time to time, but when would an additional admin account WITH SecureToken really come in handy? In my opinion, the only the situation where that would be the case would be when the end user forgot his/her password… when coming back from lunch break, after grabbing a coffee, or any moment where the Mac got locked or when the user logged out WITHOUT A REBOOT. Without a reboot, the Mac would be sitting at the Login Window or Lock Screen, but FileVault would still be unlocked. Here you could indeed use a Jamf Pro Policy (! maybe not, see below !), SSH or Remote Desktop to get access to the Mac remotely and reset the password of the end user.

But what are the chances of this happening? Ok, yes, maybe people do forget their password after a lunch break and yes, Mac users are not really known for regularly rebooting or shutting down their Macs (why would they?). And yes, especially, the day after a good party (for those who still remember what that is…) it does happen that people are staring at the login window or lock screen… not remembering their password, while the Mac was not rebooted yet.

But what are you going to do about it? Back in the days where we were all in the office, the end user could walk up to IT and get help… The admin could then login, reboot if needed and unlock FileVault with the tokenised additional admin, and reset the password of the tokenised end user account… all good if we have physical access to the Mac. Even better, if the end user is on the same network, you could indeed also remote into the Mac via SSH or ARD and fix the issue manually.

For situations where SSH or remote access to the Mac is possible this would indeed be an argument pro giving the additional admin account a SecureToken, but again, especially now that so many people are working remotely chances are this is not going to be possible in a lot of situations.

So what about a Jamf Policy, assuming the Mac is connected to the internet and communicating with Jamf Pro? Well, the Jamf Pro policy to reset a local account password does NOT work if the account you want to reset the password for has a SecureToken! As mentioned in the admin guide, you need to disable to token first: https://docs.jamf.com/jamf-pro/administrator-guide/Local_Accounts.html. Even if the Jamf Management account does have a SecureToken, Jamf Pro can not reset the password of another tokenised account! You need to disable the token of the end user account first!

So, the token of the account you want to reset the password for needs to be disabled! Yes, but this is possible via a Jamf Pro Policy with the ‘local account -> disable user for FileVault payload’. For this payload to work, as strange as it may sound, you do not need another admin account or management account with a SecureToken. The policy to disable FileVault for a user, aka disabling the SecureToken, just works fine. Not SecureToken needed.

The reason for this is because ‘fdesetup remove -user’ is used for this policy payload, which does not require a SecureToken.

So if the end user did not reboot and the Mac is communicating with Jamf Pro, you can run a policy to disable the SecureToken of the end user account and then reset the password via a second payload:

If the Mac is on the same network (or possibly on VPN) you could indeed remote into the Mac and fix things manually. No need for an admin account with SecureToken. Not manually, not remotely via a Jamf Policy.

Note:'fdesetup' or some of it's functionality is being deprecated by Apple, so this may not work in future macOS releases, but it still works on macOS Big Sur 11.2.3. Even if this would not work anymore in the future, this would still not be a reason to give an additional admin a SecureToken in my opinion. See the rest of this post.

But what if the end user did a reboot/shut down? This means that FileVault got locked again, and, as we all know, after booting up a FileVaulted Mac, you are presented with the FileVault Screen. Not the login window! Until FileVault is unlocked, there is no way you can remote into the system. Not by any means. You need to authenticate physically on the Mac, and unlock FileVault on the drive. Only then the OS will be fully loaded, network connectivity will be available, Jamf Pro policies can run at the next checkin, etc… If you have physical access to the Mac, you could then indeed use the additional admin account with a SecureToken to unlock FileVault, and reset the password of any other account. But remotely, regardless of the user ‘physically’ being in the office or not? After a reboot of a FileVaulted Mac? Forget it.

I know, time will come where we will all be working in offices again (or not), and getting physical access to a problematic Mac will be possible again (one day…) but this as only reason to argue that we need an additional admin with a SecureToken is not enough in my opinion.

Taking all the above into account:

If one day you need to change the password of your ‘Jamf Management Account’, just change it via a Jamf Pro Policy (if the keychain is in sync, see https://docs.jamf.com/jamf-pro/administrator-guide/Management_Accounts.html), or reset it. But yet again, to reset it you’d need to disable the token first… so to keep things simple, don’t give it a token to start with.

For computers with macOS 10.14 or later, you must disable the management account SecureToken to reset the password.

If you need to reset the password of a tokenised end user account and you have remote access to it, you could disable the token (Jamf Pro Policy or ‘fdesetup remove -user endUserAccount’) and reset the password…

But… going for this strategy requires you to enable the SecureToken for the end user again, and preferably before a reboot happens or the end user will be locked out of the Mac (even if you have just gone through all the hassle of resetting the password…).

Wondering if you are still with me here, and if you agree with all the above or not, but this finally brings me to what, in my opinion, we should be doing if ever a user forgets his/her local account password:

Give the end user the Personal Recovery Key ! Tell them to reboot if needed!

Indeed, you will need to make sure that the PRK is correctly escrowed in your MDM server, and ensure that you can cycle it when needed, without passing credentials of an admin account in a script etc… but that should be no problem at all if the correct things are in place to do so: https://travellingtechguy.blog/escrowing-and-re-issuing-filevault-personal-recovery-keys/

Note: cycling existing recovery keys with a Jamf Pro policy works if there is a valid PRK in the inventory of the Mac, or if not, when the 'Jamf Management Account' has a SecureToken. Oh, would this then be a reason pro giving our management account a token? In my opinion NO. You should always have a valid PRK for each Mac in the Jamf Pro inventory, so whenever you need the cycle it the Jamf Pro policy should work. The problem is that, at the moment of writing this post, there is a bug in macOS Big Sur, which does not allow to cycle the PRK by using the current valid PRK...

<checked, still present in macOS Big Sur 11.2.3>.

So, this means that the Jamf Pro policy to re-issue a PRK is broken at the moment....if the 'Jamf Management Account' does not have a SecureToken... AH, so now there is a reason to give it a token?! NO, in my opinion, you should not base your workflows on a bug or product issue, this needs to be fixed in macOS Big Sur, and if you do need to cycle the recovery keys on your Macs there are a couple of very good scripts to do so like: https://github.com/homebysix/jss-filevault-reissue.

Once the bug in macOS Big Sur is fixed, the 'Disk Encryption -> re-issue recovery key' in a Jamf Pro policy should work just fine... without a management account with SecureToken...

None of the above, in this again way too long blogpost, gave us any solid argument pro giving an additional admin a SecureToken right? Let me know if I missed something in the comments below, but in my opinion the Personal Recovery Key is the way to go!

Now, let’s spice that discussion up a bit further by bringing security into the mix. As solution to reset a password of a tokenised account, there are scripts in the community which are passing the credentials of an admin account with SecureToken. I think we all agree on the fact that passing credentials in a script is not best practise at all, but it’s true, I also have a script on my Github to ‘manage SecureToken’ in which I also pass credentials. However, in my defence, that script was written back then because SecureToken was a bit of a mess (let’s be honest), and many MacAdmins were struggling with navigating between expected behaviour and bugs/product issues in both macOS and Jamf Pro. It many cases there were only 2 options. Wipe all affected Macs, or script your way out of it.

Today, I believe that this script, as well as many other similar scripts available in the community, are still valuable as very last resort solution to fix some FileVault issues, or at least, to make it easier. Avoiding the need to wipe a few hundreds Macs in some deployments. However, if we look at the security aspect of passing admin credentials, or even ANY credentials for that matter… in a script, I think a lot of security experts will wave a big red flag.

Even solutions like salted, encoded or hashed password passed via variables, are nothing more than a way of creating a fake feeling of a more security. At some point all ingredients of a script come together on the Mac and with some (more advanced) skills those can be retrieved one way or the other.

In view of fixing SecureToken issues, passing credentials into a script may be your only option if you really want to avoid wiping a few Macs, but passing credentials in a script, just to reset another account password does not buy you out of the security concerns. If your management account has a SecureToken and you need to reset the password, disable the token, and if your end user needs to reset his/her password: give him/her the Personal Recovery Key.

One more thing, giving your additional admin a SecureToken will also cause it to show up at the FileVault screen after every reboot (even if you hide it from Users and Groups in System Preferences). Maybe something you also want to avoid.

Long story short, it is my personal believe that you don’t need an additional admin account with a SecureToken, you should not pass credentials in a script, and you should just put your trust in using the Personal Recovery Key whenever a password is forgotten or unknown, or when you need to get access to the data of a FileVaulted Mac when a user left the company.

(Oh, and if you ever need to create another account on a Mac which also needs a SecureToken… there is Bootstrap.)

Let me know what you think, especially if I missed something.

That’s it! As always, if you liked the post, hit the like button, tell your friends about it and leave a comment down below!