I took a look at this. It's good work, thanks for putting it together.

But one piece of advice. You should mention in your notes on github that the solution specifically uses swiftDialog for the UI. I see in your script you have a section where it downloads the latest version of swiftDialog if needed, but you can't assume every environment will be able to do this. For example, I work at a bank, and so, highly regulated environment. Github is blocked for many users (I have access to it, and so do some others), and also we use an authenticated web proxy, for which github is not one of the excluded sites, so all curl commands must be preceded with a --proxy <proxyaddress> string for curl to work at all.

Just some things to think about. As it is, for some people your solution may not work since they may not be able to auto download swiftDialog if it needs to do that. They can always pre-deploy swiftDialog of course to meet that requirement. If it's mentioned in your notes, others will know what they need to do to get it to work.

I took a look at this. It's good work, thanks for putting it together.

But one piece of advice. You should mention in your notes on github that the solution specifically uses swiftDialog for the UI. I see in your script you have a section where it downloads the latest version of swiftDialog if needed, but you can't assume every environment will be able to do this. For example, I work at a bank, and so, highly regulated environment. Github is blocked for many users (I have access to it, and so do some others), and also we use an authenticated web proxy, for which github is not one of the excluded sites, so all curl commands must be preceded with a --proxy <proxyaddress> string for curl to work at all.

Just some things to think about. As it is, for some people your solution may not work since they may not be able to auto download swiftDialog if it needs to do that. They can always pre-deploy swiftDialog of course to meet that requirement. If it's mentioned in your notes, others will know what they need to do to get it to work.

Thanks for the feedback.

As stated it's very early release and I guess if admins in highly restricted environments need to use apps like swift dialog then these can be pre-deployed in a secure way and the scripts can be tweaked.

The notes on the GitHub pages are very basic at the moment as it is in a very early version and I haven't had a chance to detail every aspect on GitHub yet.

Hopefully the tools were of some use at least regardless of the security hurdles?

great point.. with how things are with supply chain attacks.. we don't allow any remote ingest of code or pkg or ..anything ... not matter where or who.. (and im surprised some people think this is acceptable) 

@perryd84 great work though.. I've done a code review all all good.. now to have some time to test.

my only other take is jamf will roll a GUI for this pretty soon ( maybe ) so.. keep that in mind on your dev time on this.. 😎

Thanks for the feedback.

As stated it's very early release and I guess if admins in highly restricted environments need to use apps like swift dialog then these can be pre-deployed in a secure way and the scripts can be tweaked.

The notes on the GitHub pages are very basic at the moment as it is in a very early version and I haven't had a chance to detail every aspect on GitHub yet.

Hopefully the tools were of some use at least regardless of the security hurdles?

Yes, all good. You saved me from doing some of this work myself. I've had it on my "to-do" list since Jamf introduced this new LAPS solution. I may make a few modifications to it to fit my environment.

Thanks for sharing it with us, I really like the LAPS Configurator tool.

My noob question for this is, will this impact the existing prestage-configured admin account(s)? 

@jobscommasteve my LAPS solution doesn't touch existing accounts or the JAMF management accounts. JAMF LAPS however will take control of your Pre-stage and user initiated management accounts. By default since 11.3 JAMF LAPS is enabled by default on user enrolled devices.

Hi Perry, have tried to implement your solution and everything is working awesome except for one thing.  I have the password to rotate after 5 minutes, but thats not happening.

Thx in advance!

Hi @vcasiero 

Is the password not rotating on a remote machine? Thats unfortunately a limitation of the solution at the moment. The rotation of the password after being viewed, is limited to the device viewing the password. So for example if you gave a Dev user access to the decoder app on their device, the password would rotate after 5min.
I'm currently looking at some of the new DDM features which will hopefully allow devices to call JAMF for a policy update rather than waiting for a check-in.

The password isnt rotating on my test machine, so it would be the one that I ran the decoder on via self service.  It only rotated after the machine ran the daily "cycle" policy that I setup.

Can you check to see if you can see this LaunchD file after decoding the password /Library/LaunchDaemons/com.LAPS.triggerCycle.plist
If it is there can you share the contents please?

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>Label</key>
<string>com.LAPS.triggerCycle.plist</string>
</dict>
</plist>

***the timestamp of that file changed to the time when I just decoded the pswd again

sorry, contents changed:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>Label</key>
<string>com.LAPS.triggerCycle.plist</string>
<key>ProgramArguments</key>
<array>
<string>/usr/local/bin/jamf</string>
<string>policy</string>
<string>-event</string>
<string>createLAPS</string>
</array>
<key>RunAtLoad</key>
<false/>
<key>StartCalendarInterval</key>
<dict>
<key>Hour</key>
<integer>11</integer>
<key>Minute</key>
<integer>10</integer>
</dict>
<key>UserName</key>
<string>root</string>
</dict>
</plist>

so seems to have run the cycle 5 mins later, but failed:

================================================================= ============ LAPS Account cycled 09/08/2024 11:10:11 ============ ================================================================= Password length has been set to 12 characters A Special character has been set in the password ACCOUNT ACCOUNT has already been created and is a local admin. Resetting local admin password.... No active session for ACCOUNT. Continuing to reset password 2024-08-09 11:10:12.637 sysadminctl[27985:12775769] resetting password for ACCOUNT. (Keychain will not be updated!) 2024-08-09 11:10:12.957 sysadminctl[27985:12775769] SystemConfiguration commitChanges failed. <dscl_cmd> DS Error: -14090 (eDSAuthFailed) Authentication for node /Local/Default failed. (-14090, eDSAuthFailed) Password validation failed.

Ah this means the passwords have become out of sync. If the cycle script runs again it will clean it up and reset the password to get it back in sync.

Give the device a couple of runs and let me know how it goes.

Thanks for your help, things have seemed to calm down and are working as expected.  Had one question, the Reset LAPS script to purge machines of the account.  Is there any way to trigger that silently from Jamf, ie. not have the "are you sure" popup on the local machine.

Thx in advance!

If anyone is interested I've got another JAMF LAPS tool. Its a menu bar app which displays the LAPS password for the current device. https://github.com/PezzaD84/JAMF-LAPS-Menubar-app

We have found an issue where the volume owner on apple silicone machines seem like they work for logins at least with the rotated password, however with things like system updates where a restart is needed, it shows as an incorrect password or failed authentication.  We seem to be having trouble with it allowing other volume owners as well, so I seem to be caught in a loop.  Anyone else seen this on Apple silicon?