Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

We have a number of PCs running XP SP2 (and a couple running SP1) already in production, and we're looking to keep the local administrator's password consistent across the OU. The only solutions I can think of would be using pspassword to change all of their passwords, or having a script containing the password run locally on the PCs.

Unfortunately, pspasswd won't work on computers that aren't online and a local script containing the password would be insecure.

Is there any other viable solution? How can I account for computers that aren't online at the time of the password change?

share|improve this question

7 Answers 7

up vote 5 down vote accepted

Although there is not a Group Policy setting that can do this, there is a Group Policy Preferences setting that will. More information here: http://blogs.technet.com/askds/archive/2007/11/28/introducing-group-policy-preferences.aspx

Edit: One other option is to use the Passgen utility that Steve Riley and Jesper Johannson (both formerly from Microsoft) wrote for their book "Protect your Windows Network". It actually sets a unique local administrator password for each computer in domain (which is much more secure... if you have them all the same, the compromise of one computer means the compromise of all the computers in your domain). From the description:

In the book, we recommended that you maintain separate passwords on every local administrator and service account in your enterprise. This is, of course, almost impossible to manage without something to automate it for you. That’s what Passgen does. The tool generates unique passwords based on known input (an identifier and passphrase you define), sets those passwords remotely, and allows you to retrieve them later.

Passgen is free, and you can get it here: http://blogs.technet.com/steriley/archive/2008/09/29/passgen-tool-from-my-book.aspx

share|improve this answer
    
Looked at this, wasn't sure if it was viable since we still have a couple computers using SP1 and we'd have to do a domain-wide rollout of GPP to get it to work. –  Jordan Milne Jun 26 '09 at 14:39
    
The MS article at blogs.technet.com/b/grouppolicy/archive/2009/04/22/… does not recommend using GPP for sensitive passwords. "Because the password is stored in SYSVOL, all authenticated users have read access to it. Additionally, it can be read by the client in transit if the user has the necessary permissions." –  bshacklett Dec 27 '11 at 15:54

We do this through Group Policy.

I don't know the specifics of how the GPO is created, but it is in the section:

 Computer Configuration
  / Windows Settings
   / Security Settings
    / Local Policies/Security Options
     / Accounts

There are settings to allow disabling of the guest account and renaming of the local admin account.


EDIT: I misspoke about changing the local password.


Changing the local admin password is a bit more complicated, at least until Windows Server 2008. This solution works on Server 2003, and is a bit of a kludge as it sends the new password in plain text. If that concerns you, there are other alternatives that encrypt but need additional software. We address the issue by leaving it disabled unless we need to make a change.

1- write a 1 line batch file .. with the command "NET USER Administrator %1" - if you rename the account use the new name.

2- set the batch file to run on logon using the GPO, in the following section

 Computer Configuration
  / Windows Settings
   / Scripts
    / Startup

3- IN THE GPO entry, press the button to show the files, and copy the batch file into the location opened. Then the batch file (incl .bat) as the script name and the new password as the parameter.

illustration

share|improve this answer
    
I see one for renaming the admin account, but not changing the password. –  Jordan Milne Jun 26 '09 at 16:22
1  
Prepare to be pummelled for mentioning using a script with a plaintext password in it... smile –  Evan Anderson Jun 26 '09 at 17:56
1  
You have compression enabled on your SYSVOL? Eww... –  Evan Anderson Jun 26 '09 at 17:56

I'm not sure what you're looking for here since it would be difficult to deploy a local account password change solution that will 'somehow' work for online and offline computer accounts. The process would be if it's an actual script or GP, for them to get the password change at 'some point' when they're online. If you want to deploy this as a one time action on a certain timeframe, you would have to do the offline computers manually.

I'm sure you've probably read this, but here are some solutions that were suggested in a previous question related to yours: http://serverfault.com/questions/23490/is-there-a-group-policy-that-would-push-a-new-user-name-and-password-to-all-local

share|improve this answer
    
The only kind of script I'm really against is one that contains the password itself, not all scripts. –  Jordan Milne Jun 26 '09 at 16:49
1  
How are you going to have a machine set a password if the password isn't in the script? The plaintext has to exist somewhere at some time. "Passgen", for example, just uses a plaintext passphrase and the computer name as a salt. The "trust" is just moved into the passphrase, rather than the password. You'd still have to have that passphrase in a script in order to use the tool. You have to have trust somewhere. To my mind, a script that's marked "Domain Computers / Read" w/ the "Authenticated Users" permission removed, allowed to run on client computers, and then deleted is fairly secure. –  Evan Anderson Jun 26 '09 at 17:16

We push local passwords out using the Powershell script Set-LocalPassword.ps1 and get the list of servers using Get-OUComputerNames.ps1.

Quick, simple and the password doesn't have to sit around waiting to be found.

Get-OUComputernames "OU=TheOU,DC=TheDomain" | Set-LocalPassword "TheAccount" "TheNewPassword"

However this solution does not cover the case when a machine is turned off. Though it would be simple enough to make a list of un-pingable machines and deal with them later.

share|improve this answer

I'm going to point you to my answer at: http://serverfault.com/questions/23490/is-there-a-group-policy-that-would-push-a-new-user-name-and-password-to-all-local/23509#23509

You could deploy such a script with permissions set to only allow "Domain Computers" to read the script (or an even more restrictive group, if you wanted), and setup a "trapdoor" group as I describe such that you can know when all the computers have processed the script such that you can delete it. The script would execute locally on the subject computers, but would only be accessible to the computer's security context. (If the users have "Administrator" on their machines, though, then this will be a problem. If they have "Administrator", though, you have bigger problems than unset local "Administrator" passwords. Presumably, the users have already setup methods to guarantee them the ability to regain "Administrator" rights after you change the local Administrator password... I would! >smile<)


On a completely different front, you could do something crazy like a server-side script that:

  • Polls an AD security group for member computer names
  • Attempts to PING / "NET USE" / etc each computer in the list to determine if they are "online"
  • Executes a "PSPASSWD" against the remote computer if it determines it is "online"
  • Remove any computers that successfully completed the password reset from the security group
  • Sleep for a period and repeat if the group isn't empty yet

That would keep the script executing on a server.

share|improve this answer

I would just use simple batch file changing password and convert that file into exe or something using AutoHotKey or AutoIT Script. Then configure this script to run as computer startup script. To stop people from spying I would use the trick of only giving "Domain Computers" READ rights instead of "Authenticated Users".

share|improve this answer

As Sean Earp said, you want to have a unique local admin password for each one, regularly changed.

Another way that I prefer (at least in theory ;) is to simply delete the local administrator accounts completely and rely on domain accounts for management.

share|improve this answer
    
There isn't any functionalty in the OS to delete the RID 500 Administrator account. You can do it by mucking around in the SAM but you're far into "unsupported" territory at that point. What happens, anyway, when the machine's workstation trust relationship gets b0rked up? –  Evan Anderson Jul 16 '09 at 2:42

protected by splattne Aug 17 '10 at 7:13

Thank you for your interest in this question. Because it has attracted low-quality answers, posting an answer now requires 10 reputation on this site.

Would you like to answer one of these unanswered questions instead?

Not the answer you're looking for? Browse other questions tagged or ask your own question.