Validate Local User Password

[Jason]

We create a local user account for administrative tasks as part of our imaging. What we're seeing is that we'll receive a unit with some issues where we need to use that account, and the password won't work. This is not very common, but it is happening sometimes. We'd like to create an Extension Attribute that checks that account and validate if the expected password works, and if not, scope a policy to that smart group to reset it.

I did see one slightly complex script here:
http://www.yourownlinux.com/2015/08/how-to-check-if-username-and-password-are-valid-using-bash-script.html

But it doesn't appear to work any more since the shadow hash is now under /var/db/dslocal/nodes/Default/users/<USERNAME>.plist

Before I start working through that I wanted to check if anyone has any other suggestions/solutions.

Thanks

[andrew_nicholas · Accepted solution]

Look at using dscl to do this. The authonly flag might fill what you're aiming to do. If nothing is returned then all is well with the password, so just test for ANYTHING generated. The below might be what you're looking for.

outputTest=$(dscl . authonly [accountname] [password])
result="yes"

[ "$outputTest"] && result="no"

echo "<result>$result</result>

[andrew_nicholas · Accepted solution]

Look at using dscl to do this. The authonly flag might fill what you're aiming to do. If nothing is returned then all is well with the password, so just test for ANYTHING generated. The below might be what you're looking for.

outputTest=$(dscl . authonly [accountname] [password])
result="yes"

[ "$outputTest"] && result="no"

echo "<result>$result</result>

[Jason · Accepted solution]

Thanks @andrew.nicholas , I created the below script for my EA for that which uses some jamf code for encrypting strings. Not ideal since it can still be reversed, but slightly better then being in plain text and I don't know a better way. I'll probably add some more logic to validate that the account exists first and maybe some more around when errors are returned

#!/bin/sh

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

AcctName="ACCOUNTNAME"
AcctPWD=$(DecryptString 'STRING' 'SALT' 'PASSPHRASE')

outputTest=$(dscl . authonly $AcctName $AcctPWD)

if [ "$outputTest" = "" ]; then
    echo "<result>Match</result>"
else
    echo "<result>$outputTest</result>"
fi

[joshuasee]

Regarding other places to store login info, remember that macOS keychains are made for that sort of work, and root has no questions asked access to the System keychain… though so would admin users on the machine. You might want to try the add-generic-password variant of this:

/usr/bin/security add-internet-password -a "acctname" -D "Network Password" -s "printserver.example.com" -r "smb " -l "A Printer" -A -w 'P@$$w0rd' /Library/Keychains/System.keychain

[mbezzo]

How are you guys dealing with complex passwords (spaces, !, etc) with the dscl command?

[macguitarman]

You could put the username and password as parameters in the Jamf policy (script) $4 and $5. The username and password would not be in the script, therefore secure...