Skip to main content

Note: A newer version of this article is available on the Jamf Blog.

 

Jamf added support for LAPS in April’s Jamf Pro 10.46.0 release.

 

What is LAPS?

LAPS is short for Local Administrator Password Solution. It was coined by Microsoft in May 2015 as a solution for automatically rotating passwords of shared IT administrator accounts on end users’ computers. Since then, it’s become a standard industry term used across platforms.

Desktop administrators have added shared IT admin accounts to their end users’ computers for decades for those times when they need to sit in front of a computer or remotely control it and log in. But this practice introduces a few major security problems:

  1. Typically, these accounts share the same username and password across computers. If the credentials are ever exposed to unauthorized persons, the entire fleet is vulnerable to attack.
  2. Multiple people know these shared IT admin credentials and they’re easy to reshare to anyone without any means of controlling access.
  3. Because multiple people know the credentials, end user privacy and sensitive data are at risk without any way to audit who and when someone uses them to access a computer.
  4. And if a desktop administrator leaves the organization, someone must change the credentials on all the computers and share the updated password with the remaining administrators.

LAPS solves these problems.

While Microsoft may have developed the LAPS workflow, Jamf Pro is using Apple’s technology in its implementation. Jamf Pro’s LAPS supports all recommended macOS versions listed in Jamf Pro’s System Requirements.

Let’s look at how to use LAPS with Jamf Pro. We’ll cover how to:

  • Define the admin account in a PreStage enrollment
  • Review and enable LAPS settings in Jamf Pro
  • Apply LAPS settings to a computer
  • Verify LAPS is applied to a computer
  • Retrieve the local admin username and password
  • Audit LAPS access
  • Disable LAPS

 

Define the admin account in a PreStage enrollment

Automated Device Enrollment must create the local admin account during enrollment.

When Automated Device Enrollment creates the local admin account, it becomes the sole managed Apple admin account. That means LAPS in Jamf Pro can only manage one local admin account.

Jamf Pro administrators define the name of this account in Computers > PreStage Enrollments. Each PreStage enrollment may have its own unique admin username, but computers are still limited to just one managed Apple admin account.

To configure a PreStage enrollment with a managed Apple admin account:

  1. Create a new PreStage enrollment or edit an existing PreStage enrollment.
  2. In the Account Settings payload, enable Create a local administrator account before the Setup Assistant.
  3. Set Username to something like “localadmin” or any single name without spaces.
  4. Set the Password and Verify Password fields to a known password. (Later, we’ll attempt to authenticate with the known password to verify whether LAPS has rotated it.)
  5. Choose whether to hide the account and whether to make it MDM-enabled. These settings don’t affect LAPS management.
  6. Scope and save the PreStage enrollment.

Computers already enrolled using an existing PreStage enrollment are eligible for LAPS management after a Jamf Pro administrator enables the feature.

 

Review and enable LAPS settings in Jamf Pro

In its initial release, LAPS in Jamf Pro is only available to configure and review via the Jamf Pro API. Jamf will later make LAPS available in the Jamf Pro GUI after refining its feature set. This doesn’t mean administrators need to learn scripting to use LAPS. They can do everything in Jamf Pro’s API pages.

Before setting LAPS, administrators should ensure their Jamf Pro account’s Privilege Set is set to “Administrator”. If the privilege set of their account is set to “Custom”, they should verify they have two new privileges enabled under the Privileges tab > Jamf Pro Server Actions:

  • View Local Admin Password
  • View Local Admin Password Audit History

