Hello again! Yes, almost 1 month into 2020 and this is the first post of the year… I know! But to my defence, family first around New Year, a few additional days off, a small trip to the US… BUT! Here we are, and yes, finally ticking the box on writing a post on macOS Catalina and Bootstrap tokens! So without further due… let’s go!

So, in my previous post I mention the main difference between Catalina and Mojave regarding local accounts: the standard account login in as first interactive login gets a Secure Token! This was not the case in Mojave. Not that it changes a lot, as we know by now that the act of enabling FileVault on a system without ANY Secure Token holder… generated a token for the FileVault enabling user anyway… no big deal with this change in Catalina imo.

Remains: the lack of Secure Token for the admin account which the IT admin wants to use in case he/she needs to unlock the drive. In Mojave, the only way to get around this was either manual intervention on the device (in the presence of the end user) or scripting your way in by fetching the end user’s password… both not ideal to be honest. Ok, Jamf Connect has this awesome LAPS feature but not everyone has Jamf Connect deployed in their environment… (if thats the case for you… check it out! )

To kick this off: Apple’s Official Documentation on Bootstrap Tokens

macOS 10.15 introduces a new feature—Bootstrap Token—to help with granting a SecureToken to both mobile accounts and the optional device enrollment-created administrator account (“managed administrator”).

Ok that’s cool! But when reading the rest of the documentation before diving into testing, my attention was immediately going to this little note:

Note: A Bootstrap Token can’t be generated automatically by macOS during setup if the first user created in Setup Assistant is downgraded to a standard user using MDM or if local user account creation is skipped entirely. If needed, the initially created administrator account in Setup Assistant can be downgraded to a standard user later, or can be abandoned or deleted if not needed (It can’t be deleted or downgraded until at least one other Secure Token–enabled administrator account exists on the Mac). Alternatively, a Bootstrap Token can be generated after macOS setup using the profiles command-line tool.

Wait…? Standard accounts don’t generate Bootstrap? Ok, makes sense, but skipping account skips the Bootstrap Token generation as well? But… I want to skip account creation because I’ll bind my Mac (bad idea) and use Mobile accounts… and wasn’t this the purpose of “help with granting a SecureToken to mobile accounts…”??? Ok, I guess we’ll need to test…

So here are my scenario’s:

  • Automated MDM enrollment (Jamf Prestage) with additional admin account creation and keeping the end user account creation at administrator
  • Automated MDM enrollment (Jamf Prestage) with additional admin account creation and limiting the end user account creation to standard account
  • Automated MDM enrollment (Jamf Prestage) with additional admin account creation and skipping end user account creation
Note: VERY IMPORTANT in order to understand the way the Bootstrap Token works, is the fact that the 'managed administrator' mentioned in Apple's documentation is NOT the Jamf Management Account! 

As we will see below, the Jamf Management account plays NO role in the generation of the Bootstrap Token, and does NOT get a Secure Token either by using the Bootstrap.

It's only the additional administrator account which you define in the prestage which is considered as the 'managed administrator'. The Jamf Management account is actually created later in the enrolment process via the Jamf Binary, and not via MDM.

I'll be referring to this 'managed administrator' as the user called 'addadmin' during my testing below.
Scenario 1: end user = admin account created during the setup assistant

Because the setup assistant automatically brings us to the desktop, and automatically logs in, our end user admin account gets a Secure Token (expected and similar to Mojave), but also, new to Catalina, generates a Bootstrap Token:

Scenario 2: end user = standard account created during the setup assistant

Different to Mojave (as discussed in my previous post) we do get a Secure Token for our Standard Account, but NO Bootstrap Token!

We’ll see how to get out of this situation below.

Scenario 3: skip account creation during the setup assistant + AD Binding

Here we are not automatically signed in, hence we hit the login window. Just like in Mojave, NO SECURE TOKENS ARE GENERATED YET, and even when we log in with a Mobile Account (Admin or Standard does NOT mattter), NO Secure Token is generated.

If however we decide not to log in with a Mobile Account first, but use the Jamf Management account instead:

