Beta Testing

[PezzaD84]

          @PezzaD84 

It is possible to change the Login keychain via a terminal/script command

security set-keychain-password -o oldpassword -p newpassword
or
security set-keychain-password -o oldpassword -p newpassword path-to-keychain

However I get the impression that the dreaded local items keychain cannot be manipulated at all at least by the same security command. As I am sure you are aware the Login keychain is at

~/Library/Keychains/login.keychain.db

and the local items keychain is at

~/Library/Keychains/[UUID]/keychain-2.db.*

It would be preferable to preserve this keychain but for the LAPS account it is les important than a user account so if needed just deleting the local items keychain sub-folder would be ok.

It could be Apple have changed things in new macOS versions but previously I used the LAPS solution here - https://github.com/NU-ITS/LAPSforMac

When I last used it I do not recall it causing any keychain problems. It would therefore be worth having a look at its script. Be aware its code for reading and modifying its extension attribute is out of date, as an example its xpath command needs changing on Big Sur and later. You only need to look really at its code for changing the user/keychain passwords and see if it works better.

Originally posted by @jelockwood in #6 (comment)

[PezzaD84]

@jelockwood
I've moved this issue to a new thread to avoid notifications going to an account which was added by mistake.

[jelockwood]

@PezzaD84
FYI - I was doing testing whilst logged in on the laptop as the LAPS account. The password did change successfully but this did prevent your script deleting the keychain(s).

I just created a second local admin account which I am now logged in to and your script ran and this time it has deleted both the login and Local Items keychains since they are not open and in use.

However as discussed we want to see if we can reduce the need to delete the keychains and the 'security' command I provided might help at least for the login keychain although not the Local Items keychain.

Also see if the other LAPS script I linked to has an alternative approach that might help. When I was previously using that other LAPS script I was not logged in as the LAPS account - at least not deliberately. Obviously if I logged in to the LAPS account to do something and coincidentally the (other) LAPS script ran then a similar situation might arise.

[jelockwood]

@PezzaD84
Ok, I have my script which links the SUPER tool for automating macOS upgrade and your macOSLAPS tool pretty much working.

I have added a function to your policy so that it executes my 'Super-Glue' script to re-run the Super setup/install process to tell SUPER the new local admin credentials. This is using the Jamf Pro 'Files and Processes' option in a policy to execute Jamf policy -event super-glue.

I think the following issues may still apply and there is where maybe you can help a bit.

1. Either because my super-glue policy is being triggered a little too soon before your's has finished updating Jamf Pro extension attributes, or because
2. I had at the same time a Terminal session running logged in as the local admin account your policy was going to change the password for

It resulted in the local admin password being screwed up.

I have added a 10 second sleep to the beginning of my super-glue script and will see if that helps, but if you are able to check if there is any login or terminal session running that corresponds to the local admin account, then you could exit with no change made and let it try next time.

Is there anyway in Jamf Pro to ensure that a Jamf Recon happens before a Files & Processes command?

[jelockwood]

@PezzaD84
Still having problems.

I have the beta 2.3 script run once with ONLY it passed the two extra parameters so it knows the existing LAPS credentials. This seems to work.

I had your 2.2.1 script as the one used for the ongoing Create & Reset policy, this is set to a weekly interval. It does however seem to run the first time very soon after the 'special' beta script.

It looks like the 2.2.1 script is causing a problem. As far as I can see the 2.3 script which as discussed is only intended to be run once works fine, it takes the 'known' credentials, does a password rotate and stores that in Jamf. It then seems the 2.2.1 script does a rotate but results in the credentials getting out of sync.

During my testing I have ensured I have had a second spare local admin account and via this I have been able to use

sysadminctl -resetPasswordFor <user name> -newPassword <actualpassword> -adminName <secondadmin> –adminPassword <password>

it was also necessary to add back a Secure Token although I think this happens automatically if a reboot happens. Otherwise the following may help

sysadminctl -secureTokenOn <user name> -password <password> -adminUser <secondadmin> -adminPassword <password>

