8

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?

7 Answers 7

5

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

2
  • 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. Jun 26, 2009 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, 2011 at 15:54
3

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: https://serverfault.com/questions/23490/is-there-a-group-policy-that-would-push-a-new-user-name-and-password-to-all-local

2
  • The only kind of script I'm really against is one that contains the password itself, not all scripts. Jun 26, 2009 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. Jun 26, 2009 at 17:16
2

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.

1

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

3
  • I see one for renaming the admin account, but not changing the password. Jun 26, 2009 at 16:22
  • 1
    Prepare to be pummelled for mentioning using a script with a plaintext password in it... smile Jun 26, 2009 at 17:56
  • 1
    You have compression enabled on your SYSVOL? Eww... Jun 26, 2009 at 17:56
0

I'm going to point you to my answer at: Is there a group policy that would push a new user name and password to all local machines on a network?

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.

0

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

0

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.

1
  • 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? Jul 16, 2009 at 2:42

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .