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.