How Can I Change Local Passwords on A LOT of Workstations?
I know the feeling of your secure network being compromised by an end user… Passwords do fall into the wrong hands and then what do you do? Scenarios start running through my head and I make a mental list of all the passwords and system configs that need to be changed. These aren’t fun times in Admin land but they usually breed scripts and easier ways to do the necessary!
El Di Pablo tell us of his experiences… And is culminated by using a Great tool that AtA LOVES! Check it out…
I had a bit of a scare the other day. I get a call from a user in the field. She is traveling with her laptop and she was calling from her hotel. she was complaining that she couldn’t log into her laptop using her normal login credentials, and that the only way she could login was using the local administrators account.
“Local Admin what?!?!” I exclaimed then started hyperventilating. I asked her how she came across the local administrator password, and she told me that one of the techs at the company that is no longer with us gave it to her a long time ago. I asked her to spell out the password for me, and low and behold it was the corporate standard.
I ran to my bosses office and reported the compromise, and recommended changing the local passwords. He agreed and called a meeting with me, our head desktop technician and one of the senior systems administrators to come up with a plan of attack. I told them that I can easily change these passwords using a script and pspasswd.exe that comes with Sysinternals PSTools. I told them that I can export a list of all of the workstations on the network from Active directory, and put them in a text file. pspasswd will read directly from the list in the text file and change the password of the specified account on each computer in the list. I showed each of the guys in the meeting how it works, and they agreed that my script would be the best way to go with this.
Here is an example of the syntax used in my script. Keep in mind that this script must be ran from within the directory containing the pspasswd.exe program or else you have to modify the script to change into it’s directory. Of course, if you know batch scripting well, you can add all sorts of stuff to the script, but the basic run command looks like this:
>set /p filename=”Please enter name of computer list (ie: computers): “
>pspasswd @%filename%.txt -u administrator@domain.com -p password
administrator newpassword >> %filename%-results.txt
You’ll notice that I added an output to a text file so I could create a log of which workstations the password was changed on, and which ones it wasn’t. That is a good idea so you can keep whittling away at it until the change has been completed on all workstations. Also, you’ll notice that I added the -u and -p switches. You don’t need that if you are already running the script from an account that has permissions to change local passwords. There are many other little changes you can do as well. I used the set command because I had different lists for different offices. You could just put the computer names in one list and not use the set command.
Let me know if you have used this or a similar product, and perhaps some other scripting ideas for this.
This is one of those articles where you HAVE to read the comments. You guys have some great insights and ideas! Keep on Commenting, that is what makes this site great. Go ahead pat your self on the back!
Flickr Photos
Recent Comments
Ask The Admin 
January 21, 2008 at 6:59 pm
Oh boy. When will people get it through their thick heads to place more priority on passwords. I can’t believe in this age of cybercrime people are still using their birthdates and names are passwords.
January 22, 2008 at 12:02 am
I still don’t understand why people rename the administrator account. All it does is give IT one more thing to remember.
A renamed local administrator account can be discovered in several ways, however the most damning is the SID. On Windows XP (and I believe Win2k) machines, the local administrator account will always have an SID ending in -500.
Beyond that, a simple “net localgroup administrators” run from the command line will return all accounts with membership in the local administrators group.
Most script kiddies will know this, and ALL hackers will. This is “security through obscurity” at best, and bad practice to boot (never paint over what you can fix).
Scripts to remove all but the local administrator and Domain Administrators from the local administrators group, coupled with scripts that change the password of the local administrator accounts run on a regular basis, in conjunction with auditing is the proper way to handle this.
Kudos to you for taking the initiative in correcting the security breach (I know several SysAdmins that would have just ignored it, or maybe changed the password on that one machine).