Skip to main content

I've been banging my head against a wall on this.

We have Sophos which allows us to enforce filevault and manage the recovery key. We need to add a service account to the machine with a random password per machine and give it securetoken so it can decrypt. The service account and user account will both be administrator. We're using Jamf Connect (rolling it out once this is solved).

LAPSUser key in Jamf Connect + Enabled Filevault won't work because both the service account and user account need to be admins. I thought about making them standard and then making them admin afterwards.

Support suggested this:
https://github.com/kc9wwh/FileVaultEnableAdminAccount
However the password will be random so I'd need to somehow grab it and pass it in.

I also saw some posts about this script which syncs passwords as an extension attribute:
https://github.com/NU-ITS/LAPSforMac
Maybe passing the password from the attribute to the previous script?

The only reason we want the service account to have securetoken is because there's usually an issue with the sync between filevault and the local account password. That and the user forgets their old password once they changed it. We can get in with the recovery key but we have to decrypt and re-encrypt it to allow them to decrypt with their local password whenever that happens. Unless we have a securetoken user where we can just sign in and then remove and re-add them using fdesetup. Also if we for whatever reason rotate the service account password then we're pretty much screwed is my understanding.

I feel like I'm way out of my wheelhouse here with this level of scripting.
Is there a better solution for this? What's everyone else doing? I hope Jamf is working on something to make this easier.

I keep coming back to this: https://travellingtechguy.eu/jamf-connect-and-laps/
However I need to promote the user to admin afterwards somehow and then probably abandon Sophos for filevault management to avoid conflicts.

@dnorman I also had this issue but from a slightly different perspective. Here is how I solved it.

I wanted Jamf to be able to regularly re-randomise FileVault2 recovery keys stored in Jamf. It appears this requires the Jamf management account to have a secure token so it has full FileVault privileges. I also wanted Jamf to create local admin accounts on each Mac with unique passwords for each Mac and again regularly randomised. My solution for macOS Catalina was as follows.

  1. Have Jamf create a local admin account with a known initial password
  2. Have https://github.com/NU-ITS/LAPSforMac randomise the local admin password
  3. Have the https://github.com/kc9wwh/FileVaultEnableAdminAccount script generate secure tokens for both the Jamf management and local admin accounts.

I had to modify the standard FileVaultEnableAdminAccount script so that after it obtained a valid password from the currently logged in user it could then in a single script generate secure tokens for both the Jamf management account and the local admin account.

For doing this for the Jamf management account I also had to before the script ran reset the Jamf management password to a known value (to the FileVaultEnableAdminAccount script), for the local admin account it would read the LAPS extension attribute for the local admin password. After the FileVaultEnableAdminAccount script finishes the Jamf management account would have its password re-randomised again. (Using the built-in Jamf maintenance command.)

Unfortunately there seem to be some problems with these scripts in macOS Big Sur. One issue seems to relate to having Jamf display a dialog box asking the user for a password. I believe this is a known issue, I just need to (re)find the answer to that. There could however be additional Big Sur issues.

Bumping this as we're trying to use this same setup in Big Sur but so far its not working. Anyone have success getting it setup with BS?

Bump again. I also have this issue of the dialog box (which asks for the user's password) not popping up on Big Sur macs.

Terms & ConditionsCookie settingsAccessibility statement