Well, kind off. Not everything but there are some welcome changes!

!!! ALREADY AN UPDATE to what I wrote here -  see comments !!!
Update 2: 9/12/18 - promote the non-admin Secure Token holder. see comments !!!
IMPORTANT UPDATE 12th of MAY 2019: I would advise reading the post below for overall understanding of my Secure Token overview regarding different deployment strategies, but have a look at my new post regarding Apple's official documentation here!

When I wrote my previous post on Secure Tokens, I mainly focused on enabling FileVault with Configuration Profiles on 10.14.1. The main issue was that if no account on the mac had a Secure Token, the profile would fail to enable FileVault. This due to the fact the first account logging into the Mac has to be a LOCAL Administrator.

This, amongst many other FileVault related issues, caused some concerns for many Mac Sys Admins. Additional bugs on 10.14.1 seemed to make the mayhem complete, leaving many of us in a state wondering if something was expected behaviour, or “a feature”… In all fairness, there were moments where I thought I finally understood how Secure Tokens work, and other moments where I just lost all hope…

Hence my intensive search for a recommended workflow to avoid as much of the issues as possible. I ended up testing almost every scenario with different types of accounts, on both 10.14.1 and 10.14.2.

I had to wait until 10.14.2 came out of beta, but now that 10.14.2 is released, let’s see what this early Filevault Santa bring us!

First of all, let’s list the concerns/issues we all had with FileVault on 10.14.1:

  1. Only logging in with a LOCAL Admin account at the very first login, will generate a Secure Token for this specific account
  2. Local Standard accounts and Mobile Managed/Admin do not automatically generate a Secure Token
  3. Enabling FileVault via a Jamf Pro policy on a Mac with NO Secure Token holder does not work. At login the user gets a popup asking to enable FileVault, but nothing actually happens when clicking ok.
  4. Enabling FileVault via a Jamf Pro configuration profile on a Mac with NO Secure Token holder, fails. At logout, when FileVault enablement is triggered, an error displays saying “There was an error enabling FileVault…”
  5. Creating a Disk Encryption setting in Jamf Pro Settings to enable Filevault for the Management account does not work due to the lack of Secure Token.
  6. Enabling FileVault for the Management account via a Jamf Pro policy payload ‘management account’ does not work due to the lack of Secure Token.
  7. Creating a new local account via a Jamf Pro policy and add it to FileVault via a Jamf Pro policy does not work due to the lack of Secure Token.
  8. Resetting the password of a local account via a Jamf Pro policy does not work if the account has been enabled as FileVault user. You need to disable FV for the user, reset the password and re-enable FV for that user again… but you just lost its Secure Token by disabling FV.
  9. ‘fdesetup’ can’t enable FileVault if there is no Secure Token holder on the Mac.

So, quite a long list of potential recipe ingredients for trouble when managing FileVault. And to be honest, all of them are consequences of the way Apple implemented the Secure Token system. At least most of them, as some issues are just caused by a “feature” in 10.14.1 it seems. This actually caused me to lose track of what was expected behaviour and what not…

Anyway, during my tests with 10.14.2 I noticed some changes. Let’s have a look at the above concerns and see what improvement 10.14.2 brings us.

  • The fact that the first account logging in needs to be a local Admin for macOS to autogenerate a Secure Token remains the same. Standard or Mobile accounts logging in as first user on the Mac still don’t get a Secure Token. Leaving us with a Mac with NO Secure Token holder.
  • However, enforcing FileVault with a Configuration Profile or a Jamf Pro policy actually seems to work noweven on Macs with NO Secure Token holder. Policies actually enable FileVault at login (compared to 10.14.1. where the popup would actually be there without doing anything) and Configuration Profiles correctly trigger FileVault enablement without any error.

HOORAY! Thank you Apple, let’s hope this is an intended change and not just another ‘feature’. If this actually is intended, this is a very welcome change, as it does not matter what type of account logs in first. You will always be able to enable FileVault remotely, even without a Secure Token holder on the machine.

