How to Securely Manage Local Admin Passwords with Jamf Pro and LAPS

[talkingmoose]

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.

[burdett]

@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. 

[talkingmoose]

@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.

[alewko]

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.

[bcbackes]

@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. 

[alewko]

@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 

[talkingmoose]

@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.

[nicholi]

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.

[gsoft]

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?

[talkingmoose]

@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.

[gsoft]

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.

[beegee]

@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!

[JCMBowman]

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.

[talkingmoose]

@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.

[vagabon]

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.

[talkingmoose]

@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.

[rastogisagar123]

@talkingmoose your blogs are always incredible!!

[zerocounts]

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

Thanks for the hard work and write-up!

[dstranathan]

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?

[burdett]

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

[talkingmoose]

@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.

[talkingmoose]

@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

[burdett]

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 

[glsmith]

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. 

[talkingmoose]

@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>"

[YanW]

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

[talkingmoose]

@YanW, I have a sample script I’ve been using for testing here:

https://gist.github.com/talkingmoose/fe84537a3a6951caa7fcb767d15ee3e6

I wrote it a little experimentally. Look for the "get computer management ID” section, which references the apiGET function earlier in the script.

[YanW]

@talkingmoose thank you

[BagaleAnil]

@talkingmoose I have setup LAPS and it's working fine for me, but I want to reduce the LAPS password length from 30 characters to 12 characters,

It looks like we are using the FileVault key to the LAPS account, Please let me know if we can do that in API or JAMF.

[talkingmoose]

@BagaleAnil You’ll probably be interested in upvoting this feature request:

Give the new LAPS feature the ability to create passwords with modifiable complexity

Also, Jamf Pro’s LAPS feature doesn’t manage the FileVault password for the account. I recommend not enabling the account for FileVault. You should already have the computer’s personal recovery key escrowed and should use it instead for those times when the computer is in the hands of IT but powered off.

[dan-snelson]

Thanks, @talkingmoose!

Shameless self-promotion:

Jamf Pro LAPS: Retrieving Password via Terminal

[Double_G]

hey @dan-snelson 

Any suggestions on why i keep having this error when i run the lapss from terminal?

All the information shows up, except the password. Username matches with the admin local account, and was deployed via prestage. 

[dan-snelson]

@Double_G:

The function includes a number of `echo` statements which are commented-out. 

I recommend enabling those statements and see if that helps pinpoint where things are going sideways. 

(You’re welcome to DM me on the MacAdmins Slack: @dan-snelson.)

Thanks. 

[perryd84]

Nice write up!!

I've made a nice gui dialog box for configuring JAMF LAPS and a nice gui for viewing the LAPS password.
They are up on my github and might be of use to some of you?
https://github.com/PezzaD84/JAMFLAPS-Configurator
https://github.com/PezzaD84/JAMF-LAPS-UI

Just to note these are very early versions so they might have little qwerks.

[dstranathan]

This article states that PreStage can be used for management but fails to mention that LAPS will break the account’s Secure Token and thus CANT be used to manage FV2 and starting with Jamf Pro 10.49 Jamf even recommends NOT using this account for FV2 related activities.

But what’s the point of an IT admin account if it can’t be used for tasks that require a Secure Token? Things like Software Update, running the sysadminctl command and FV2 are critical things that an IT department might need an administrator account with a Secure Token for. But according to Jamf it won’t work because the token is corrupted after LAPS rotation.

Thoughts?

[perryd84]

@dstranathan I also saw these notes and did have the same thoughts. The JAMF Documentation also mentions not to log in with the management account or use it for admin tasks and recommends creating a separate local admin account for admin tasks. This comment makes the use of JAMF LAPS a little redundant to me?!

I came across these same issues when making my own LAPS solution where the account isn't FV enabled but this doesn't limit the account to not fully administer the device. The account gets a secure token automatically so it can run software updates, log in and run any admin tasks. The FV drawback can be bypassed by logging in with the recovery key and then the LAPS account can do it's thing.

I've thought of ways to automatically enable FV but with lot's of devices being deployed as zero-touch and the end user becoming the only FV enabled user it makes this task hard as you would need to get the users password at some point.