Let’s see how LAPS is configured by default:

  1. Open Jamf Pro server in a web browser and append “/api” to the end of the URL (e.g. https://talkingmoose.jamfcloud.com/api).
  2. Click the Jamf Pro API’s View button.
  3. At the top of the Jamf Pro API page, provide a Jamf Pro username and password (with LAPS privileges) and click Authorize. The account is authorized for 30 minutes before needing to reauthorize.
  4. Scroll down and click local-admin-password to review its six new endpoints. (Older v1 endpoints may appear, but they’re deprecated and Jamf will remove them later.)
  5. Click GET /v2/local-admin-password/settings, click Try It Out, and click Execute.
  6. In the Responses section just below, locate the response body. It’ll display Jamf Pro’s current LAPS settings.

By default, LAPS is turned off (autoDeploymentEnabled is set to “false)”. When LAPS is enabled, It’ll rotate passwords on computers once every three months (autoRotationExpirationTime is set to “7776000” seconds). And it’ll rotate a computer’s managed Apple admin account password automatically one hour after it’s been viewed (passwordRotationTime is set to “3600” seconds).

Let’s turn on LAPS:

  1. Scroll down and click the next endpoint PUT /v2/local-admin-password/settings.
  2. Click Try It Out.
  3. The LAPS settings to update field displays the current settings. It’s editable.
  4. To enable LAPS, set both autoDeployEnabled and autoRotateEnabled to “true”. To adjust the frequency of each setting, enter new values in seconds.
  5. Click Execute.
  6. The response body shows the updated settings. Jamf Pro will rotate a computer’s managed Apple admin account password 15 minutes (900 seconds) after viewing it, and it will automatically rotate all passwords every day (86400 seconds).

 

Apply LAPS settings to a computer

Before Jamf Pro applies its LAPS settings, computers must submit an inventory report. By default, they submit inventory once per week.

To force an inventory update on a test computer, open its Terminal application and run the following command:

sudo jamf recon

Alternatively, create a new Jamf Pro policy and enable Update Inventory in the Maintenance payload. In the General payload, set Trigger to “Recurring Check-in” and Execution Frequency to “Once per computer”. Scope the policy to a test computer and save. The computer will update its inventory as soon as it checks in with Jamf Pro. (This is also a quick way to apply LAPS to a group of computers or an entire fleet.)

 

Verify LAPS is applied to a computer

How does an administrator know LAPS is working?

Jamf Pro uses the Apple Push Notification service (APNs) command SetAutoAdminPassword to change the account’s password. Within seconds of submitting an inventory report, Jamf Pro should send the command to the computer and receive a response.

To verify the command, click Computers > Search Inventory. Click the computer name to view its inventory. Then click History > Management History. The SetAutoAdminPassword command should appear under Completed Commands.

Another way to verify Jamf Pro applied LAPS to a computer is to test authenticating to the local admin account. The easiest way to do this is to use Terminal again to attempt to log in as the account. Run the su (substitute user) command on the computer using the name of the managed Apple admin account:

su localadmin

When prompted, enter its known password. If Terminal responds with “Sorry”, the known password is no longer valid, indicating Jamf Pro has changed it.

Note: The computer itself isn’t aware it’s being managed by LAPS. As far as it knows, it received a command telling it to change the password for the managed Apple admin account.

 

Retrieve the local admin username and password

Viewing the current LAPS password requires putting a few pieces together.

First, the Jamf Pro administrator must retrieve the computer’s management ID. This is an ID created at the time of enrollment and it’s unique to each computer. It’s only stored in Jamf Pro and only visible using the Jamf Pro API.

  1. In the computer’s inventory record in Jamf Pro, click Inventory > General and note the Jamf Pro Computer ID. (This is not the management ID, but computer ID helps identify the computer next.)
  2. Return to the Jamf Pro API by appending “/api” to the end of the Jamf Pro server’s URL and reauthorize if necessary.
  3. Scroll down and click computer-inventory to view its endpoints.
  4. Click GET /v1/computers-inventory-detail/{id}, click Try It Out, and enter the Jamf Pro computer ID from inventory.
  5. Click Execute.
  6. In the Responses section just below, locate the response body. It’ll display information about the computer.
  7. Scroll down the response body slightly and locate managementId. Copy its value.
  8. Scroll down the Jamf Pro API page back to local-admin-password.
  9. Click GET /v2/local-admin-password/{clientManagementId}/accounts, click Try It Out, and paste the management ID into the clientManagementId field.
  10. Click Execute.
  11. In the Responses section just below, locate the response body. It’ll display the username of the managed Apple admin account. (This is the same admin account username from the PreStage enrollment.)
  12. To retrieve the LAPS account’s password, scroll up the Jamf Pro API page just slightly.
  13. Click GET /v2/local-admin-password/{clientManagementId}/account/{username}/password, click Try It Out, and paste the management ID into the clientManagementId field, and enter the local admin account username in the username field.
  14. Click Execute.
  15. In the Responses section just below, locate the response body. It’ll display the password of the managed Apple admin account.

Remember, this password is valid only for the length of time specified for passwordRotationTime when enabling LAPs. Work quickly.

 

Audit LAPS access

Protecting data end user privacy requires knowing who accessed a password and when. Jamf Pro’s LAPS implementation provides auditing to disclose this information.

For successful auditing, Jamf Pro administrators themselves must never use a shared user account when logging into the server. Instead, one administrator should set a long and complex password that only one person knows and keeps in a secure location. (Consider also enabling Jamf Pro’s Password Policy feature to enable that account for password recovery, just in case.) Then each server administrator should use a uniquely identifiable username with necessary privileges.

To audit who’s accessed a computer’s LAPS-managed password:

  1. Return to the Jamf Pro API by appending “/api” to the end of the Jamf Pro server’s URL and reauthorize if necessary.
  2. Scroll down and click computer-inventory to view its endpoints.
  3. Click GET /v1/computers-inventory-detail/{id}, click Try It Out, and enter the Jamf Pro computer ID from inventory.
  4. Click Execute.
  5. In the Responses section just below, locate the response body. It’ll display information about the computer.
  6. Scroll down the response body slightly and locate managementId. Copy its value.
  7. To audit who’s accessed a computer’s LAPS password, scroll down and click local-admin-password to view its endpoints.
  8. Click GET /v2/local-admin-password/{clientManagementId}/account/{username}/audit, click Try It Out, paste the management ID into the clientManagementId field, and enter the local admin account username in the username field.
  9. Click Execute.
  10. In the Responses section just below, locate the response body. It’ll display the audit history for the LAPS account including the name of the accounts viewing the passwords, the passwords themselves, and when the Jamf Pro administrator viewed them.

 

Disable LAPS

Jamf Pro’s LAPS feature is global. It affects all computers with a local admin account created during Automated Device Enrollment. Therefore, administrators can’t easily apply LAPS settings to just a subset of computers.

A desktop administrator could disable LAPS for an existing computer by deleting the managed Apple admin account. Recreating the account with the same name won’t reenable it for LAPS because it’ll have a different UUID.

To disable LAPS globally, the Jamf Pro administrator should follow a specific order of operations to keep from losing access to the local admin account:

  1. Return to the Jamf Pro API by appending “/api” to the end of the Jamf Pro server’s URL and reauthorize if necessary.
  2. Scroll down and click local-admin-password to view its endpoints.
  3. Click PUT /v2/local-admin-password/settings, and click Try It Out.
  4. The LAPS settings to update field displays the current settings.
  5. Set autoRotateEnabled to false to disable and further password changes.

Keep in mind LAPS can’t restore the original local admin account passwords on computers and each will have a unique password. While Jamf Pro offers a PUT /v2/local-admin-password/{clientManagement}/set-password endpoint, it’s only available to set one computer at a time. The Jamf Pro administrator will need to create a Jamf Pro API script to set every computer password using LAPS. Only after ensuring all passwords are changed to known passwords should the administrator turn off LAPS:

  1. Return to the Jamf Pro API by appending “/api” to the end of the Jamf Pro server’s URL and reauthorize if necessary.
  2. Scroll down and click local-admin-password to view its endpoints.
  3. Click PUT /v2/local-admin-password/settings, and click Try It Out.
  4. Set autoDeployEnabled to false to disable LAPS.
  5. Click Execute.

 

Testing

Now is the time for customers to test LAPS and give Jamf feedback while it’s in its early stages. Any customer can register for the Jamf Pro Customer Feedback Program and gain access to the private beta forums. Betas are a great opportunity to see what’s coming next and test critical workflows before Jamf releases new versions. Customers planning to use LAPS in their environments should participate.

Administrators should carefully consider whether LAPS is a fit for their environment. Ideally, each Jamf Pro administrator’s account is secured using some combination of a strong password policy, Single Sign-On with a randomized failover URL, and limited access to other administrators' account settings. And while products like Jamf Connect and Jamf Pro’s LAPS are compatible with each other, both can offer secure and auditable admin access to a computer. Implement one or the other for the sake of simplicity and ease of auditing.

Jamf Cloud customers should test LAPS in their free-of-charge Jamf Cloud sandbox instances before enabling LAPS on their production server. Customers can create their sandbox instances in their Jamf Account or by contacting their Customer Success Manager.

And it’s worth repeating that LAPS is an API-first feature. That means it’s only available in the API until Jamf has completed the LAPS feature set. Later, it should move to the Jamf Pro GUI for those who aren’t comfortable with the API.

@talkingmoose, Thank you for this Tech Thought to help as we can look at deploying LAPS in JAMF and we consider moving away from binding to AD. 

When a Local administrator account is create before the Setup Assistant for computers enrolled with this PreStage enrollment, does checking Hide managed administrator account in Users & Groups create problems?  If if does create a issue is there a way to unhide the account post enrollment?

Will this Admin account get a secure token and generated a bootstrap token to be escrowed in JAMF, and be this account be Volume owner?  Is the a way to give this Admin account a secure token make it a volume owner so I can git rid of the other local admin accounts?

Currently we do a light touch were the service desk enrolls the computer and creates the first admin account, before handing the device over to the Active directory end user and I would like to move away from this practice. 

@burdett, glad to hear this will help!

LAPS has no influence over whether the managed Apple admin account created during Automated Device Enrollment is hidden, MDM-enabled, receives a secure token, or is made a volume owner. It also doesn’t care about any of these properties when rotating a password. Apple’s guidance sill applies.

Never enable a shared IT admin account for FileVault. It's one set of credentials that allows access to your entire fleet if they’re ever shared or stolen. If you use LAPS, it won’t rotate the FileVault password.

Hi, 

Thanks for the clear tutorial :)