So, all is good right? Well not everything… let’s have a look at the other concerns I listed above.

  • The Jamf Management Account does not get a Secure Token. This remains the same. Except, like in 10.14.1, when you use the Management Account to log into the Mac at first login. Something I would try to avoid however. *** Leave the Management Account for what it’s intented, managing the Jamf binary. – CORRECTION – Following one of the replies below – Jamf runs indeed everything as root, and we only use the management acount for Jamf Remote. But if you want to be able to cycle the management account password with the build in payload in policies, I would not tokenise it. If you would like to use the Management account as FileVault user (preBoot), you’ll have to. Doing so you’ll have to use sysadmctl to cycle the password (see below) and ‘edit the Management Account information’ via the inventory search action button if you want to use Jamf Remote.
  • Use the Management Acccount to enable FileVault in the Jamf Pro Settings > Disk Encryption. Remains the same. Not possible due to the lack of Secure Token
  • Enabling the Management Account as FileVault user via the Jamf Pro policy payload. Again due to the lack of Secure Token, not possible. 
  • Creating a user and enable it for FileVault via a Jamf Pro policy. Yet again, does not work.
  • Resetting a local account password via a Jamf Pro policy. Does not work if the account is enabled for FileVault. You need to disable FileVault for that user first, but this kills the Secure Token…
  • Finally, ‘fdesetup’ can now enable FileVault on 10.14.2 again, even if there is no Secure Token holder on the Mac.

So in 10.14.2, this means that wether or not you have a Secure Token holder, you will always be able to enable FileVault via either a Config Profile, Policy or ‘fdesetup’.

Also, manually authenticating with an Admin account (local or mobile) to the Security & Privacy pane in System Preferences, to enable FileVault, also generates a Secure Token for that admin account!

And finally, using a tokenised Admin to create a new user in the System Preferences also grants that user a Secure Token.

I did some additional tests to see if any of the items above change if we give the Management Account a Secure Token. As expected, no it does not. This, if I’m seeing it correctly, is due to the fact that the Jamf runs as ‘root’ when running scripts/policies. Hence, obviously no Secure Token.

This means that granting the Management Account a Secure Token doesn’t really give us any other benefit apart from enabling us to use it at preBoot. 

Note: All users with a Secure Token are automatically added as FileVault user when enabling FileVault. However, when giving a user a Secure Token when FileVault is already enabled, the account does not show up at the preBoot. It does however remove it from the list of user which can't unlock the drive (System Preferences > Security & Privacy > FileVault), and adds it to the Jamf Pro Inventory as "FileVault Enabled User'. I had to run a  ' diskutil apfs updatePreboot / ' command to make the newly tokenised accounts show up at preBoot. It makes sense that the 'FileVault capability' of an account is directly linked to the Secure Token, but not sure if this behaviour is entirely intended.

Now, what does all the above give us. Well, lets summarise:

  • If you are not concerned about having an additional admin account enabled as FileVault user, things became very simple. Just let the end user use/create any local/mobile account you feel fit for your environment and enable FileVault with either a policy or a profile. All is good, you will have the recovery key in Jamf Pro if needed.
  • If however you need to have multiple users enabled for FileVault, or you want your ‘IT Admin’ account to be enabled as well, you will need some additional scripting.
  • The same goes for when you need to change the password of a FileVault enabled user via a policy/script.
!!! Very important consideration here is that if you want to manipulate additional Secure Tokens later, you will need at least 1 ADMIN token holder. A tokenised standard user is NOT enough. This admin account can either be your 'IT ADMIN' account, or your end user. This depending your scenario and script, see below. A tokenised non-admin account can't grant tokens to other accounts.

My suggestion for a workflow to grant your additional admin account a Secure Token.

!!! ALREADY AN UPDATE to what I wrote here -  see comments !!!
Update 2: 9/12/18 - promote the non-admin Secure Token holder. see comments !!!

What I want to avoid is any manual FileVault intervention post enrolment, as well as having to log in with a local admin account before the end user touches the Mac. 

  1. End User creates admin account: local – mobile – NoLoAD (see note on mobile admin accounts at the end of this post…)
  2. If using mobile accounts we enable FileVault first to generate a Secure Token
  3. End User gets Secure Token.
  4. Script grants other ADmin account a Secure Token
  5. If using local accounts we can enable FileVault here
  6. Demote End User if needed

