Update: Also check out my post about macOS Catalina and BootStrap Tokens
Yes, there they are again our beloved Secure Tokens! Well, they actually never went away but after my final wrap up post a while ago, I decided to leave them as they are. Nothing really changed anyway. Most about them have been said anyway.
However, in this post I want to go back to a very specific situation. Imagine the following conditions:
- You want a local admin on the Mac which is FileVault enabled (and hence has a Secure Token).
- You want your end users to be Standard Accounts, but also FileVault enabled. Hence again, with Secure Token.
- You are not demoting your users via any script, but actually skipping account creation via a Jamf Pro prestage – Accounts Settings.
- You provision your Macs with Standard Account using Jamf Connect Login
- You are creating the Jamf Management account to fit the purpose of the local admin here above.
As discussed in my previous post, the fact of adding the ‘Accounts Settings’ payload in the prestage, changes the behaviour of the Management Account creation. When you don’t have the Account Settings payload in the prestage, the prestage will honor the ‘Management Account settings’ you define in the User Initiated Enrolment settings of Jamf Pro. If not set to create, it will not create it. If set to hidden, it will hide it.
Note: Hidden account should get UID 80.
However, when we do have the Account Settings payload, things behave a little different. (I was told that this is linked to a requirement from Apple MDM specs, where if the account creation is tweaked by MDM, an MDM provisioned admin account is mandatory… but I’ll leave that discussion for another time). The fact is, with this Account Payload added to the prestage, the following things happen:
- The management account is created, regardless of potential settings under User Initiated Enrolment settings disabling the ‘Create Management Account’
- The account does not get UID 80, but UID 501
Note: it does not matter if you skip account creation, or just limit it to Standard or if you are even creating additional admin accounts.... it does not matter. Account Setting Payload configured in the prestage = the behaviour above.
Now, in our scenario above, we create STANDARD accounts by logging into Jamf Connect Login. This means that, in line with Apple’s documentation, this Standard Account DOES NOT get a Secure Token… Why? Well, because of the existance of another local user with a UID above 500 ! Again, for the reasons linked to the prestage above: our Management Account!
Our UID 501 user, being our Jamf Management account, although being an LOCAL ADMIN does NOT get a Secure Token either! Why? Because it’s not the first account interactively signing in into the Mac!
Hence we end up with a system with NO Secure Token Holders. Is that a problem? Yes and No, it depends.
If you don’t care about having a local admin with a Secure Token, hence you don’t care about having a local admin which is FileVault enabled, and you don’t care about potentially needing to manipulate tokens (as in granting other accounts a Secure Token to enable them for FileVault) in the future… all is good! Remember that since macOS 10.14.2 enabling FileVault via any possible method, on a system with NO Secure Token was fixed. It will just grant a token to the user actually enabling FileVault at that moment.
But, in our scenario above, we DO want a local admin with a Secure Token! So how do we fix this situation? Well, I already discussed some options in the past:
- Provision the Macs with Admin users, manipulate tokens by granting your Management or IT Admin account a token and demote your end user…. Dirty scripting indeed.
- Make sure you log in with a local admin on the Mac before your Standard account end user logs in (or is created via Jamf Connect)…. bye bye zero touch
- Make sure you do not enable FileVault, promote your end user to admin, enable FileVault, grant your admin a token, demote your end user… again scripting madness…
- Whatever other possible option or voodoo script you might find
- etc.
The good news however is, that Jamf Connect Login actually has a nice little setting which you can enable to avoid all the above: LAPS !
<key>LAPSUser</key>
<string>AdminUser</string>What does it do?
First of all, as always: the official documentation and reference to this feature can be found here. As you can see, the first section is talking about approving FileVault enablement on devices with macOS 10.15 or above. While this is very valid as more and more of you will be upgrading your Mac environment, this is outside the scope of my post here. The LAPS feature actually works on older macOS versions as well.
That said, yes, what does it do? Well, I could not describe it better than what’s in the official documentation:
"This setting randomizes an already existing local administrator account password, uses the password to enable FileVault and create a personal recovery key, and then cycles the personal recovery key to become the local administrator password. This results in the configured LAPS user account and standard user account being FileVault enabled."
So, ‘an already existing local administrator account’… this can actually be any existing local admin on the Mac, but as discussed above, our scenario and the discribed behaviour of our prestage actually makes or forces us to have the ‘Jamf Management Account’ on the system. So to me it makes sense we just use that. Afterall, this gives our Jamf Management a real usecase, because as you might know it’s actually used for… nothing else than having an Admin account to connect to the Mac via Jamf Remote. Nothing else, because the binary of Jamf actually runs in the root context since many Jamf Pro versions ago. Still Jamf Pro needs to have this ‘managed by account ‘ info in the inventory to be able to ‘manage it’ and send MDM commands and profiles. A legacy thing…
Note: on the other hand, if you do intend to use Jamf Remote, you might want to choose the 'additional admin account' created in the prestage for the LAPS solutions. Otherwise, you'll need to update the Management Account info to match the password with the Recovery Key... not handy.
How does it work?
That’s actually the good part! It’s so easy! The only thing it needs is the above ‘LAPSUser’ key in the Jamf Connect Login plists… AND (that’s where the gotcha might be) the key to enable FileVault via Jamf Connect: EnableFDE ! It can’t just create tokens without enabling FileVault, hence you need to enable FV via Jamf Connect. Actually a good start to have things nicely secured and FV in place as from the moment the end user starts using the Mac!
<key>LAPSUser</key>
<string>jamfadmin</string>
<key>EnableFDE</key>
<true/>Add the above 2 keys to your JCL plists and you’re all set. Deploy a Mac via a prestage enrolment, provision it with Jamf Connect Login, skip account creation and your Standard User, as well as your Jamf Management Account will be tokenized and FileVault enabled! MAGIC !
But wait… we are enabling FileVault via Jamf Connect? So where does our recovery key go? Well, no panic! Although, according to the KB above, you could store it locally, there is a better way. Just enable the escrow functionality for FileVault via a profile, and the key will be nicely send to Jamf upon creation! Actually where it should be for secure safekeeping 🙂
Hereby some screenshots to make this all a bit more visual:
First all, make sure you create the management account in the ‘User-Initiated Enrollment settings’:
A prestage with ‘Account Settings’ payload and skip user creation:
Make sure a config profile is ready and scoped to all devices to enforce FileVault and Escrow the recovery key:
Note: It's axctually only the escrow tickbox you need for this LAPS solution to store the key in Jamf, but you need the 'Require FV2' anyway to avoid end users disabling it.
Configure Jamf Connect Login according to your iDP, and make sure to add the LAPSUser and EnableFDE keys !
IMPORTANT: FOR macOS 10.15 CATALINA OR LATER YOU MUST ALSO DEPLOY THE CONFIG PROFILE DESCRIBED HERE -- to allow enablement of FileVault by Jamf Connect Login (I'm just testing this with MacOS Mojave as there should not be any difference regarding Secure Tokens in Catalina. I will of course test 10.15 as well and report back later)
DEPLOY YOUR MAC 🙂
Moment of truth! “diskutil apfs listcryptousers /” to see who has tokens !!!
HOORAY! 2 users with tokens… let’s check to be sure!
Our Jamf Connect Login provisioned STANDARD Account:
And our Management Account:
But wait, what about the part saying it cycles the management account password to the recovery key…? Let’s check in Jamf!
Yes, our recovery key is there…
Note: escrowing the personal recovery key might require an additional inventory update to send it to the Jamf Pro inventory.
But is it now really the password of our Management Account? Yes it is:
And just to confirm, yes we unlocked admin privileges with our Management Account, while our end user is Standard:
Finally, yes the Mac is encrypting right after being provisioned…
And Jamf Pro also confirms we have 2 FileVault enabled users:
That’s it! As always, if you like this blog hit the like button, tell your friends about it and leave a message down below!
Brgds,
TTG
(PS: If you don’t like it, fine, we live in a free world. Just remember this is a personal blog, and not official documentation of any mentioned company or product. Doing this out of free will: sharing is caring.)
Apple ecosystem enthusiast, geek, tech gadget freak, Belgian living in the Netherlands
Enterprise Support Engineer II | Jamf
The first cert has been issued with a 100% pass! Congratz!
Super interested in this! Thanks for the write up! Question: does this reconcile the password if the FV key changes? So for example: if the need is there to rotate the FV key, will Jamf Connect update the management password as well?
Hi Clint. No it will not unfortunately
Good to know, thanks!
@Clint Depending the deployment and prestage account creation options, you might want to check Catalina Bootstrap functionality and use additional admin account to be Tokenized
What if I need a third account for management purposes? how does that get filevault enabled?
Hi kat. Depends. LAPS is one solution to give 1 admin a token apart from the en user getting one too. Bootstrap is another solution which also gives Secure Tokens to mobile accounts. Apart from that you will need to manually intervene or script it.
My dilemma is needing a routine “administrator account” that gets FileVault enabled. Since the recovery key gets recycled as the password, it kinda breaks administering the computers at a company level. I’ve tried to make the next admin account FileVault enabled and that doesn’t ever work.
Well not much you can do, one way or another you will need a script. If you leave the end user creation with JCL at standard, it won’g get a token. In Catalina this is a big problem because that standard account without a token can’t even enable FileVault. Compare to Mojave where it would get a token at FileVault enablement if the system was still tokenless. So with JCL creating a standard account without Laps, you will need a script anyway. If you do use laps all is fine for the standard account, filevault can be enabled, even by JCL immediately, and your admin of choice (can be any admin account) will get a token too. The only thing is, the account needs to exist already. All other, 3rd, 4th,… account will need a script or manual intervention but you will need the password of a token holder. No way around that. However, because the admin which got a token via laps has the password set ti the recovery key, you can fully automate the creation of a second admin and give it a token via the recovery key as password for the already tokenised account… remember that jamf connect enablefde feature can write the recovery key to a specified path via EnableFDERecoveryKeyPath key. Your script can read it there and use it as password to tokenize your 2nd admin… question is… is all this really needed depending how often an admin really needs physical access to a machine… for which it would need a tokenized admin account. In view of what is happening to the world nowadays… with most people working remotely, how often doe you really need a tokenized admin… anyway, the above is possible to script
interesting, ok thank you for your input. this is helpful. !!
ok I have one more question, sorry to be a bother.
What if I just used JAMF to reset the “Admin” password ? could that work?
No worries. Jamf can technically not reset passwords of accounts which have a SecureToken. This because you need an account with a secure token to reset the password of an account with a secure token. As Jamf binary does not use any account to run policies (not even the Jamf Managed account) it is technically impossible. Jamf runs from within a privileged binary. A script will be the only way if laps or bootstrap is not enough to achieve the goal. But the script to read the recovery key stored by jamf connect made me think of some things. Definitely possible, and quite easy. I’ll give it a night sleep and play with it tomorrow. It’s basically nothing more than a 2 line script. 1 to read the plist with the recovery key, a second do use sysadminctl command to pass the token. And the creation of the 3rd account is easy with jamf policy.
thank you!
hey again, just circling back on this. Instead of using an individual key, can we set it for institutional key and accomplish having the “same” password on each computer? or would this not work?
Hi kat. If an institution recovery key is deployed prior to enabling FileVault via Jamf Connect, that should work if the end user created via Jamf Connect is an admin. For standard account you still need to enable it via LAPS for which the additional admin password will change. Standard account can not enable FileVault without having a secure token and they don’t get one via Jamf Connect. An institutional recover key will nott help here.
Thanks for explaining that. Very helpful. This process is indeed frustrating. Re: using the script to read the plist and the path to recovery key. I’ve had no luck getting this to work. Seems like for some reason, my deployment doesn’t write the recovery key to the file. I’m banging my head back and forth with this.
Do you think I need to change the workflow with ‘escrowing the recovery key” could this be interfering with the writing of the recovery key to the path?
any help appreciated
I’d open a case with support regarding that recover key plist. I just tested and it does not write the key to the plist for me either. If you open a case for it we can create impact.
I’m opening a support case, as well. It’s not writing the key for us, either. We’re hoping to create a local admin account and granting it FV privileges using the account created via the LAPS process. Frustrating this isn’t working. Since opening, have you heard anything?
It’s indeed confirmed as a product issue. The laps process is writing 2x to the file. First time with the key but second run overwrites it with empty file. It should only run fdesetup once, so a product issue.
This doesnt work with users that are administrators. I keep hearing we should create separate plists but how do we scope that?
Different prestage and smart group based on prestage would be only option imo.
The screenshot of your “PreStage Enrollments –> Account Settings” doesn’t match my settings in JAMF Pro (version 10.21).
I see a selection field “Create a local administrator account before the Setup Assistant”. If I deselect this, no account will be created during the setup and I’m required to create an account during the PreStage process.
If I select this field, I can create a local admin account. Should this be the same credentials as the Jamf Management Account I filled in under “User-Initiated Enrollment”?
I’m planning to push the enrollment profiles via Apple School Manager, so am I correct that “Automated Device Enrollment” applies here, not “User-Initiated Enrollment”? I’m not planning to let user enroll their devices themself. So I’m confused if the Jamf Management Account actually will be created on automated enrolled new devices. Sorry for this rookie question 🙂
No problem! No rookie questions at all. The feature has changed over Jamf Pro versions. Earlier we had the “Jamf Management account” + additional admin account which could be created in the prestage. Now we don’t show the jamf management account in the prestage anymore, only the additional admin account which you can create. Best practice, in my opinion, is to set this to the same as the management account. The Jamf management account is a requirement for jamf pro to consider the mac as “managed” for the Jamf binary. The additional account is what Apple requires to be created during prestage if the account creation is skipped. Apple MDM requires an admin account to be created if you skip the user creation (for AD bind or jamf connect for instance). Furthermore, Apple requires the additional account to be created in prestage if you want to use “bootstrap” for FileVault and Secure token. The jamf management account does not qualify for this. So to keep everything simpel I’d recommend setting the additional account the same as the jamf management account in the user initiated enrolment settings to avoid confusion, as well as multiple admin account which you don’t need.
Regarding Apple School Manager: you assign devices in Apple School Manager to Jamf (added to Apple School Manager as your MDM server), and within Jamf you assign the devices to a prestage. If both are done, wiped or new devices will enrol automatically into Jamf Pro when going through the setup assistant.
Hope this clarifies your questions?
Thank you again for your comprehensive answer.
If I enter the same credentials under PreStage Enrollment –> Account Settings as I did under “User-Intitiated Enrollment” will this account be created twice? Once before the Setup Assistant during enrollment and the second time when the JAMF binary will be installed? The first one will overwrite the second one but will this have consequences for the UniqueID of the user? I prefer to hide the admin user in Users & Groups. This would mean the account will get UID 80.
Under User-Initiated Enrollment I’ve filled in the same credentials at the Management Account field and selected also “hide management account”. I would expect this account would get a different UID, depending on the order which one would be created first.
Thank you again for taking the time to explain my questions.
No, a user account can not be created or overwritten if it already exists. The UIE settings in Jamf Pro also say “create management account IF it foes not already exist”. You can still specify this account to be hidden from users and groups in the prestage.
However, please note that if this user gets a secure token, it will be visible on every reboot if FileVault is enabled. No way around that, all secure token holding accounts are visible at boot to unlock the drive. They can remain hidden in ays prefs if set so.
So the LAPSUser is not available as an option in either the Jamf Pro Config option nor the Jamf Connect Configuration App.
So I’m a little confused on how to add this key to the plist?
Am i being silly when I think it is weird that this key is not selectable at all? Any suggestions, it sounds so simple in this article, but I’m a bit confused.
You’re right. It needs to be set manually in the plist. So don’t use the custom profile option in Jamf Pro. Create a plist with the new configurator app (see xml you can read now in the app), or write one manually. Then add the key(s) before uploading to Jamf as custom settings plist.
I got this working on a prestage enrollment and it works great. I’d prefer to only keep the management account and user’s account but I have a few questions. If the user needs to be given and use the filevault recovery key in a lockout issue then what are the best practices of changing the management account password so they don’t use the key again for the management account.
Tired to reset it via JAMF but yeah I do see it doesn’t reset it due to secure token.
Hi!
This is not purely due to SecureToken.
The ‘change management account password’ payload in Jamf Pro Policy should work if Jamf Pro has the valid current password of the management account on file. But because LAPS is changing that to match the recovery key… the Jamf Pro database does not have the new password info of the management account.
You can change the management account password for each mac in Inventory-> General -> Allow Jamf Pro to perform management tasks.
So if you give a user the PRK, change the management account info on file and execute a policy to ‘change’ the management account password.
If however you want to ‘reset’ it in the payload… that will indeed not work due to SecureToken. Because the reset command does not authenticate with a SecureToken admin, it uses the root privileges of the Jamf Binary. Root has no SecureToken, so the reset fails by lack of SecureToken unlock.
https://docs.jamf.com/10.25.0/jamf-pro/administrator-guide/Management_Accounts.html
Apart from that you’ll need to script a password change passing the valid, current admin credentials of a SecureToken admin account, or it’s own credentials.
I was stumbling on the same issue. Ideally i do like to have a local admin with a secure token in addition to the local (non-admin) with a secure token.
And I was excited at first that this article was going to solve that! And although it actually does, I didn’t anticipate the Laps randomization of the password of the local admin account, so now I do have a local Admin with a secure token, but not with their own single Admin password for all my macs.
It is kinda pointless then…
You could argue that it might be handy when getting your hands on a mac physically, but I rather do a Recovery-mode restore & Install, than digging out the encryption key and use that as a password to log in… It is just too much effort and work…
Anyone know if this still works for the ABM enrollments with Big Sur? I just tried it on one that already had the Big Sur kernel updated and FileVault did not turn on. Catalina still works fine though.
Hi! No it does not work anymore on Big Sur due to the changes with Secure Token: https://travellingtechguy.blog/filevault-securetoken-and-bootstrap-in-macos-11-0-1-big-sur/ see comments for link to Jamf documentation on this
We are using Jamf Connect to make standard users on Catalina and enabling FV. If I understand correct ..
– Make an admin account under UIE with known password and create if it doesn’t exist.
– Make the same account in the Pre-Stage, same user/pw
– Use same account settings for the LAPS for devices 10.15
That correct?
That is indeed how I’ve been doing it to avoid the need for multiple additional admin accounts.
Followup … if I do not care about having another token-sized account on the computer … I can still set FV2 with a config and the standard user who first logins in will be able to have FV turned on … correct?
In Big Sur yes, but not in Catalina as macOS Catalina does not give a token to a standard account created via Jamf Connect outside the setup assistant. This due to skipping account creation.
And a standard account without token can not enable FV (an admin can).
This changed in Big Sur where it does give the standard account a secure token.
So using LPASUser, a PPPC, and an escrow config is the only way on Catalina to allow the standard user from Jamf Connect to get a token and turn on FV2 … sound right?
Unfortunately yes, unless you let them create an admin account and somewhere after initial provisioning the mac and the account you demote the user to standard