How Can I Change Local Passwords on A LOT of Workstations? (2 Years Ago Today)
on January 5, 2010 at 10:51 am
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 log in credentials, and that the only way she could log in 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!
That’s a good idea. In my network security class in school, my professor actually recommends that as well as creating another user called administrator with only guest permissions.
@Regge and El Di Pablo – Both Fantastic Ideas! Keep Em coming In! You can always email
Tips At AskTheAdmin Dot Com
with any off topic stuff you think we would like!
There are also scripts that can detect which accounts have local admin rights on the workstations. That way you can see if any users have discovered the local admin password and made themselves admins.
You can manage Local Computer Groups through Group Policies as well. These settings get applied at login so even if a user logged in as a local admin, and added their user account to the local admin group, as soon as they log off and back on, the changes would be lost and replaced with those in the policy.
The main problem I have with situation in the above post is how it can be tedious to keep whittling away at the list of computers. But when you need to run a script with privileges higher than the logged in user, this is usually the easiest way to do it.
Another way I have been slowly testing is to run the script at start up, so it will run with higher privileges.
Create a Group in Active Directory and add the appropriate computers to it.
Then apply a Group Policy to that group which runs the script at start up.
They key is to add commands at the end of the script which will remove the computer from that group once the script has finished.
This way you don’t have to manually re-run your script all the time. And by looking at the members of the group it is easy to see which computers have not yet had the script applied to them.
Reggae I am going to try that this weekend. Do you have the syntax for adding and removing computers from ad groups or ou’s?
In this situation I think it might be beneficial to rename the local admin account as well. This can be done through a group policy.
dsquery computer “OU=OUNAME,DC=domainame,DC=com” -name %COMPUTERNAME% | dsmod group “CN=GROUPNAME,OU=OUNAME,DC=DOMAINNAME,DC=COM” -rmmbr
DSQUERY finds the computer in Active Directory and the results are piped to the DSMOD command which removes it from the group. You’ll have to read the descriptions for both commands to be sure.
I can’t recall if these command are available by default, but, this should get you started.
Let me know how you make out!!
@Regge and El Di Pablo – Both Fantastic Ideas! Keep Em coming In! You can always email
Tips At AskTheAdmin Dot Com
with any off topic stuff you think we would like!
@reggae, we already have a group policy in place that does that, but that is an excellent tip.
As far as the Group policy idea, that’s a great idea. We will do that for the remaining 20!
Wow…That didn’t make sense. I meant the group policy about people adding them selves as local admins is already in effect.
We will implement the group policy to run my script on the remaining 20.
There are also scripts that can detect which accounts have local admin rights on the workstations. That way you can see if any users have discovered the local admin password and made themselves admins.
You can manage Local Computer Groups through Group Policies as well. These settings get applied at login so even if a user logged in as a local admin, and added their user account to the local admin group, as soon as they log off and back on, the changes would be lost and replaced with those in the policy.
The main problem I have with situation in the above post is how it can be tedious to keep whittling away at the list of computers. But when you need to run a script with privileges higher than the logged in user, this is usually the easiest way to do it.
Another way I have been slowly testing is to run the script at start up, so it will run with higher privileges.
Create a Group in Active Directory and add the appropriate computers to it.
Then apply a Group Policy to that group which runs the script at start up.
They key is to add commands at the end of the script which will remove the computer from that group once the script has finished.
This way you don’t have to manually re-run your script all the time. And by looking at the members of the group it is easy to see which computers have not yet had the script applied to them.
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.
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).
At my district, I had the same issue happen, and had to change the local admin password, though I had an additional issue with technicians coming in and out of the district, knowing the local admin password, so I create an Active Directory group that I added to all workstations via the login script, then added my technicians to that group as they came and went away. This way, I’m not forced to change the local admin password on each of my 5000 workstations, but rather just remove that user’s account from the Active Directory group which happens to be in the Local Administrator’s Group on all the workstations. my initial thought was to place the technician’s names in the Administrors group on the workstations, but obviously, their membership to that group can’t be easily controlled without tapping into group policy. I found AD security group is much easier.
Very slick. Any interest in writing up a small article for our readers on how you did it – step by step?
Well, the resetting of the local admin password was done in the same method you did with the PSTools.
As for adding the local admin, it was actually very simple:
1- Create an Active Directory Security Group, and add users who you want to be local admins on the workstations.
2- the line to add that group to the local admin group is none but our beloved :
net localgroup Administrators /Add “DOMAIN\group”
Now the trick here is to actually allow this command to run at user logon, and make it work. Given that users are not local admins on their own workstations, I had to embed this command in an exe, and run it as a higher privilege user. I use KIXstart to do that, and the reason I use a compiled EXE, is so that I can mask the username and password that is running this command (will likely be a domain admin account). (I use Admin Script Editor (http://www.adminscripteditor.com) to package the Kix Script into an EXE. if you don’t have that tool, perhaps, kix2exe can be user, I believe it allows pre-tokenizing and embedding alternate credentials.
Now anytime a user logs on, that group will be added to the local admins group.
p.s: you might want to run some logic to check for that group before adding it every time, just for efficiency purposes, and good scripting habits :)