I have a question : when devices are already enrolled since months or years through DEP/MDM, how the apple managed account should be created ?

I change my prestage enrollment configuration by adding an account, but he is never created during the phases described in your tuto.

Any help or advice would be appreciate.

Kind regards.

@alewko you could try creating a policy and using the "Local Accounts" payload to create the account on devices that are missing it. I started setting up something like that but never had to use it yet. 

@bcbackes well, already tried but not working. The strange behavior : LAPS is enabled, but for all my devices when I check into the API manager, 0 accounts are shown compatible with LAPS.

I will check it on Monday, maybe an issue related to an update time needed on jamf's backoffice side 

@alewko, the managed Apple admin account is only created during Automated Device Enrollment. You’ll specify that account in a Jamf Pro PreStage enrollment in the Account Settings payload.

Run this command on the computer to verify the account exists:

cat /var/db/ConfigurationProfiles/Settings/.setupUser

You should see a key called shortName and it should have the value of your admin account. If you don’t see this, your Mac either your Mac wasn’t enrolled or it didn’t create the account during Automated Device Enrollment. That’s not part of LAPS, so you’ll need to investigate that issue separately.

We are currently using https://github.com/joshua-d-miller/macOSLAPS.

This comes in useful as password are stored in AD and users who do not have access to JSS can lookup passwords using the macOSLAPS app.  

