Passwords with parameters

[dcgagne]

In light of the 9.97 hot fix our organization is going through and purging or sanitizing any scripts that may contain sensitive data. To that end, one script in particular is throwing back some errors when we attempt to pass parameters when using it.

This script resets the password for a local account on the machine, no AD binding.

The password is effectively two parts, a prefix ($prefix) and suffix ($4).

$prefix - A unique identifier for each machine
$4 - A string of characters that remains static for every device

The following script is executed:

#!/bin/sh

prefix=SOMETHING
acctName="SOMEUSER"    ## You will need the shortname of the account, so all lowercase presumably

dscl . passwd /Users/$acctName "$prefix$4"
dscl . create /Users/$acctName AuthenticationHint "Prefix + Suffix fields as of `date "+%B %d, %Y"`"

if [ $? == 0 ]; then
    echo "Password successfully changed"
else
    echo "Password not changed"
fi

exit

Normally, this worked with prefix and suffix being specified directly in the script. But when run as it is above with a custom event in verbose we see this:

Script result: DS Error: -14165 (eDSAuthPasswordQualityCheckFailed) passwd: DS error: eDSAuthPasswordQualityCheckFailed Password successfully changed

The password is, of course, not successfully changed.

We've tried different variations of this but seem to get the same error each time. Any thoughts? Possibly a better method?

[mm2270]

Try wrapping each variable in curly brackets

"${prefix}${5}"

BTW, your script mentions using $4, but you're using $5 in the script. Not sure if that's just a typo, but wanted to point it out in case.

[dcgagne]

Double post

[dcgagne]

No dice, looks like it throws out the same error.

And yeah, the 5 was a typo. Fixed!

[mm2270]

Silly question, but do you have a password policy enabled on the Macs this is running on? The error you're getting seems to think the password quality is not up to snuff, which makes me think the complexity or types of characters being passed to the variables isn't meeting a password policy requirement.

I don't really see a reason why it would be failing to change the password otherwise. It should work, but I haven't specifically tried doing a password change in that way before myself.

[dcgagne]

We do have password requirements configured though a CF. The password that we set is certainly complex enough, but I was worried that the shorter length of the variables would "trick" the profile into thinking it was a short password.

I may try fooling it tomorrow by making the prefix variable longer and more convoluted. Something like:

Pref1x$tart=PREFIX

Should be interesting to see what happens!

[dcgagne]

Hmmm... strangely, this morning it started working correctly without any modifications. I thought there may be a bug in the parameter being set on the JamfPro server in the script section vs policy, but that isn't affecting it.

So far 10.12 devices are resetting correctly. I'm going to start working my way backwards and see if it pops up on previous OS versions.