State of the (Jamf) union - LAPS

New Contributor III

For those unaware LAPS is based on an approach originally created for Windows environments whereby Windows devices are configured with local admin level accounts for which the password is randomised and stored in Active Directory per device record. (This relies on devices being enrolled in to AD.)

This was and is a highly useful approach so that each device can have a unique admin password rather than all of them having identical passwords.

As such this technique would equally benefit a Mac environment and a number of equivalent solutions have been developed over the years. Some even store the password in AD also but many store the password in Jamf hence this discussion here. Again many techniques have been previously discussed here before.

However Apple being Apple 😦 this is more complex than it used to be or likely is for Windows.

The big issue these days is the use of Secure Tokens for FileVault2 access.

Firstly I will state that previously at a number of organisations over a number of years I have used the solution provided here - LAPSforMac

The Macs have been enrolled in to Jamf via DEP and (usually) in conjunction with using Jamf Connect. During enrolment a Jamf management account is created, a dedicated local admin account is created and (usually) via Jamf Connect the users local account is created. This will normally result in the Jamf management account having a Secure Token, the local user account also having a secure Token and the local admin account initially not having a secure token. I have previously solved this by having a Jamf policy which checks to see if the local admin account has a secure token and if not it runs a script which displays a dialog to the user asking the user to enter their credentials so as to use these via the script and then give the local admin account a secure token. This works fine even with macOS Ventura.

Thereafter the LAPSforMac scripts can randomise the local admin password and store it in a Jamf extension attribute and the secure token for the local admin account remains intact.

The LAPSforMac script is not being maintained anymore but I did 'fix' it to make it compatible with macOS Big Sur and later including macOS Ventura. However I do find it sometimes fails and this can result in the Jamf extension attribute and the individual Mac getting out of sync. There is a relatively easy way to get them back in sync and I think it should also be easy enough to add extra checking in the script so it tests the change before updating the extension attribute but I have not had time to sit down and re-write it to do this.

I am as it happens now in a new job and setting up a new Jamf system and therefore looking to again implement a LAPS solution and I am open minded to using an alternative approach. I have found a number of such solutions most of which seem unlike LAPSforMac to still be being maintained but I have not found a definitive statement regarding their support for secure tokens.

In particular see the following links.

and regarding Secure Tokens - 

My reading of Josh Miller's solution is that if the local admin account already has a secure token it takes steps to preserve it, but I see nothing to suggest it will add a secure token.

Now I feel that if you created the Jamf management account and used that also as the local admin account you could do this but it would mean that either you could not randomise it because Jamf itself needs to internally use that credential for Jamf processes or you might break it. However due to when the Jamf management account is created and how it should automatically have a secure token. Likewise the user account created during the enrolment and activation of FileVault will have a secure token, but past experience has shown that an additional local admin account does not automatically get a secure token. (Hence my using an additional script to get the user to authorise adding a secure token.)

So, my question here is whether anyone who has used an alternative LAPS solution knows of one that more automatically give a result of a dedicated Jamf management account (does not need a secure token), a dedicated local admin account (does need a secure token) and the users own local account which if course also needs a secure token?

Or, does anyone have advice on the best approach to create all three accounts i.e. Jamf management, local admin and user account and doing this in a way that all three automatically get secure tokens?

Note: It is increasingly common for Mac focused MDM solutions to have a built-in LAPS solution however Jamf whilst very powerful leaves all the hard work up to admins who have to keep re-inventing the wheel.


Contributor III

In my fleet, the JAMF Management account is randomized and there is no local admin account available for LAPS.

If the Call Center or Deskside Team needs to perform an elevated function on an end user's machine, they authenticate to Self Service and run a policy using JAMF's MakeMeAnAdmin script to elevate the end user's account temporarily.


For end users that are authorized power users, I deploy Privileges which lets them temporarily elevate their local account as needed.


Your approach is indeed a valid one and used by a fair proportion of admins. However as one example where it is less friendly (to admins), if a laptop has been returned, found, being repaired, whatever, the user password will not be known and then you may have to do a user password reset perhaps using the FileVault recovery key.

I prefer having a separate fully enabled local admin login so I do not have to bother the user - especially if they have left.

Each to his own. Clearly the number of different LAPS solutions that have been created indicates this is not an uncommon choice. 😊

Note: As I intend to use Jamf Connect to make it possible to create users as 'standard' level users I will also look at an elevated privilege solution like you describe for some of them to use.

Valued Contributor II

Sort of related topic: Another option for general admin management (including creating accounts on-the-fly ("break glass"), and aoutmatically promoting/demoting/reporting/loggin is Admin By Request. I love it. We are testing it on Mac, Win and Linux. 1 pane of glass to manage policies for 3 platforms. Nice.