Reset local account password using $computerName

So, in your example above, "D8873904" is the Sharing name of the Mac?

If so, grab that with something like scutil, into a variable and plug it back in with the rest of your password using the Unix passwd command. Try something like this script. Not tested really so make sure you use it on a testing machine to ensure its actually working.

#!/bin/sh

compName=$(scutil --get ComputerName)
acctName="billybob"    ## You will need the shortname of the account, so all lowercase presumably
suffix="_i_forgot_my_password"

dscl . passwd /Users/$acctName "$compName$suffix"

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

exit

Not that this must run as root to change the password without supplying the old password, or it will prompt for it. As long as its running out of a Casper Suite policy it should be OK.

There's a simpler way to handle this. If you set up a policy, click on the Accounts section. Under Create Accounts/Reset Passwords/Delete Accounts, select the Reset Password link. From there, you can enter the username and the password that you want the account's password reset to be.

At that point, you can set up a smart group to include machines with that particular account, then scope the policy to run on those machines.

Update: Never mind, I'd missed that there's a unique variable in the password. D'oh!

rtrouton - am I missing something regarding your post? Does this set the password on each device with the unique $computerName variable?

mm2270 - thanks I will try this.

You're right, it doesn't. I'd missed the unique variable in your password. Sorry for the confusion.

Hi Everyone,

Just speaking from experience here. Never put a password in a script if you can avoid it. Also, if you have to, redirect all standard and error output to /dev/null. Many years ago I was told to reset a local password immediately by management and I did it via a script. It will log that output to the system.log. Lets just say it backfired on me. I had one user that actually knew a bit of Unix. This was back in like 2006, and with how popular OS X has got since then, I can only assume more and more users are becoming some-what Unix savvy.

This is where directory services comes in. I would say if you are using local accounts, and have to use this method, have Casper Remote send a change password policy to the client directly. I would not recommend passing any password in a script. Just my opinion.

Hope this helps,
Tom

@Tom-

That's a really good point about not putting passwords in cleartext. I would generally agree. We almost got burned with this ourselves with an account creation policy. But, I've actually only seen this be an issue if using the Run Command section of a policy, which is what we were doing initially (you really DON'T want to put a password there). If the information is in a script, I have not seen it write anything to the logs where it can be read back. Perhaps I've just not run across it. Even if so, that's not to say it still can't be captured somehow, but it seems the only thing that gets written anywhere is to the jamf.log that it ran a policy and downloaded the script.

Overall though it is good advice to not include those in scripts if at all possible. I'm not sure if there would be an easier way for zmbarker to implement what he's looking for outside of in a script. If it was a straight password change, he could just use the built in Account change password process in Casper, but that doesn't apply in this case.

The only other thing that can help here I can think of is to use passed parameters, so in the very least its not hardcoded in the script, just in case someone managed to get their hands on the script itself. It would just have parameters where any account names and passwords would be.

deleted - double post

Tom - I agree about the plain text item. How would I get around this from the script posted above? Can you post a new updated script?