Jamf Pro LAPS, FileVault and Administrator Level accounts

[user-BqBTAgwquG]

The Administrator account created in the PreStage Enrollment does not have the ability to unlock the disk via FileVault after the password is rotated via Jamf Pro LAPS, and this is causing issues for our techs. If they log in to the system, perform some operations, and then return to the computer later, they find they are not able to log in as Administrator at the FileVault Login screen.

However if we create an additional administrator account i.e. ‘jamfadmin’, and manually enable it for FileVault, that password is viewable in the Jamf Pro web UI and rotated regularly/after viewing. Because Administrator is the first account created and the one with the initial Secure Token, we need that one to be always and easily accessible.

We are a long way off zero-touch due to ageing infrastructure that will hopefully be replaced in the coming years, but in the meantime we require the ability to have our techs log in with an administrator level account at the FileVault login screen, and be able to recall the LAPsed password easily going forward in case the user runs into issues/needs an operation performing on the console itself. Our security team would like us to use LAPS for our Administrator Level accounts and from a personal POV I always like to use the built-in Jamf Pro functionality wherever possible. Before Jamf Pro LAPS came along we used macOSLAPS, but we always found that to be very hit and miss in terms of storing passwords in AD (yes we still bind to AD!)

Does anyone have a similar workflow? Is there a way of having our techs log in as Administrator first, doing any final checks and setup, then handing over to the customer - but then being confident that they can log in with the same account sometime in the future?

[AJPinto]

Unfortunately, I don't think you are going to find much luck without a significant overhaul to your process. You guys are operating with a very much late 2000's workflow in the mid 2020's. Needing modern security processes, while using nearly 15-year-old device management processes will not lead to anywhere good.

We have similar requirements but have moved away from domain binding as well as techs performing any administrative functions on the local device. We are fully 0-touch enabled, but some of our techs still prefer hands on configurations which is fine. FileVault is enabled by the end user like Apple intends, and if a tech ever needed to bypass FileVault they use the FileVault Recovery key (which will break account syncing on mobile accounts). Pretty much any administrative action that is needed is performed with Jamf usually with Self Service and by the user, and if it's one off we use an EPM tool to escalate the workflow or grant temporary admin access to the user (incredibly rare). 

[stevewood]

This is our tech article on the implementation of LAPS. In it you will find a section detailing what each of the two LAPS accounts can do: the PreStage admin account and the JMF (Jamf Management Framework) account. The JMF account is the only one of the two that can be enabled for SecureToken which can then be enabled for FileVault.

If you need your techs to be able to unlock FileVault, the more secure workflow would be to utilize the FileVault recovery key anytime your techs need to unlock a volume. You can then have a workflow that prompts the user to spin the PRK on their next login or at some specific time, like the next day or something.

[mm2270]

Use the Individual FileVault Recovery Key to get into your Macs. That's one of the reasons it's there, and doesn't require using local accounts with rotating or static passwords that can be lost, inaccurate or just plain not work like you've found.