We do see that this admin account is granted a Secure Token. Nihil novi sub sole, same as in Mojave:

… and it does not matter which local admin account we use. The ‘additional admin account’ does the trick as well. Nothing new here:

BUT ! No Bootstrap Token! Again, just like in the standard account scenario, we’ll need to fix that…

So, what do we know already?

Well, we know that, apart from the standard account getting a Secure Token at first interactive login, there is no big change compared to Mojave, and that Catalina enables Bootstrap Token, but ONLY IF we keep the end user account creation during the Setup Assistant at ‘administrator‘. Limiting it to standard or skipping account creation does not. So far so good and exactly how Apple described it in the update documentation!

But to use the Bootstrap technology… we need to have it enabled… obviously, and instead of explaining what the Bootstrap Token does when we get it by default (with admin end user account creation), I’m going to go through the steps to enable it manually and work my way through explaining it’s functionality once it is enabled.

Note: it does not matter when or how the Bootstrap Token was created, once it's enabled it will have effect on the subsequent logins. No matter how.

So, we have 2 situations where we need to enable the BootStrap Token manually (yes, so far for your hopes not having to intervene on fixing Secure Tokens in any situation in the future…)

The first one, ‘end user is standard account‘, is a bit of a blocker… because just like in Mojave, you need an Admin Token Holder to manipulate tokens, and yes, also to manipulate Bootstrap Tokens. So, if you end up with a Standard Account who has a token, and you don’t have an Admin Account with a token… you will first need to promote the end user to Admin… before you can enable the BootStrap Token. Once that is done, it basically comes to running a single command:

sudo profiles install -type bootstraptoken

This will prompt you for the useraccount and password of the Tokenized Admin. After authenticating with your promoted admin account, it will enable the Bootstrap token and bring you in the exact same scenario as when you did not limit the account creation to standard account during enrollment. When done, you can demote the user back to standard, but remember you can’t deleted OR DEMOTED until another Secure Token-Enabled ADMIN user has been created on the system…

To illustrate the workflow I’m going to use scenario 3 where I skipped user creation, and logged in with the ‘an admin account’ prior to using a mobile account. This provided me with a Secure Token-enabled admin. In this case I used the Jamf Management account to do so.

Below you can see that, initially I have my jamfadmin tokenised, which allows me to run ‘sudo profiles install -type bootstraptoken‘.

However, just to confirm that the system is not Bootstrapped yet, I run ‘sudo profiles status -type bootstraptoken‘, which tells me the MDM server is Bootstrap compatible (Jamf Pro 10.18) but no Bootstrap Token has been created / escrowed yet.

After enabling it, I check the status again:

So this gives me a system with a Secure Token Holder (jamfadmin who was granted a token by logging in as first interactive login to the system), and the BootStrap which I had to enable manually due to the skip user account creation.

So, now that the Bootstrap issue is sorted (yes, if you do not keep the user creation during the setup assistant at ‘administrator’ this is NOT zero-touch 🙁 ), let’s put it to a test.

On Mojave, logging in with a Mobile Account on a system which has a Secure Token Holder…. the Mobile account would receive this pop-up:

But on a Bootstrapped Catalina system…

It doesn’t ! And after logging in, we can see that our Mobile Account was tokenized! Hooray!

And the same goes for the ‘Additional Admin Account’! When we log in with ‘addadmin’…

… it also gets a Secure Token ! As you can see, both my initial admin account , my mobile account and the additional admin (aka ‘Managed Administrator’ according to Apple) got their precious Secure Token!

But wait a second…. I told you that the Jamf Management Account is NOT the ‘Managed Administrator’ in this Bootstrap functionality (as it not created by MDM but by the Jamf Binary… )… so what’s the difference….

Well, lets reset our system, skip account creation, bind it to AD… but this time let’s log in with ANY other admin account… hence not the Jamf Management Account. In this example the additional admin…

Again, we skipped user account creation, so we’ll need to enabled the Bootstrap. This time our ‘addadmin’ is the Secure Token holder so we’ll use that to enabled the Bootstrap:

System tokenized, Bootstrap enabled… let’s log out and log in with the Jamf Management account…. NO SECURE TOKEN!

And this brings us to the most important conclusion to remember when looking at Catalina’s Bootstrap magic:

ONLY MOBILE ACCOUNTS and the ‘MANAGED ADMIN‘ (aka the additional account created in the prestage) can be Bootstrapped and receive a Secure Token at their initial login…. Apart from that, only users created via the System Preferences, by unlocking the account preferences pane with a tokenised admin, receive a Secure Token. Mojave-style scripted hacks, not considered. They still work, but I guess Apple’s game here is to get rid of those practises.

Finally, what happens if we do not login with a local account prior to logging in with a Mobile Account ?

If we do, we know by now that this local account, admin and standard, will get a Secure Token and that if it’s a standard account we’ll need to promote it to admin before we will be able to manipulate Secure and Bootstrap Tokens…

But if we don’t? Well, as said before, no Secure Token, no Bootstrap…:

FUN FACT: not sure if this is fully intended by design (I have a feeling it is to facilitate the whole Secure Token experience, TBC) but I noticed that, if there is no Secure Token Holder on the system logging at all, Catalina grants a Secure Token to the next local admin logging in!

This was NOT the case in Mojave! In Mojave, if the first interactive logging into the system was NOT a local ADMIN your opportunity to automatically grant a Secure Token was burned.

Again, not a big deal because enabling FileVault on a non-tokenised system sorted that out anyway, but still, good to know.

What’s even more interesting, is that even doing a ‘login’ or ‘su’ in Terminal, again on a non-tokenised system, suddenly also grants a token to this admin account.

As you can see below, the initial login was done with a Mobile Account… No Secure Token… ‘su jamfadmin’ –> Magic –> Secure Token for ‘jamfadmin’

And the same when you use ‘login’ or do a real logout / login through the login window.

Note: it only works if NO Secure Token holder exists... which makes sense because if there is.... we end up in the Bootstrap Token situations :-) 

That’s it for the walkthrough my Bootstrap Token tests and findings.

I hope I did not miss any scenario, or even worse, missed the ball completely on one of them… I’ve been testing the above multiple times, but although I’m quite confident about the results, this is new to me as it might be to you… In case you do have a different opinion on any of the above, please don’t hesitate to let me know via the comments below or through the macAdmins Slack channel!

But wait a second…, there is still something I’m missing here… looking at all the above, the only zero-touch scenario is keeping the end user creation as ‘administrator’… limiting it to standard or skipping user account creation entirely results in having to manually intervene to enable the Bootstrap token?

So what about zero-touch binding macs to AD and Bootstrap? As far as I can see – > not possible… and creating a local admin account prior to switching to a mobile account does not make any sense to me… except in student lab type scenario’s… or libraries… or shared devices where the IT admin deploys the Mac…

What about zero-touch deploying macs with Jamf Connect and Bootstrap? Again, not possible… as typically when deploying the Mac with Jamf Connect, you would skip user creation, hence no automatic Bootstrap either… which brings us back to the Jamf Connect LAPS solution.

Let me know if I’m missing something on the above final comments.

One more thing: The ‘sudo profiles’ commands prompts for the Secure Token Admin credentials and unlike ‘sysadminctl’ command there are no ‘-admin’ and ‘-adminpassword’ flags for the Bootstrap option. However, it could potentially be scripted using ‘expect/send’ commands in a bash script… to be testedbut still, I thought the Bootstrap Token functionality was added to avoid additional scripting… (Thanks Rob for reminding me about this).

And final final note:

sudo profiles validate -type bootstraptoken: Verifies that the Bootstrap Token escrowed in the MDM solution is valid on the Mac.

Well, although mentioned in Apple's documentation as stated above, it does not work for me... Error: This command does not support the option you specified...?!

That’s it! Probably to be continued… I’ll review this post myself over and over again in the next days, and if I do catch a fake news situation I’ll update immediately. For now, this is how I experienced it during my testing.

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

Brgds,
TTG