[dstranathan]

This doc from WIllaim got my LAPS juices flowing back in April and was the genesis of why I decided to move from a UIE Jamf Management admin account to a PreStage admin account in the first place. In fact, I called a meeting with Jamf to start planning my FV2 project (which is supposed to go live in October) based on ideas I got from this article. But the Jamf doc fails to mention 2 critical facts:

-The PreStage admin account can't be used for FV2 etc because the Secure Token will be killed after LAPS rotation.

-The UIE Jamf Management admin account can also be used with LAPS.


@perryd84 I was slo told by Jamf (for 7+ years!) to never use the UIE Jamf Management admin account for general IT tasks like SSH, ARD etc. This was causing issues at my org because we have a policy to not have more than 1 IT account per Mac for security. This is another reason I moved to a PreStage account in the first place. Now I might end up needing 2 or more going into 2024. This is crazy. 

[dan_berlyoung]

Hey @talkingmoose , I just saw your presentation at JNUC. Very good! Well organized and presented.

I manage about 800 systems and as part of our standard configuration have the local admin account already created. We use this account to preform administration functions on the systems whenever necessary.

I would like to test out the LAPS system but I don't think I can as soon as I activate it, it will start rotating the password on all my systems. Correct?

How would you go about setting up a test environment so we can develop and test deploying LAPS to our fleet? Should we ignore Jamf's sytem and use yours (macOSLAPS)?

Thanks a ton!!! 

p.s. Love your handle. Is it a throwback to antlered friend that used to inhabit my Mac Plus waaaay too many years ago?

[talkingmoose]

@Dan, thanks so much for the kudos on the presentation! I have to say Starbucks not only upsized my drink later that day but the next day, so I was pretty well caffeinated later on. ;-P

Jamf Pro’s LAPS story is still evolving and you may have seen there are two accounts that it may affect — the managed Apple admin account created during Automated Device Enrollment (MDM account) and the Jamf management account created from the settings in User-Initiated Enrollment (JMF account).

For years we’ve been encouraging customers not to use the JMF account for their own purposes but to leave it for only Jamf Pro to use. As soon as your server updates to Jamf Pro 10.49.0, the JMF account is automatically put under LAPS. The only other settings you can test are the rotation frequency and the delay between someone viewing the password and the automatic rotation.

There’s more work to do with the MDM account, but if you’re using that for your own needs, I’d make sure to begin transitioning now to a different account you can create using a policy. (Or consider not using a shared IT admin account at all, which is much more secure.)

If you’re concerned about testing, ask your Customer Success Manager at Jamf for a Jamf Cloud sandbox instance. It’s free. You can enroll a Mac and test there and see how it’s going to affect you.

When the development seems to have settled down, I’m hoping to put out a revised article explaining both types of LAPS and walking through how to prepare using them in production.

And, yes! Talking Moose from Bob Levitus’s Stupid Mac Tricks!

[sdunbar]

@talkingmoose Hi

We have the situation where we have used the same username for the management account created in User-Initiated Enrollment settings and a managed local administrator account created in a PreStage enrollment (which was never an issue until LAPS has come online).

So we have some machines showing in Jamf as Managed by: administrator, administrator  This is confirmed when looking in the API which shows 2 LAPS capable accounts (JMF and MDM) both with the same username. When trying to get the LAPS password for administrator if fails, as you would expect.

I have deleted the administrator account (after setting a new local account with admin rights), but it is still showing in the API with the 2 LAPS administrator accounts (and showing in Jamf as Managed by: administrator, administrator).

So is there a way of removing, or renaming one of these accounts to solve this issue, before we enable LAPS?

I would like to avoid the rebuilding of those machines if at all possible.

[talkingmoose]

@sdunbar Currently, using the same username name for both the MDM LAPS account and JMF LAPS account puts you in an “unknown” state. Jamf Pro can’t have two processes managing one account.

My recommendation is to immediately change the username for one or the other. It doesn’t matter which and the change won’t apply until you re-enroll a machine.

