Comments on: How Can I Change Local Passwords on A LOT of Workstations? (2 Years Ago Today)

By: Babylon

Babylon — Tue, 27 Jan 2009 15:30:47 +0000

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 :)

By: Karl L. Gechlik | AskTheAdmin.com

Karl L. Gechlik | AskTheAdmin.com — Tue, 27 Jan 2009 14:56:13 +0000

Very slick. Any interest in writing up a small article for our readers on how you did it – step by step?

By: Babylon

Babylon — Tue, 27 Jan 2009 08:10:55 +0000

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.

By: Therealjoe

Therealjoe — Tue, 22 Jan 2008 00:02:00 +0000

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).

By: Leon

Leon — Mon, 21 Jan 2008 18:59:00 +0000

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.

By: Unknown

Unknown — Fri, 14 Sep 2007 20:34:00 +0000

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.

By: Unknown

Unknown — Fri, 14 Sep 2007 20:28:00 +0000

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.

By: Unknown

Unknown — Fri, 14 Sep 2007 20:13:00 +0000

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.

By: El Di Pablo

El Di Pablo — Fri, 14 Sep 2007 20:02:00 +0000

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.

By: El Di Pablo

El Di Pablo — Fri, 14 Sep 2007 20:00:00 +0000

@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!

By: Unknown

Unknown — Fri, 14 Sep 2007 19:44:00 +0000

@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!

By: reggae

reggae — Fri, 14 Sep 2007 19:09:00 +0000

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!!

By: Reggae

Reggae — Fri, 14 Sep 2007 19:04:00 +0000

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.

By: NinjaAdmin

NinjaAdmin — Fri, 14 Sep 2007 18:47:00 +0000

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?

By: reggae

reggae — Fri, 14 Sep 2007 18:34:00 +0000

By: reggae

reggae — Fri, 14 Sep 2007 18:28:00 +0000

By: PD

PD — Fri, 14 Sep 2007 18:13:00 +0000

By: Karl L. Gechlik

Karl L. Gechlik — Fri, 14 Sep 2007 17:44:00 +0000

@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!

By: El Di Pablo

El Di Pablo — Fri, 14 Sep 2007 16:32:00 +0000

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.