What would be nice is if we could target any additional local admin account with JAMF Pros LAPS not just the management account.

Attempted to implement this and I have a large portion of our prestage enrolled fleet that returns 0 accounts. If I SSH into one of them and run 'cat /var/db/ConfigurationProfiles/Settings/.setupUser' I do see the account that was created, reflecting the prestage profile. Any guidance on troubleshooting this?

@gsoft, have you enabled LAPS in Jamf Pro (set autoDeployEnabled to “true”) and then updated inventory for these Macs using a policy or manually running “sudo jamf recon”?

That’s all it should take to start reporting.

I enabled LAPS with the put request, verified that the settings took with a fresh get request, and then ran a policy on our PreStaged computer smart group to force an inventory update. Even after all that only 14 of our 44 PreStage computers return an account for LAPS. Choosing a few random computers and checking the .setupUser file shows that the corresponding local admin account was created.

@talkingmoose thanks for the great write up, as always!

I saw that HCS Technology Group also put up a guide on implementing LAPS the same way. However, they did have a warning that there is a known issue with PreStage Enrollments that include a configuration profile. (@gsoft this may be the same issue you're experiencing with those other 30 computers.)

Here is what they said in their guide:

Known LAPS Issues: Jamf has an open issue for Mac computers enrolled through PreStage Enrollments that include a configuration profile. Jamf Pro will not enable LAPS for these computers unless their computer record is deleted and the computer is re-enrolled into the Jamf Pro server. Jamf will address this issue in an upcoming release. Settings won't apply until a computer submits an inventory update and then a check-in to Jamf Pro. To force settings immediately on a computer after enabling LAPS, run the following command: sudo jamf recon

I can't imagine how long this workaround would take for organizations that have hundreds (or even thousands!) of computers!

As part of my imaging/deployment workflow I sign into my local administrator account immediately after the automatic enrollment process is complete. This ensures I have a bootstrap token escrowed, and I have a SetupYourMac policy setup to run that executes the basic computer configuration while I'm logged in under that account, and then restarts once the core policies are all executed successfully. 

If I enable LAPS at what point does it change the password of the local administrator account? If it waits until the first inventory update I should be fine with my workflow - but is there any chance that LAPS will rotate the local admin password as the local admin account is created?

Basically - I want to be able to image labs of computers without having to look up LAPS passwords for each individual machine.

@JCMBowman, it’s going to be fairly immediate after enrolling. You might consider creating a policy to add a temporary “setup” account with a known password and then another to remove it when you’re done.

Any idea if it can change the password, if the password has been changed by other means, like with macOSLAPS (https://github.com/joshua-d-miller/macOSLAPS.) ? I deployed this not too long ago, and it is working fine, but I would like to transition to this in the future.

@vagabon, I can’t confirm without testing, but the password change is done using an Apple command sent to the computer from Jamf Pro. I don’t believe it requires knowledge of the existing password because the account is already a managed Apple admin account on a Jamf Pro managed computer.

@talkingmoose your blogs are always incredible!!

Excellent tutorial!  We have already begun to deploy, and it works like a charm.

 

Thanks for the hard work and write-up!

 

Great document, William - thanks!

A few questions:

1 Instead of using a PreStage Admin account, can we use the User-Initiated account (AKA the 'Jamf Management' account)? Will LAPS work with this account?

2 When choosing to hide the PreStage admin account, it only hides it from the Users & Groups GUI pane. The admin's homedir is located in /Users and therefore can be seen by any casual user. Why is this homedir not in /var or other hidden dir?

In contrast, the User-Inititated account (AKA  the 'Jamf Management' account) DOES have a hidden homedir in /var (not /Users) Any idea why these 2 accounts differ?

3 Does LAPS care what UUID the PreStage admin account has (example 501, 502 etc)?
I'm asking because at my org, I have both a PreStage admin account and a User-Inititated admin account. Typically the User-Initiated admin gets created BEFORE the PreStage and therefore gets UUID 501 and the PreStage admin gets UUID 502. But Im planning on disabling the User-Inititated admin account (legacy workflows removed and I no longer require the account) and at that point, the PreStage admin will get UUID 501 I'm assuming.

4 Does a PreStage admin account get a Secure Token?

Is there a known extension attribute we can use to find the date of  SetAutoAdminPassword ?

@dstranathan, some good questions.

1. Jamf Pro is using Apple’s mechanism for creating the “managed Apple admin account”. Apple only allows for one managed admin account, and they require it be created via Automated Device Enrollment. I believe the jamf binary creates the Jamf management and all other accounts, therefore they don’t qualify.

2. Here’s the spec on the AutoSetupAdminAccounts key from Apple. It doesn’t seem to allow for choosing a path for the home folder. That might be a RADAR you’ll want to file with Apple.

And before you think “AutoSetupAdminAccounts" (plural!), this page describes only the first element will be used and other accounts ignored.

3. I don’t think Jamf Pro cares what the local user ID of the managed Apple admin account is, however, I think it’s likely to be 501 since it’s getting created as part of Automated Device Enrollment before all else.

4. My understanding is only accounts actually logging in to a Mac at the login window (not command line) can get a secure token. The first local account to log in will be the only local account with a secure token. A token can be issued to another local account, but then the first will lose its token. That’s why the better practice is to let end users go through Automated Device Enrollment themselves, so they can be the first to log in and get the token.

Any number of directory (Active Directory) accounts may receive a secure token.

And newer macOS versions that support a bootstrap token make user secure tokens a moot point. Only an MDM can get the bootstrap token and then it can do everything an account with a secure token can do.

@burdett, I made this extension attribute a while back for some internal testing:

Managed Apple Admin

#!/bin/zsh

if [[ -f "/var/db/ConfigurationProfiles/Settings/.setupUser" ]]; then
    lapsUsername=$( /usr/libexec/PlistBuddy -c "Print :Users:0:shortName" /var/db/ConfigurationProfiles/Settings/.setupUser )
    echo "<result>$lapsUsername</result>"
else
    echo "<result>Not configured</result>"
fi

Thanks William! 

The EA works great for getting the DEP AutoAdmin name.    What I was looking for was an extension attribute to confirm / validate that password rotation was running and create a smart group from that.   

Once I have a confirm / validate that password rotation is running I want to have a policy to remove the "shared IT admin accounts" on our end users’ computers.


Is there a way to create a EA grab the date from SetAutoAdminPassword from the computer inventory -> History -> Management History ->SetAutoAdminPassword: 05/22/2023 at 10:57 PM 

 

 

I had this working a couple of weeks ago in a test environment and decided to check again today to make sure it is still working but I have tried entering in the password the API shows and it won't let me sign in with the local admin account and password shown. Terminal shows Sorry when I try su localadmin with password. I even waited an hour for the password to change and tried the new one still can't sign in. Any thoughts why I not able to sign in now after it has been working previously. 

@burdett This should work to get the last date/time the LAPS password was changed from the computer itself. Jamf Pro can’t create extension attributes from its own data.

Managed Apple admin password last set time

#!/bin/zsh # get LAPS account username lapsUsername=$( /usr/libexec/PlistBuddy -c "Print :Users:0:shortName" /var/db/ConfigurationProfiles/Settings/.setupUser ) # read LAPS account for password information userPasswordInfo=$( /usr/bin/dscl . read "/Users/$lapsUsername" accountPolicyData | /usr/bin/tail -n +4 ) # extract Unix epoch date from account password information passwordChangeDateEpoch=$( /usr/bin/xpath -e '//key[text()="passwordLastSetTime"]/following-sibling::real[1]/text()' 2>/dev/null <<< "$userPasswordInfo" ) # convert Unix epoch date to ISO 8601 standard format passwordChangeDate=$( /bin/date -j -f "%s" "$passwordChangeDateEpoch" +"%F %T" 2>/dev/null ) # report value to Jamf Pro according to computer's local time zone echo "<result>$passwordChangeDate</result>"

@talkingmoose If I want to get the managementID in a script. How do I get the info?

Terms & ConditionsCookie settingsAccessibility statement