Hey all!
It’s 2024 already and it has been a while since I’ve been talking about FileVault and Secure token. However, with the release of JPRO 11.2 I to bring that topic back to the table and see where we are on things.
To start I’d like to look back at https://travellingtechguy.blog/filevault-securetoken-and-bootstrap-in-macos-11-0-1-big-sur/ which was my last blog post on the matter. Long story short is that the flowchart I posted back then is still valid in view of when macOS (Sonoma) is granting a secure token to an account:
However, there are 2 points in time – which I highlighted with the red 1 and 2 – where potential problems could be triggered.
The nature of these problems is also twofold:
- a problem with the end user account creation
- a problem with the (unwanted) account Secure Token grant
Let’s start with having a look at the potential problems at time of the red 1 on the diagram.
When going through Automated Device Enrollment (ADE / DEP), there is a point in time during the Setup Assistant, where the MDM profile gets installed. At that point, the Mac enrols in JPRO, which, apart from all MDM stuff, also triggers the installation of the Jamf Binary. This via an install enterprise application command:
Alongside with the installation of the Jamf Pro Binary, and subject the account creation settings in the JPRO prestage, macOS may also creates the “Managed Admin” (aka autoadmin). This account, mandatory when demoting end user account creation to standard, or when skipping the end user account creation entirely, gets created with its Secure Token disabled.
In a similar way, and already the case since many previous versions of JPRO, the Jamf Binary also creates the Jamf Management Account. This with the “DisabledTags;SecureToken” option, so that the act of creating the account, on a system which at the exact time of the management account creation does not have a Secure Token holder, does not trigger macOS to grant it a token.
Note: Important to remember is that this "DisabledTags;SecureToken" only affects account creation. Yes, the account created with this option set does not get a Secure Token if no other user already has one. Without that option the account creation would trigger macOS to grant it the first Secure Token of the system. However, subsequent logins and ssh authentication using that account, as well as any password changes, prior to having another account with a token granted in the mean time, will still trigger macOS to give this account the first Secure Token! Long story short is that "DisabledTags;SecureToken" only affects the initial account creation!
That all said, for the red 1 point of time on my diagram, there was no problem with Secure Token since JPRO added “DisabledTags;SecureToken” to the Management Account creation in previous versions already.
However, with the arrival of macOS Sonoma, in combination with the JPRO LAPS functionality, it seemed that another problem saw the light. Depending on the exact time at which the Jamf Management Account is created (hence it’s password being set), before the end user account creation has been completed (if not skipped in the prestage settings), a race condition could cause macOS to skip the end user creation. This resulting in the unwanted behaviour of throwing the end user on the login window, with no opportunity to create a local account.
Reported behaviour like this ended up with the creation of JPRO Product Issues, of which some were valid, while others like PI111120 (macOS account creation is sometimes skipped if “Transfer Information” and “Location Services” is configured to be skipped in Prestage Enrollment) were not. I called this specific PI a hoax since day 1 of it’s existence as the Transfer info or Location Services options were only red herrings.
Nevertheless, the main root cause for this (or similar) unwanted skipping of account creation was nothing more than the above mentioned race condition. With JPRO 11.2 a change in view of when the Jamf Binary creates the Management Account brings resolution:
As of JPRO 11.2, the creation of the Jamf Management Account will be delayed until AFTER the first end user account has been created. By doing so removing the potential race condition causing the Setup Assistant to unintentionally skip account creation.
So far for what I wanted to elaborate on the above changes in JPRO 11.2 and the problem of account creation being skipped. But what about FileVault and Secure Token?
Well, if we look at the above scenario, where we are not skipping account creation, this should result in a situation where the end user creates his/her account, and macOS granting that account the first Secure Token.
“Should”… yes, as there are in fact still things which could potentially cause trouble with Secure Tokens. This has always been the case, however, JPRO 11.2 further reduces the likelihood of that happening. Let’s dive in further.
For the completeness of the story, allow me to list the Secure Token granting events once more. When no other account already has a secure token:
- Creating a local account and settings it’s password
- Logging in through the login window or authenticating with SSH, with a local account
- Changing the password of a local account
This including logging in with an account which previously was created with the “DisabledTags;SecureToken” option set. I leave Bootstrap out of this discussion as it is not related to the discussed problems.
However, this means that if a Jamf Pro POLICY runs, which includes a local account creation, before the first grant of a Secure Token, that account gets the first Secure Token.
At both the red 1 and 2 point in time on my flowchart, this could happen, which brings us to another change JPRO 11.2 brings.
As from JPRO 11.2, any account created via the LOCAL ACCOUNT payload of a JPRO Policy, will also be done with the “DisabledTags;SecureToken” option set:
This to avoid that a token would be granted if the policy runs while the end user is still in the Setup Assistant (red 1), or at the Login Window (red 2). In the second situation, for instance in view of scenario’s with Jamf Connect.
Unfortunately, this does not account for other account manipulating events, which are entirely outside Jamf Pro’s control. This includes any 3rd party scripts or packages doing anything like creating accounts or changing passwords, as well as any actions of IT Administrators logging in or authenticating with a local account on a tokenless system.
Note: some 3rd party end point security software requires a packages to be installed, which creates a Service Account on the Mac. If that happens, via a policy triggered in JPRO, this could still cause trouble with Secure Token. In this case, the policy needs to be delayed to a later time in the initial deployment, or the 3rd party tool needs to start using the "DisabledTags;SecureToken" option as well.
One more thing before I end this post, the change of delaying the creation of the Jamf Management Account, until after the creation of the first end user account (or to be more exact, to after the login of that account) also fixes some issues where Macs could end up with an UNMANAGED status in JPRO post initial enrolment. This especially when both the "Managed Admin" account (aka autoadmin) and the "Jamf Management Account" are named with the exact same account name !
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
Manager Technical Support | Jamf
Hey TTG,
first of all, I am immensely grateful to have your blog as a valuable resource for learning. Words cannot express how thankful I am for the knowledge and insights it provides.
Two things are not clear for me actually
1. If the user is initially created through Jamf Connect, is it sufficient to have standard permissions to obtain the secure token? or alternatively, does it make sense to initially grant the user admin privileges and then downgrade the permissions after enabling FileVault?
2. In case, you have multiply users on one device, it’s better to create an admin user to keep the secure token? Later on the user will created by Jamf Pro POLICY -> local create local.
thank you!
Hey, thanks a lot for the feedback! Appreciate it!
For you questions, no, you do not need to go into workflows with initially granting admin rights for users to get the secure token and later demote them. That was different in the past, but at least since macOS Big Sure things have been quite stable on how Apple designed the secure token, and it does not matter if the first user is admin or standard to get the token.
Multiple users complicate things. Mainly because once the first user got the secure token, other users can only get one by logging in through the login window (native or Jamf Connect does not matter), and leverage Bootstrap to get a token too. Problem is that if FileVault was enabled, subsequent users will only be able to login if the Mac is already FileVault unlocked. Meaning it is sitting at the login window and not the FileVault unlock screen (like after a reboot).
In all cases I still (and I know people are seeing things different) do not see the need for an admin with a secure token. In cases where physical access to a Mac is needed from an IT support point of view, I would personally just use the recovery key. And if that is escrowed correctly from the start, if needed I would then just issue a new recovery key via a JPRO policy (which should work if JPRO knows the current PRK), after using it, so from an audit perspective the PRK I used is cycled.
Creating local accounts with a JPRO policy, as from 11.2, will now be created with secure token disabled as discuss, so that it never risks to claim the first token if it would run before the first real end user creates an account. But regardless of that, if you do create local account via a JPRO policy, and other users have been using the Mac with FileVault enabled, you’ll have to make sure the Mac is FileVault unlocked as new users will not be able to use it after a reboot.
Thanks a lot for ur very fast answer.
This implies that a user created by Jamf Connect, such as one associated with an ENTRA ID, may have standard permissions to acquire the security token and activate FileVault. Historically, it wasn’t feasible for a user to enable FileVault without being an administrator, correct?
In my scenario, it seems effective to have an administrator account retaining the secure token. The new user generated through the Jamf policy appears as the volume owner, and after successive logins, FileVault allows the new user to access the system. (In other words, an existing user logs in, logs out, and the new user gains access as the volume owner with FileVault enabled.)
I’m aware of your blog article expressing the opinion that creating an administrator solely for secure token retention may not be necessary. However, from my perspective, it could pose an issue if, for instance, the initial user is an employee who leaves the company, necessitating the transfer of the secure token to someone else through a script, correct?
Correct, that changed in Big Sur.
Technically yes, although if data recovery is needed I would stil use the PRK, and for another user, I’d prefer wiping the Mac to allow the new user to have a clean device to work with.
Yes absolutely but I meant for a device which is used by multiply users. Then it’s not possible to delete the device because one persons offboaridng. Of course, if its a device which is used for just one person, we don’t need any administrator user who keep the security token.
Agreed. Yes, multi user remains a challenge and then I would see benefits in having an admin account with token indeed.
So, I have testing Jamf Pro 11.3 with its LAPS feature and FileVault enablement. Here’s my finding so far:
– To skip account creation (we will let Jamf Connect to create account), there must be Account Settings payload of prestage enrolment. I have no choice but putting in “mdmadmin”
– Jamf binary will create Jamf LAPS (jamfadmin) through user-initiated enrolment. As advised by Jamf, the Jamf LAPS account shouldn’t be the same name as “mdmadmin”.
– That means we will have two admin accounts in the mac, one is mdmadmin and jamfadmin (Jamf LAPS admin)
– My testing shows that the Jamf connect created account can acquire secureToken after logging in. That means, fileVault can be enforced through configuration profile / policy (with script)
– Jamf LAPS admin (jamfadmin) can acquire secureToken once logging in through login windows
– Jamf LAPS password rotation works fine. secureToken is retained as well.
I just wonder if it will cause any harm if I remove the mdmadmin which is mostly useless through policy with some scripting?
All sounds as expected and good indeed, and IMO the mdmadmin can be deleted… but *update* that does creates problems with the SetAutoAdminPassword command JPRO is sending out.
Need to look into it, as the account is referenced in /var/db/ConfigurationProfiles/Settings/.setupUser even if it is deleted and on the JPRO side the account remains referenced in management related DB tables.
Hi TTG, thanks for sharing your knowledge!
Any tips on how to avoid accounts created by Jamf Connect automatically getting a Secure Token? The scenario I’m talking about involves shared Mac devices where users log in via Jamf Connect, FV2 is disabled and it would be helpful for IT to be able to reset an account password via a Jamf Pro policy.
Hey TTG,
we deactivated the installation of the Jamf management account in the past.
We have now reactivated it in the UIE settings. Because we want to use it for LAPS
Unfortunately, the user is not created on existing macs in our tests by redeploying the management framework.
Do you have any ideas about what could be causing this?
I only managed to create the User with the following method.
https://community.jamf.com/t5/jamf-pro/retroactively-creating-jamf-laps-capable-admin-accounts/m-p/309862/highlight/true#M269599
Thats expected, as it is only done at enrolment, as per how JPRO works right now. There are some feature requests related to LAPS out there already.
Thanks TTG
Is this a workaround that we can do? Or will the DEP Macs explode? 😀
https://community.jamf.com/t5/jamf-pro/retroactively-creating-jamf-laps-capable-admin-accounts/m-p/309862/highlight/true#M269599
run /usr/local/bin/jamf enroll -noPolicy -invitation “${invitationID}”
Looks good imo. Did not test myself yet, but at first glance it should work.
Okay there seems now a offical jamf script 😀 with the same logic.
https://gist.github.com/talkingmoose/9f4638932df28c4bebde5dd47be1812a