The idea here is that our end user will be the ADMIN token holder which will give another account a Secure Token. This admin is tokenised because it was the first account logging into the Mac (local admin account, or NoLoAD created Admin Account) or FileVault has already been enabled and the Mobile Admin account got a Secure Token post enrolment. This, in 10.14.2, by enabling FileVault via a policy or profile.

The key to success here is to make sure that this end user Admin account gives our additional account a Secure Token BEFORE we demote it to a standard/managed account. Once we have a tokenised Admin account under our control, we can demote the end user (if needed for your deployment strategy).

This can be done with ‘sysadminctl’ and the following command. If you want to automate it, we need the username/password for both the tokenised admin as the account you want to grant the token to.

There are already some scripts in the community providing a solution to prompting the end user for his/her password. Maybe a bit dirty in the way that the password is temporarily passed via a variable, but yeah, it’s a solution.

I’m currently exploring other options to get the password in a more secure way, but I wanted to get this post out first. I will update when applicable, but all suggestions are more than welcome!

To grant another user a Secure Token:

sysadminctl -adminUser adminUsername -adminPassword adminPassword -secureTokenOn receivingUsername -password receivingUsernamePassword

When using the command manually in terminal, you can use the ‘interactive’ flag to prompt for the passwords:

sysadminctl interactive -secureTokenOn receivingUsername -password -

(The final ‘-‘ is to obfuscate the password in the prompt, but you could write it in clear text instead of the ‘-‘ if you really want to)

There is however another way of doing things. We could also use ‘fdesetup’ to enable FileVault for the ‘IT Admin’ account, and grant our end user a token. An opposite way of thinking which might work, but ‘fdesetup’ does not escrow the Recovery Key outside the machine. Hence I’m not really keen to even try this approach. I’d only use ‘fdesetup’ when I need to manually intervene if I have no other option left.

Finally we have our issue of ‘resetting the password of a FileVault enabled user’. As the Jamf Pro ‘local account’ payload in the policies can’t do it anymore, we also have to use ‘sysadminctl’ to do so.

The good news here, compared to disabling/re-enabling the user for FileVault is that ‘sysadminctl -resetPasswordFor’ does not kill the Secure Token. Furthermore, the user can immediately use the new password at preBoot.

The only command you’ll need is:

sysadminctl -adminUser adminUsername -adminPassword adminPassword -resetPasswordFor username -newPassword newpassword

A few things to wrap everything up for this 10.14.2 change:

  1. You don’t need a Secure Token prior to enforcing FileVault with a policy or profile anymore. It just works! Your first user logging in can actually be a mobile account, or a standard local account. 10.14.2 will create a Secure Token when FileVault gets enabled.
  2. Enabling users as FileVault users or resetting FileVault User passwords with Jamf Pro policies still don’t work and will probably never work due to the lack of Secure Token
  3. fdesetup is fixed
  4. Manipulating Secure Tokens need to be scripted and we need both the passwords of an ADMIN token holder and the user account we want to manipulate. This admin token holder can be either a local or a mobile account.
  5. The only consideration we need to keep in mind is that, if we want to do ‘zero touch’ deployment, the end user needs to be Admin initially. We can demote later, but we need the first user logging in to be admin in order to grant another admin user a Secure Token.

That’s it! 10.14.2 and Secure Tokens! It finally starts to make sense again!

Just as a summary:

Note: Just one more thing regarding the 'Mobile Admin Accounts'... there are still some macOS issues with creating mobile accounts which are by default 'Admin' and not 'Managed'. I've seen some very inconsistent behaviours. When binding via a policy, but especially with the Directory Binding during Automated Enrolment. The 'Allow Administration By' setting not being respected at all, or in specific situations... According to my tests I can confirm all the above is valid for a Mobile Admin account, but I would once again like to say: just forget the bind! Go for NoLoAD/JamfConnect. Just take the time once to change your workflows and deployment strategy, no matter how hard this may seem. And enjoy your easy life afterwards... especially if you run into issues creating mobile admin accounts, where you'll need to promote and demote again. No, not worth the hassle. At least, that's what I think. Bye bye mobile accounts!

Please let me know if I missed something! Or if anything I wrote is wrong 🙂
As always, all this is based on my own testing. Test and confirm before putting anything in production!

All suggestions, comments and remarks are more than welcome! Especially in this Secure Token saga!

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