Next, pick one LAPS method (MDM via the PreStage Enrollment or JMF via User-Initiated Enrollment) as your preferred LAPS management method. MDM LAPS accounts are managed using Apple’s technology and JMF is managed using Jamf’s technology. For you, I suggest changing the JMF account name in UIE and using the JMF LAPS account.

You can then send a /usr/local/bin/jamf enroll -noPolicy command in a policy (Files and Processes > Execute Command) to re-enroll computers and apply the updated LAPS management account.

I haven’t tested this workflow to re-enroll to change the LAPS account, so be sure to test yourself on a single computer or small group of computers and verify the results first.

Finally, if you choose to implement some sort of shared IT admin account that’s known to multiple engineers (I strongly recommend not doing this) then use a policy to create that account going forward.

[sdunbar]

@talkingmoose

That is great, much appreciated. 

I'll give that a go and see how I get on. We have only used the shared IT admin a/c as a temporary measure until we get this sorted.

Many thanks

[perryd84]

If anyone is using JAMF LAPS I've made some updates to my LAPS UI tool which you can find here https://github.com/PezzaD84/JAMF-LAPS-UI

Just makes viewing the LAPS Password a little more user friendly. You can scope this tool to your help desk etc and then they don't need JAMF or API access to view the password.

[dstranathan]

Any idea when PreStage accounts will be required to use LAPS?  

The Jamf Pro 11 Deprecation doc mentions it but no dates are provided. Why not?

My techs require a PreStage account to deploy new Macs. Enabling LAPS at enrollment time will break all my workflows. I'd like to request to Jamf devs that the PreStage admin get LAPS at a time window that I control as an admin - not when Jamf dictates.

[RichClic]

Hi @talkingmoose @sdunbar ,

Have try the method to fix the same username for the management account created in User-Initiated Enrollment settings and a managed local administrator account created in a PreStage enrollment by renaming the user for the User-Initiated Enrollment but when I run the commande I got this error message:

sudo /usr/local/bin/jamf enroll -noPolicy        

There is an error in your syntax.

Error: Valid credentials are required to enroll this computer. Use either the -invitation or the -prompt option to authenticate.

Have also try re-enroll with this command using my jamf admin credential

sudo /usr/local/bin/jamf enroll -prompt -noPolicy

JSS Username:jamfadmin

JSS Password: ***

But I'm still not able to see the laps admin password from the Jamf API:

Did anyone has been able to fix this situation ?

Many thanks.

[sdunbar]

Hi @RichClic 

I had a similar issue, with being prompted for credentials. I got the re-enrolment to work (for me) using  profiles renew -type enrollment 

One issue I have got however, is that if I try to run the command via a policy it does not pop up with the window asking to confirm the re-enrolment, but if run from Self Service it works fine. So I having difficulties getting it done with minimal user interaction.

If the re-enrolment fails I have found the machine can end up being unmanaged (but I got it managed again using the Jamf API to Redeploy the Jamf Management Framework).

Hope that helps.

[Wgphoto]

This should be a much more simple process, and JAMF shouldn't be forcing this on anyone until it is fully functional within the Jamf Pro GUI, at the earliest. Even then, it should be a customer choice.

https://learn.jamf.com/bundle/jamf-pro-release-notes-current/page/Deprecations_and_Removals.html

[dstranathan]

Just chiming in on a related topic and linking to recent changes...

According to Jamf from this Jamf Nation community link PreStage admin accounts will continue to be able to be set with a static password for the remainder of 2024.

As of Jamf Pro 11.3, admins can now view LAPS passwords from Inventory section of a computer record. See this video overview.

[dstranathan]

Ugh, wait: This Jamf Pro 11.3 document (dated yesterday Feb 19 2024) says that LAPS WILL BE REQUIRED for PreStage account. What is going on...?

[ITMan]

@perryd84 , how do you get encoded API credentials ? 

[perryd84]

@ITMan You can use this little script here 

If you put in your API account username and password the script will echo out an encoded string you can use to get the bearer token from JAMF. I'm looking to change the authentication method to use the new API roles feature in the next release.