Hi all!
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
- Login
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!
Brgds,
TTG
Apple ecosystem enthusiast, geek, tech gadget freak, Belgian living in the Netherlands
Enterprise Support Engineer II | Jamf
“Note: On macOS 11 or later, the Local Administrator Password Solution (LAPSUser) is not required to enable FileVault for standard accounts. ”
It looks like LAPS is still listed in documentation for JC2.0.2 and 2.1. Do you have other references on how it won’t work? The only thing I see is listed above which seems to imply it’ll still work. Setting standard users with Filevault is only half the use. Is there another good method for having a unique local admin password for each computer also have it secure but available?
Hi Wesley, yes it is indeed still listed because it is still in Jamf Connect 2.0.2 and 2.1. This because it still works on Catalina. It’s not because Big Sur changed how Secure Token works that Jamf Connect should change its functionality or remove features for Catalina.
The feature indeed has 2 purposes, fixing the fact that standard user could not enable FV is created with Jamf Connect, and give the additional admin a Secure Token.
To have a password unique to each computer for an additional admin you can use the Jamf Management account with randomised password if you set the account name different to te managed admin in the prestage.
That will be an unknown password which you can only use with Jamf Remote however, and it will not have a token.
Apart from that there is no other possibility than scripting.
Question remains, do you still really need an additional admin account with Secure token? As all other roadblocks for end user accounts are now fixed, bootstrap has been improved… what would be a scenario where you need an admin with secure token?
If you are locked out of the system because the end user forgot the password and rebooted, you will need physical access to the machine anyway to unlock FileVault. Here the recovery key can be used and there is no difference in accessing the devices with a know password compared to using the recovery key. You need physical access anyway and it can be argumenten that the recovery key is even a more secure option than an password which is known to some people other than the PRK which is securely stored in Jamf Pro.
If the Mac is not reboot, hence FileVault drive is still unlocked, you can use any admin to log in… and bootstrap will even give it a token.
IMO there is no real need for LAPS anymore, but I leave that to each other’s interpretation and requirements of course.
Fact remains, Big Sur changes the way Secure Token works and LAPS via Jamf Connect is gone for Big Sur.
This is also partially mentioned in: https://docs.jamf.com/jamf-connect/2.1.0/administrator-guide/Release_History.html
Hi TTG, thanks for you great post again!
My nicely working JC2 + Catalina environment, now (with Big Sur) fails to enable FV upon the very first login. As you well described because I’m using LAPS.
I use 2 admin accounts:
– ‘admin1’ is my jamf management account, setup in Jamf Pro settings. We all admins in our company use its known credentials for elevated tasks and support.
– ‘admin2’ is my managed administrator, setup in the PSE. We use this for LAPS.
I’d like to have an environment working for both Catalina and Big Sur, so I duplicated by JC Login Config Profile having now these two:
– ‘JC Login (Catalina), with LAPS (admin2), scoped to a SG ‘Catalina & DEP enrolled’ and excluded from another SG ‘macOS Big Sur’.
– ‘JC Login (Big Sur), without LAPS, scoped to a SG ‘Big Sur & DEP enrolled’ and excluded from another SG ‘macOS Catalina’.
Both CPs are ticked in my PSE.
However, I tested a few times with both OSs and I can see during the Setup Assistant, after the Remote Management screen, that both CPs get installed.
Q1: Possibly because my SGs scopes are to complex at this stage?
Then JC Login screen comes up (Azure AD), user is created (set to be standard always) and I reach desktop for the first time.
Right after that I go to Sys Prefs > Profiles and I can only see de desired CP installed.
Q2: Possibly because a recon already removed the undesired one?
Then I check FV and it’s enabled regardless of the OS this time! I also check secure token status of users and they seem to be in accordance with your post.
on Catalina:
admin1 DISABLED
admin 2 ENABLED
standardUser ENABLED
on Big Sur:
admin1 DISABLED
admin 2 DISABLED
standardUser ENABLED
So even that my dual CP scenario seems to be working, I don’t know how solid it is and if will work every time regardless of the OS (Catalina or Big Sur).
Q3: is there a better way to set this up without have two separate PSE, one for each OS, which will then require manual assignment of computers?
Q4/Note: I checked both my ‘admin2’ and ‘admin1’ and I could not see the “;DisabledTags;SecureToken” flag on them. I think I’m not fully understanding this bit.
Thanks again!
Hi, if you add a profile to the prestage, ir installs it during setup assistent, regardless of the scope! In the mean time the enrolment continues, jamf installs the jamf binary, runs a recon, smart groups calculate and the scope of a profile applies. Exclusions and smartgroup pull the prestage profiles which the device should not have.
So yeah I would not add configuration profiles in prestage if they are not also scoped correctly because the timing and speed you go through the setup assistent will create inconsistent behaviour.
2 different prestage needed imo. Or just forget about Laps and script a secure token grant for you admin if you really want.
Question is, when are you going to use or need that secure token? If you need acces to the machine pre boot you need to have the mac in your hands, and you can use the PRK…
Ok standard accounts and Jamf Connect… need laps for FV but you can script it. How many devices will re – enroll with catalina anyway if you already have Big Sur devices? I presume you are ready for embracing big sur in your environment then?
The disabledtag, which jamf pro version are you running? And if you use laps to give the account a secure token or enable it by any means after enrolment it removes that flag.
Hi, I don’t mind not having an admin with secure token. PRK is fine for me. The only issue is standard accounts with JC. How can I script that without laps? Do you have a link or something to investigate that?
We usually delay the approval of new OS for a few months until all our apps prove to work fine on it, so I expect to have Catalina and Big Sur coexisting for a while when we approve it.
Jamf Pro version 10.25.1-t1602899070. I’ll double check the flag on Big Sur.
Thanks!
Scripting Secure Token always needs user interaction, so not that fluent either. My script has all then ingredients but might need some cosmetic cleanup: https://github.com/TravellingTechGuy/manageSecureTokens
Alternatively, make everyone Admin during enrolment and demote them to standard after user creation. Either scripted or via a logout/login with Jamf Connect
One thing you could do, while not as fluent, is delay the installation of Jamf Connect with @ enrolment trigger based on your smart groups. Together with the profiles. Add a “killall login window” and the username/password login window will automatically flip to Jamf Connect and have the correct config. Or use the authchanger.
I would like to know what has been your experience with Macs running 11.0.1 that are truly tokenless and how you were able to deal with them.
I have 2 Macs, one a 2016 MacBook Pro 13in and a 2020 Intel MacBook Air. Both are tokenless after a complete wipe and reinstall of Big Sur. I have not found a single method that creates a secure token on either of them.
Hi Ian. How have these computers been wiped, and how have they been provisioned?
What does “sudo fdesetup list -extended” really say?
What has been done during the setup assistant?
I do believe you, nothing surprises me anymore with SecureToken, but I’d need to know exactly each step in the process after the wipe as it is technically almost impossible to create a tokenless Big Sur system.
The 2 Macs were wiped using the erase install flag in the MacOS installer so they were a fully wiped and clean install.
I do skip account creation during setup assistant and the Mac is joined to AD during a bootstrap setup using Munki.
When I run “sudo fdesetup list -extended” I do get a user listed but the user is “343dbb665679317905918c4622d6ea9f” and according to my Jamf instance the full username is “Information Technology Temp Admin”.
I have never seen this account appear before but it is the secure token holder so you are correct in that it is not truly tokenless.
After further investigation, I believe I have uncovered the issue.
Since we still perform binds, part of the script to perform the bind is to first create a temporary account for the purposes of helping with unbinding when necessary. It is this account that gets the Secure Token first. The behavior is consistent on an M1 Mac as well.
Hi Ian, sorry, was stuck on an emergency call.
Yes, that first account gets a token by authenticating on a (at that point tokenless system). If you then delete the account scripted (which macOS tries to block you from doing, but there are still situations where it foes delete the only secure token holder), you end up with what I call a ghost token holder and things go bad.
Say for instance we skip account creation at the setup assistant. The Jamf Management account gets created with the ;DisabledTags;SecureToken flag, so it does not have a secure token.
As part of enrollment we also create an additional local administrator account called OrgAdmin. This account gets created programmatically before the first login on a system with no secure token, therefore it is granted the first secure token.
We are now at the Jamf Connect Login window. The end user logs in, Jamf Connect creates a standard account for them. If I understand correctly this account is not granted a secure token. The end user cannot enable FileVault on this system.
What options, if any, exist for this workflow to allow the end user to enable FileVault in this situation? Will it require using the OrgAdmin account to grant a token and/or send the bootstrap token to Jamf Pro?
Hi Sam! How is the OrgAdmin created exactly? You correctly mention that the Jamf Management account gets created with disabled token flag, but you are skipping account creation, so that means that the prestage MUST (automatically by Apple requirement) create an additional admin… “the Managed Administrator”.
Is this your OrgAdmin? Because if yes, this account does NOT get a secure token.
If however you are talking about any other scripted account creation… and OrgAdmin is not the “managed admin” from the prestage (not the same as Jamf Management account, can be but 2 different concepts) then you end up with 2 admin accounts and in that case, yes, it gets a token.
If OrgAdmin is the one you specified in the prestage (and other script or policy) then it should not get a token and on macOS Big Sur the Standard account created gets the first token.
See my flowchart.
In my example the OrgAdmin account is created using a Jamf policy (triggered by an enrollment script with the Jamf Connect Notify mechanism).
So it ends up being the second admin account in addition to the “Managed Administrator” (which is also the Jamf Management Account).
It seems like I would either have to do some dirty scripting with the admin password in plain text, or I need to stop creating the second admin account(either entirely or at least before the end user logs in).
Hi Sam! Thanks for clarifying! Indeed, in that case we are 100% on the same page.
With this workflow you will have to script, so I’d definitely opt for tweaking it and avoiding that second admin.