Admin local account password no longer work

[glpi-ios]

Hello,

We have a problem with a local account password that seems to no longer work for some unknown reason. 

During prestage enrollment, we create a local admin account (other than the management account). 

When created, a temporary password is assigned so that our support team can finish preparing the computer. 

Once our support team has finished intervening on the preparation of the computer, they execute a script via the self-service to change the password with a password that few people know. 

Below is the script we use to modify the password with openssl encryption.

#!/bin/bash


function DecryptString() {
    # Usage: ~$ DecryptString "Encrypted String" "Salt" "Passphrase"
    echo "${1}" | /usr/bin/openssl enc -md md5 -aes256 -d -a -A -S "${2}" -k "${3}"
}

LocalCurrentPassword=$(DecryptString "${5}" "${6}" "${7}")
LocalNewPassword=$(DecryptString "${8}" "${9}" "${10}")

sysadminctl -adminUser "$4" -adminPassword $LocalCurrentPassword -resetPasswordFor "$4" -newPassword $LocalNewPassword

passDSCLCheck=`dscl /Local/Default authonly "${4}" $LocalNewPassword; echo $?`
if [ "$passDSCLCheck" -eq 0 ]; then
	"/Library/Application Support/JAMF/bin/jamfHelper.app/Contents/MacOS/jamfHelper" -windowType utility -title "Changement de mot de passe" -description "Le mot de passe du compte master a bien été changé" -button1 OK &

else
	"/Library/Application Support/JAMF/bin/jamfHelper.app/Contents/MacOS/jamfHelper" -windowType utility -title "Changement de mot de passe" -description "Un problème est survenu lors du changement du mot de passe du compte master. Merci de voir avec un administrateur." -button1 OK
fi

exit 0

The problem is that we have a lot of computers where the password no longer works, neither the temporary one nor the new one, although it worked when preparing the positions. 

Here is the attribute extension that we use to know if the old or new password is used. 

#!/bin/bash


function DecryptString() {
	# Usage: ~$ DecryptString "Encrypted String" "Salt" "Passphrase"
	echo "${1}" | /usr/bin/openssl enc -aes256 -md md5 -d -a -A -S "${2}" -k "${3}"
}

LocalOldPassword=$(DecryptString "xxxx" "xxxx" "xxxx")
LocalNewPassword=$(DecryptString "xxxx" "xxxx" "xxxx")

passDSCLCheckNew=`dscl /Local/Default authonly "our_local_admin_account" $LocalNewPassword; echo $?`
passDSCLCheck=`dscl /Local/Default authonly "our_local_admin_account" $LocalOldPassword; echo $?`

if [ "$passDSCLCheck" -eq 0 ]; then
	RESULT+="Ancien mot de passe : oui"$'\n'
else
	RESULT+="Ancien mot de passe : non"$'\n'
fi


if [ "$passDSCLCheckNew" -eq 0 ]; then
	RESULT+="Nouveau mot de passe : oui"
else
	RESULT+="Nouveau mot de passe : non"
fi


echo "<result>${RESULT}</result>"

exit 0

We have another attribute extension that brings us back the last date of modification of the password of this local admin account and we notice that the last date of modification always corresponds to the execution of the script of change of password via the self service.

We have been using the same script and passwords for over 3 years and on some computers, the new password works very well and on others, it no longer works although when the script was executed, the new password had been successfully set, we are going crazy.

This account is our only local admin account with securetoken (we have not yet activated Filevault but we must do so soon). So we can't delete it and if we want to create another local admin account, we can't assign it a securetoken since we don't know the password of the only account having it.

I'm panicking because with the huge number of computers with this symptom, it is not possible to reset all the devices and in any case it would not be useful if we do not target the problem before.

Have you ever had this type of behavior? Does this come from the openssl decryption?

Thank you for your help.

[mm2270]

Have you applied any kind of password management policy to your Macs, like through a Configuration Profile? Because in my experience profiles with password policies applied end up applying to these local admin accounts, just like other accounts. And I've found when this happens, you cannot login or use the known/last password for authentication prompts.

[glpi-ios]

Hello @mm2270,

Thank you for your response.
Unfortunately, we have never used configuration profiles to manage passwords on local accounts.
We have a password policy managed by Active Directory, so for mobile accounts on computers connected to our AD.
We are migrating our AD to an Azure AD instance with Jamf Connect authentication.

As I said, if we look at the date of the last password modification of this account on the computers, it corresponds to the moment when our support team ran the script to set our usual password. And at that moment, the password works.

It's really strange.

[glpi-ios]

I just noticed something on a computer that has the problem.

When I try to log in to the local admin session, the password doesn’t work.
When I try to connect via ssh to the computer with the local admin account, the password is refused.

But when I connect to a user session, open the terminal, and type: 

su <local admin account>

The password works and I am connected as follows: 

<local admin account>@<computername> empty %

And right away, the password works normally again and when I try: 

dscl /Local/Default authonly “<local admin account>” “<Password>” echo $?

It’s OK even though it didn’t work until then.

So just typing “su <local admin account>” as a user unlocked the situation.

Do you know where this might come from?
And what does “empty” mean in the terminal when connecting with “su” 

<local admin account>@<computername> empty %

Thank you for your help.

[glpi-ios]

Hello,
I noticed something else. When I run the command

sudo -u <Local Account> -S <command>

I get the following message:
sudo: PAM authentication error: account locked
sudo: a password is required

Furthermore, when I run the command

dscl . read /users/<Local Account>

I can see:
<key>failedLoginCount</key>
<integer>132</integer>

Could this be the problem?

If so, how can I unlock the account with a remote script on all our posts that have this issue?

Thank you for your help.

[rstasel]

I see something similar and I'm still trying to track down what's causing it. The only thing of note is we're able to login via the GUI and it unlocks the account and things start working again. It _seems_ like it might be after some OS updates, accounts are getting locked until an interactive login so they can remediate something... but unclear.