DISCLAIMER: Please wait for the official communication from Jamf regarding the Big Sur compatible Jamf Pro version. I have been testing with 10.24.2 and 10.25.1
Furthermore: The change regarding the creation of the Jamf Management Account discussed below is something I'm adding in this post as it may also impact edge case manual manipulations on a token-less macOS Catalina. See note at the very end of this post.
Please not that all my findings are based on previous understanding of FileVault in macOS Catalina and testing in Big Sur. I'll verify everything once again when full public Apple documentation is available.
Here we are! A new major macOS has been released so there is no escaping from checking what macOS Big Sur brings us in view of FileVault, SecureToken and Bootstrap!
Apart from doing a few spot checks when I heard about some rumored changes during the beta period, I deliberately postponed doing a full test until the release candidate was ready. This to avoid wrong assumptions caused by unexpected behavior native to beta versions and / or incompatible Jamf Pro versions.
Now the wait is over, and I must say I’m really happy with the changes which macOS Big Sur brings regarding FileVault! Things really got a lot less complicated to understand! Let’s have a look!
For those who are new to FileVault, I would still suggest to review my macOS Catalina flowchart in order to fully appreciate the changes which macOS Big Sur brings.
For this post I’m going to try to keep things as simple as possible, meaning that I’m not going to share screenshots of each test and command line validation of my findings. Instead I’m going to focus on pure statements and work my way towards a new flowchart!
Let’s start with my setup:
- Jamf Pro 10.25.1
- macOS 11.0.1 Big Sur (RC2)
- Extension attributes to report SecureToken, Bootstrap and FileVault
- Jamf Pro policies to create additional accounts, bind my Mac, etc…
As you can see above, I’m testing on the Release Candidate 2. Reason for this is that I want this post to go out the moment Apple pushes the public availability of macOS Big Sur. As things look really good, I don’t expect any changes in the official public release.
I’m using extension attributes in Jamf Pro to check the SecureToken holder, the Bootstrap token, FileVault status, etc… This to avoid having to login with any account when it’s not a part of my test. This is very important, because logging in with any local admin account on a token-less macOS Catalina system, generated a SecureToken for that account. Without knowing the exact behaviour in macOS Big Sur at the start of my testing, this could potentially corrupt my findings. Hence the use of the extension attributes to grab the status of the system. Those EA’s run from the Jamf Binary during inventory updates within the root context. As root does not / should not have a SecureToken, it does not impact my testing in any way.
This allows me to monitor progress in the Jamf Pro Dashboard…
…. and the inventory of my test Mac:
More info about my extension attributes can be found HERE.
Now, let’s now have a look at some basic statements for FileVault in macOS Big Sur:
- Each account, admin or standard, created by the Setup Assistant gets a SecureToken and enables Bootstrap
- The Managed Administrator, created by MDM as additional admin account during the Setup Assistant (UID 501), does not immediately get a SecureToken
- The Jamf Management Account, created by the Jamf Binary during enrolment, does not get a SecureToken (Jamf Pro 10.24.2 or above – more about this below)
- An account created by a script, a 3rd party tool like Jamf Connect, a Jamf Pro Policy or a Mobile Account (in case of AD Binding) does automatically get a SecureToken upon creation of the account if there is no SecureToken holder already present on the system
- Any authentication with a local admin, EXCEPT the Jamf Management Account (Jamf pro 10.24.2 or above – more about this below) on a macOS Big Sur system with no SecureToken holder already present generates a SecureToken for that admin account (ssh, screensharing, Terminal, Login Window and System Preferences)
- Bootstrap now gives a SecureToken to ANY account logging in into the system through the login window (if Bootstrap is enabled/escrowed).
Let’s try to visualise this first. Have a look at my new flow charts and try to match my statements above. I’ll elaborate below.
Ready? Ok let’s elaborate and check if we are on the same page!
Let’s start with the most straight forward enrolment strategy:
We do not skip account creation during the Setup Assistant
If we do not skip account creation during the setup assistant, it does not matter whether the Setup Assistant creates an admin account or a standard account. Both types of account will receive the first SecureToken and Bootstrap will immediately be enabled (if the MDM server supports it – Jamf Pro 10.18 or above). This was already the case since macOS Catalina 10.15.4 and does not change in macOS Big Sur!
But what about the Jamf Management Account and the Managed Administrator ? Well, here we need to pause for a second! Because there is a change in both macOS Big Sur as in Jamf Pro 10.24.2 or above!
First of all, both accounts mentioned above are NOT the same! The can have the same account name, but they are a different concept! I’ll try not to go to far into detail here, but please allow me to quickly sidetrack a little bit as it is very important to understand this in view of fully understanding FileVault in macOS Big Sur!
The Jamf Management Account is a legacy necessity of the Jamf Binary, as older Jamf Pro versions required the existence of this account to perform management tasks. In Jamf Pro 10.x (or even since a couple of versions before this) the Management account is only used for:
- Jamf Remote (as it uses these credentials to remote into a Mac)
- To consider the Mac as ‘managed’ (again, a legacy thing)
- To re-issue a Personal Recovery Keys if Jamf Pro has no valid recovery key in the inventory of the Mac. This only works when this “Jamf Management Account” really exists on the Mac, and if it has a SecureToken. In that case the Jamf Pro ‘re-issue PRK’ payload uses the credentials of the Management Account to cycle the PRK
But apart from that, this account does not necessarily need to really exist on the Mac.
Note: try it out, enrol a Mac via User Initiated Enrolment while disabling the 'Create Management Account' checkbox in the Jamf Pro Settings. Yes, the account details need to be defined, but the actual creation of the account is NOT necessary. Furthermore, go to any inventory of a test Mac, and edit the general section. Change the account name and password to anything you want and save. It does not break anything, apart from the items in the list above. Jamf Pro just needs to 'think' this account exists for the binary to work.
However, if you do create the Jamf Management account, it is created by the Jamf Binary during enrolment. Not by MDM!
The Managed Administrator is an additional admin account created by MDM during the Setup Assistant. This is an Apple concept, not a Jamf requirement. Apple requires the creation of this additional admin when the user creation is being skipped, or limited to Standard privileges, during Setup Assistant.
This Managed Administrator is also the account which, apart from all Mobile Accounts, was the only local account which could automatically get a SecureToken via Bootstrap in macOS Catalina.
This Managed Administrator can be configured with the same account name as the Jamf Management Account, but can also be a totally different account. This is where is gets interesting for macOS Big Sur.
If you set the Managed Administrator (the additional admin account you define in the Jamf Pro prestage), to the same account name as the Jamf Management Account (which you define in the User Initiated Enrolment settings of Jamf Pro), then the account will be created by MDM during the Setup Assistant. Obviously, because the account already exist by then, the jamf Binary will not create it again during enrolment.
In this case the same account is both considered as Apple’s Managed Administrator and the Jamf Management Account. Both with their own purposes. In this case the account will be created with UID 501, and it will NOT get a Secure Token. This was already the case in macOS Catalina and does not change in macOS Big Sur.
BUT, if we don’t set those 2 accounts to the same account name, and we configure Jamf Pro UIE to really create the management account, you end up with 2 additional admin accounts. This was no problem in macOS Catalina.
However, let’s have a look at bullet point 4 in my statements above…
An account created by a script, a 3rd party tool like Jamf Connect, a Jamf Pro Policy or a Mobile Account (in case of AD Binding) does automatically get a SecureToken upon creation of the account if there is no SecureToken holder already present on the system
Doesn’t this conflict with bullet point 3… ?
The Jamf Management Account, created by the Jamf Binary during enrolment, does not get a SecureToken (Jamf Pro 10.24.2 or above – more about this below)
This is a bit conflicting no? Because the Jamf Management Account is actually “a scripted account creation”, created by the Jamf Binary!
Exactly! And this brings us to a change which was made in Jamf Pro 10.24.2 and above…
NOTE: Again do not consider Jamf Pro 10.24.2-10.25.1 as fully compatible with macOS Big Sur. Wait for the official Big Sur compatible release from Jamf!
If you would however enrol a Big Sur Mac into Jamf Pro prior to 10.24.2 (for testing purposes only – ignoring other potential compatibility issues), the creation of the Jamf Management Account by the binary during enrolment could result in triggering the following change in macOS Big Sur:
If there aren’t any SecureToken enabled users on a Mac, setting a user password will enable SecureToken for that user only. If you use a workflow that programmatically creates a user and sets its password before other user accounts are created, the programmatically created user will be the only SecureToken enabled account.
To prevent this from happening, add ;DisabledTags;SecureToken to the programmatically created user’s AuthenticationAuthority attribute prior to setting this user’s password:
sudo dscl . append /Users/mdm_created_admin AuthenticationAuthority “;DisabledTags;SecureToken”
If you do create the Jamf Pro Management Account adjacent to the Managed Administrator (other account name), there is a chance that this account gets created before the end user account is created. Whether that is because the user goes with turtle speed through the Setup Assistant, or because you skip account creation, chances are it happens. Noting the change in macOS Big Sur above, this means that the Jamf Management Account would get the first SecureToken!
If this would happen, it would mean that the end user would not be able to enable FileVault by lack of getting a SecureToken. Hence a manual or scripted intervention would be required to fix this situation.
To avoid this the Jamf Pro Management Account is now being created with the “;DisabledTags;SecureToken” flag:
Note: If required, the SecureToken can still be enabled for the management account post enrolment with the sysadminctl command.
That said we can conclude that both the Managed Administrator as the Jamf Management Account does not get a SecureToken upon enrolment.
This brings us to account creation, post-enrolment, after skipping the account creation during the Setup Assistant. By now we know that at this point there will be NO SecureToken holder on the system yet, and apart from that, just like on macOS Catalina, Bootstrap is disabled.
However, what happens next does change in macOS Big Sur!
No matter which type of account gets created next, standard or admin, local or mobile, by any means, gets the first SecureToken !
This is a very welcome change compared to macOS Catalina, where only a login (or any other authentication) by a local admin account on a token-less system generated a token (or FileVault Enablement in case of Mobile Accounts). More problematic was the fact that, not only did a scripted local standard account creation lack a SecureToken, it was also not able to enable FileVault! Even if there was no other SecureToken holder on the system.
On macOS Big Sur, the user creation, or more accurate in view of the quoted elaboration above, the act of setting a user password, on a system with no existing SecureToken holder, immediately gives that account a SecureToken.
The same happens when logging in and creating a mobile account when the Mac is bound to AD. On macOS Catalina, a mobile account would only get a SecureToken upon FileVault enablement or via Bootstrap. Now it immediately gets a SecureToken upon mobile account creation.
Bootstrap however, is NOT immediately enabled. As mentioned above, skipping account creation during the Setup Assistant disables Bootstrap, and unlike SecureToken, Big Sur does not enable it upon account / user password creation. But, just like in macOS Catalina, it will automatically be enabled / escrowed (if the MDM server supports it), at the next login of a SecureToken-enabled account.
Once Bootstrap is enabled, the Managed Administrator and any other mobile acccount logging in later will automatically receive a SecureToken. Just like in macOS Catalina, however, Big Sur goes beyond that!
In macOS Big Sur, ANY account (local/mobile, standard/admin, Managed Administrator or not) does get a SecureToken via Bootstrap!
This basically summarises my second flow chart above!
Now, as you can see I added a box with “Jamf Connect” in the flowchart. This is just to highlight that the user creation by Jamf Connect actually does 2 things:
- Create the local account + setting a password
The user account / password creation triggers the generation of a SecureToken (on a token-less system), and the login following in one go immediately enables Bootstrap! NICE ! This for both Standard as Admin Accounts.
This is NOT the case for mobile accounts or accounts created via other scripted mechanisms. For mobile accounts a 2nd login with that initially created and tokenised account is needed to trigger the escrow of the Bootstrap token. For accounts created programmatically, not via Jamf Connect, a login is required as well.
That’s it! macOS Big Sur and FileVault just made the life of all macadmins a lot easier. At least that’s my opinion. I do hope however that this post will allow you to get up to speed with preparing your organisation for a FileVault-compliant management.
But wait, there are a few more things…
Jamf Connect LAPS? Sorry, as it stands today (Jamf Connect 2.0.2), that’s gone. The fact that macOS Big Sur now also gives a SecureToken to standard accounts created by Jamf Connect, causes the LAPS functionality to break. As the standard account is created first, with a SecureToken, the ‘lapsadmin’ you define in the Jamf Connect configuration can NOT enable FileVault… by lack of SecureToken. This could potentially be fixed by reversing the order of operations by enabling FileVault via the freshly created standard account, followed by a token grant to the ‘lapsadmin’. This instead of the other way around as per current LAPS functionality. I leave the decision on whether that feature is still needed or not to the devs and the community (feature request?).
Enabling FileVault with the ‘EnableFDE’ key in Jamf Connect, without LAPS, still works however (until, maybe one day, enabling FileVault via ‘fdesetup’ gets sunset in future macOS versions…)
Next, I want to highlight that the Bootstrap functionality to automatically give an account a SecureToken (now ANY account compared to only the Managed Admin or Mobile Accounts in Catalina), still requires a login through the Login Window! Ok, good for when the drive is already unlocked and you are sitting at the Login Window (not the same as the FileVault unlock screen…) but if the Mac has been rebooted you’ll still need the PRK if you don’t have a SecureToken already. Hence I’m still struggling to understand the real benefit of this Bootstrap functionality… Ok for environments witch shared Macs like School Libraries or Labs, but apart from that… ¯\_(ツ)_/¯
Last but not least, as mentioned in the disclaimer at the beginning of this long post, there is one more thing I want to mention. The fact that the Jamf Management Account is now being created with the “;DisabledTags;SecureToken” flag should not impact your current workflows. However, authenticating (ssh, screensharing, Login Window, Terminal, System Preferences, ...) with this account against a token-less system, macOS Catalina or Big Sur, does not trigger the creation of a SecureToken. If a SecureToken is required for this specific account, a manual or scripted intervention via the 'sysadminctl' command is required.
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!