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
Manager Technical Support | 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
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
The link sends me too a lot of fantastic info, can you tell me what info link you’re referring too from the above comment.
Many thanks for great articles and info.
I’ll update the post and the link! Hete is the new link and info: https://docs.jamf.com/jamf-connect/administrator-guide/FileVault_Enablement_with_Jamf_Connect.html
Hello Frederick,
I have a question i hope you can help with. Love your articles and have read many of them especially about jamf connect, FileVault & Secure Token. My question is; We are using JAMF Connect Login ( w LAPS ) to enable FV, we have a configuration profile ( using login ) as well with the Zero Touch Pre-Stage. I’ve ran thru many tests with jamf connect login and it enables FV fine, the only thing is if I created a test config profile and then enroll a device FV prompts for the EU to enable it which is what I’d like to achieve…..because it escrows the key to JAMF……but if I run thru it again the 2nd time around, when jamf connect is creating the account I don’t get the prompt to enable FV…..I get to the desktop after our DEP enrollment is complete, using DEP Notify, when I go to JAMF to see the escrowed key, after running not 1 but many recon’s, the key never shows up, I check the FIleVaultPRK.db and it’s not even in the /var/db dir…? It shows encrypted in JAMF just no key, I also played with many configurations in the FV config profile, I tested a config where I remove the enable FV attribute and leave the escrow key part of the template…. as too see if JAMF Connect Login was enabling it without the need for it in the config and it does work….so am i missing something here?
Why would it work the first time and not continually after….?
Hi John, first of all I prefer not to enable FV with Jamf Connect but just via a config profile at login. You need the profile anyway for the escrow.
Apart from that, i see you mention “w LAPS”. I understand you want to use the LAPS feature, but what macOS version are you using? For macOS Big Sur and later you can not use LAPS, it breaks FV enablement because of the order ar which things happen with Secure Token.
Now, what I don’t really follow is “run it again the 2nd time around”. What do you mean? It works once, you wipe the same device and test again and it does not work?
We are deploying macOS Big Sur & Monterey soon.
I must have mis-understood one of your articles about LAPS and FDE. I currently setup FV ( config profile ) with JAMF Connect Login & LAPS….like your article. ..or how I understood it. In the Pre-Stage I checked the security config ( FV ) profile so it gets to the device before JAMF Connect Login, then JAMF Connect Login creates the account and prompts to enable FV, it works now every time and escrows the key to JAMF, I’ve restarted many times to see if anything is broken after the DEP Notify and the build of the mac, everything works like it should. I can talk to my solutions architect and try your way where we just enable FV using the config profile and having it enabled on login….thats a good idea but I was stuck on getting Jamf Connect Login to enable FV and prompt , it now works. If you think maybe just removing the LAPS user in my config profile would possibly stop any FV breakage I’m all ears. I’ll have to test that workflow as well…just to see.
I was thinking………what if I remove the LAPS key from my config and then continue with my workflow?
The LAPS breaking FileVault is that the same as when a user reboots the mac and then it asks for the FV key, if JAMF didn’t escrow the key then the EU is SOL and have to wipe the mac and start over.?
Well.. the reboot when there is no escrowed PRK key is a pain indeed, but seems to be a macOS issue. Nothing to do with why LAPS does not work on Big Sur or later. It’s actually not breaking FileVault as such, it’s only breaking the workflow. You simply can not add the LAPS key to deployments for Big Sur or later, because of the order at which things happen. LAPS in JC works in a order of: create the end user account, enable FV via the LAPS ADMIN account, cycle the passsword to be same as the PRK, use the LAPS ADMIN which enabled FV and now has a secure token to give the end user a secure token…
On Big Sur and later this does not work… because the end user already gets the first token and because of this LDAPS ADMIN can NOT enable Fv,… because it has no token.
This is mentioned in the JC admin guide about the LAPS feature. You have to remove that key if you deploy to Big Sur or later.
I think you also might need to consider the fact that on Macs with Apple Silicon you have to deal with this new thing called ‘volume ownership’. It requires both Admin privs (can be elevated tho) AND volume ownership to upgrade Major macOS.
If I were you I would set FV with a config profile/Policy upon next log-out or next log-in. This way you don’t have to deal with the JC LAPS malarkey and risk any difficulties with Secure/Bootstrap tokens and Volume ownerships.
Thank you both @Michiel for the advice, easy enough, I’ll just remove the LAPS user from our config profile and test again.
We are only deploying Big Sur & Monterey. So this will fit in nicely.
One more thing so I understand completely, No LAPS with JC, should I enable FV using JC or just let the profile do it?
Using JC seems to be working great….I’ve done about 60 tests on M1 macs using the MacBook Air and the 13″ MacBook Pro….
If it works for your deployment I’d go with JC.
I personally, as much fan of JC I am, prefer to do as much as I can with native Apple MDM framework.
Thank you again for all your help!!
I am trying to wrap my head around this, and I’m a little unclear. First, our setup matches the assumption you make at the top of the article:
– 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.
I actually don’t care if the local admin user gets Secure Token. But I do want LAPS to happen. And all Macs are Monterey. Does that mean that all I need to do to get this to work is to add this key to my JC login…
LAPSUser
jamfadmin
? And that “jamfadmin” needs to match the name of our local admin user (in our case, “iaadmin”). I already have JC doing enableFDE .
Hey Douglas! I’m afraid the answer is gonna be short: the LAPS key can not and should not be added to the plist if you ate deploying it to Big Sur or later.
This in view of how the feature works and the order of things in view of how the first secure token is generated since Big Sur.
Even if you only want the password cycle to the prk it won’t happen as the feature works in a way to tries to enable FV with the lapsadmin first…. Which will fail as the end user account grabbed the first token, and the lapsadmin without token can not enable FV. Hence it can not get a PRK and hence it can not set the PRK as its own password.
Furthermore since a few versions the laps key is even ignored:
To ensure the LAPS User (LAPSUser) setting only runs when required, this setting is ignored on computers in the following scenarios:
If any account type logs in with Jamf Connect on computers with macOS 11 or later.
If a local administrator logs in with Jamf Connect on computers with macOS 10.15 or earlier.
https://docs.jamf.com/jamf-connect/2.3.0/administrator-guide/FileVault_Enablement_with_Jamf_Connect.html
OK, so no LAPSUser key, check. So what is needed to get LAPS to be enabled/to happen with this configuration?
The LAPSUser key was a feature pre-Big Sur to tackle the lack of secure token for standard local accounts, and their inability to enable FV when provisions via Jamf Connect. Not per se, in my opinion, for pure LAPS purposes. There is no native LAPS functionality as such in macOS or Jamf Pro. If your only goal would be to have rotating or random admin passwords, you’ll have to leverage the random Jamf Management account password and rely on Jamf Remote if you need to use it, or use a 3rd party tool/script.
OK, thanks for the clarification. There are other solutions out there, but I didn’t want to get involved with them if all I needed to do was to add a key.
Hello, thank you again for your article.
I have followed all your steps including the EnableFDE, EnableFDERecoveryKey and even EnableFDERecoveryKeyPath in Jamf Connect Login setting and deploy built-in PPPC config profile of Jamf Connect.
Configuration profile of filevault is scoped to a smart group of Build Completed.
FileVault is enforced. But ecrow still not working. Do you know if there is anything I have left?
Hey, yes, the main reason for the escrow not working is that you are enabling FV via Jamf Connect (which I would advised against, see below), and the profile to do the escrow is set to a Smart Group.
I assume this ‘build completed’ criteria is on positive after FileVault is already enabled? I would need to see details on that criteria, but if this is the case then FV is enabled before the escrow profile is on the Mac and hence the escrow will never work.
For escrow to work, the profile needs to be on the Mac before FileVault gets enabled and before the recovery key is generated.
That said, I would advise against enabling FV (EnableFDE) via Jamf Connect, and instead push the profile as part of the prestage, set enable FV at login.
Just spend another long day and figure out how to enable FV by Jamf Connect. The key is to deploy FV config profile with two important consideration
1. Without enforce FV2 but need to deter user from disabling it.
2. Like you said, scope it during prestage enrolment
I can see the advantage of enabling FV2 by Jamf Connect as the user literally don’t need to press any button to get it enabled during creation of user account in Jamf Connect.
Why would you advise against enabling FV through Jamf Connect?
Because you need to disable “enforce FV2” indeed if you just want to escrow profile which you need, and this allows users to disable FV again later whenever they want… no idea why they would want to but still..:
Yes, the enable FileVault needs to be turned off as it will be enabled through Jamf Connect. But you can still enforce it by turning on the “Prevent FileVault from being disabled” in User adjustment of FileVault options.
Actually, yes, you are totally correct on that! That changed indeed when the FileVault payload was refactored a while ago!
Totally overlooked that!