to 'repair' the problem and using this manually set the newPassword to what the LAPS extension attributes believe it should be.

Thereafter things seem to work ok although with these time intervals it is harder to check.

I have just seen you have a 2.2.3 and I have just updated to that. However do you have any clues to this issue?

I had changed the policies to try ensuring a recon happens before it calls my Super-Glue script but as I now see confirmation the reasons my Super-Glue script was failing is down to the LAPS credentials getting broken I reckon that was a red-herring.

Here are your log files as well.
LAPS-FAILURE.log
LAPS.log

[jelockwood]

@PezzaD84
For your information it does indeed look like that if the LAPS user is logged in even if only in Terminal either via su or ssh as well of course as a full GUI login, then this will result in a screwed up password if your script runs at the same time.

I have previously mentioned this before therefore it may - indeed will be preferable if your script can check if the LAPS user has a session running. Since this can be via different methods - not just a GUI login then this rules out some of the more common means of checking for a logged in user. However the following may be an approach that could be used.

/bin/ps au | /usr/bin/grep "lapsuser" | /usr/bin/grep 'bash\|sh\|zsh' | /usr/bin/awk '{ print $1 }'

if this returns one or more lines as opposed to zero then the "lapsuser" is indeed logged in.

Note: If any other shells are used then they would need to be added to the above command.

[PezzaD84]

Hi @jelockwood

Sorry for the delay in response these last few weeks have been hectic!

Thanks so much for raising this issue it is something i will definitely be adding to a future release once I can get round to editing the scripts.

[jelockwood]

@PezzaD84
Any news about adding prevention of attempted password change if the LAPS user is logged in? As discussed I believe this will help prevent the failures of password cycling which in turn results in the extension attribute and actual passwords getting out of sync.

An alternative or additional approach which I am surprised if you are not already doing would be as follows.

1. Attempt password change
2. Use dscl /Local/Default -authonly USERNAME PASSWORD to test new password
3. If no error then update extension attribute
4. If error then abort

[PezzaD84]

Hi @jelockwood

I haven't had time recently to look at implementing these changes. The current script does indeed use the -authonly switch to check the current password and the script will exit if it fails to authenticate.
There are currently clean up measures in place which should rectify any passwords running out of sync but I still need to add the checks to see if the user is logged in before changing the password.

It's most certainly on my road map😉👍🏻

[jelockwood]

(Not a nag, just a query.)

I presume you will for the scenario I am referring to where I believe that if an active login is present for the LAPS account this currently causes the password change to fail - first do a test to confirm this problem, and then when you add the suggested workaround, also do a test.

If your first test does not reproduce the problem please let me know as maybe something different is the cause and this suggested fix would then be pointless.

Based on the fact you are already doing a dscl authonly test, I am surprised that this is resulting in the extension attribute and the password getting out of sync. My testing shows the extension attribute is being changed but is no longer the correct password.

I did spot that if the password contains an exclamation mark character this maybe an issue.

sudo dscl /Local/Default authonly user "password!"
does not work but
sudo dscl /Local/Default authonly user 'password!'
does work

Likely other special characters my also cause this.

[jelockwood]

@PezzaD84
Been busy myself since your last update to this project so I am only just looking at it.

I see you have a new version which is amongst other things supposed to check to see if the laps account is in use. Whilst I can see instructions for installing it with Jamf by itself it looks like it now uses all but one script parameter field.

Previously two fields had been allocated for the original request of defining initial values for the laps account name and laps password aka crypt.

I can use my own script to pre-populate your crypt and secret extension attributes if needed. What would now be involved in using your latest scripts with an existing laps account?

Also does this latest update take in to account my previous message in this thread regarding the use of special characters like an exclamation mark?

[PezzaD84]

Hi @jelockwood
The new script can manage existing deployments that have been created using the older version just as long as the script parameters all line up ok.
The new parameters are mainly for the teams integration so not too much should have changed.

I haven't had a chance to look into the issues with the exclamation marks yet I'll add it to my list of changes to look into.