Large-scale local administrator password reset

[Bryan R.]

I'm installing anti-virus across a large network, 200+ machines. I can do this automated but I need to have the local administrator account enabled and the password set on each machine. I was thinking something over group policy but haven't been able to find a working script.

 

My DC is 2012 and the machines and a mixture of Windows XP and Windows 7.

[AStalUK]

You can also do it through GP Preferences I believe, I've not tried this.  Within GP Management Editor expand; Computer Configuration>Control Panel Settings>Local Users and Groups and Right click for New Local User.  Leave the action as update and select Administrator (Built-in) and then update the password fields and deploy.  At least this is where it is in 2008 R2, not setup a test environment yet for 2012 R2.

[sc302]

You would do it through a batch file or vb script. It can be pushed through a gpo.

But honestly the best way to push would be through a corporate av from anyone eset, vipre, symantec, McAfee, Kaspersky, etc...

[+BudMan]

Why would you need local admin account, why can you not just use domain admin to install?

[AStalUK]

As sc302 and +BudMan have both said the best way to deploy the AV to you machines would be via the built in mechanism all the corporate AV's provide using your domain admin account.  What AV are you trying to deploy, others here may have experience with it and will be able to give you pointers?

[Daedroth]

We use Sophos Endpoint, and that uses a System account that we created in AD. I would suspect that you can do something similar, rather than enabling the built-in administrator.

[Geoffrey B.]

We use Sophos Endpoint, and that uses a System account that we created in AD. I would suspect that you can do something similar, rather than enabling the built-in administrator.

 

We use the same thing, its fantastic to use the AD account rather than a local one, we have also tied a few things in sophos to groups so that we have different levels of applications allowances and a few other things. 

[Bryan R.]

I'm deploying Avast using Avast Enterprise Administration. It would make sense to use the domain admin account to do this. Authentication to the admin shares work from the server machine to a client machine I'm trying to push to. The push fails immediately with Access Denied.

 

Log:

 

LAB06-2011: WNetAddConnection2 \\LAB06-2011\C$ LAB06-2011\administrator error 1326 (The user name or password is incorrect)

LAB06-2011: WNetAddConnection2 \\LAB06-2011\ADMIN$ LAB06-2011\administrator error 1326 (The user name or password is incorrect)

 

So, process is clearly trying to use the local admin account when in the deployment task I have the domain admin account added. As soon as I changed the local admin password, the remote install worked.

 

The point of enabling and resetting the password for all local admin accounts is also something I'd like to do for security and management reasons unrelated to this deployment.

[sc302]

http://forum.avast.com/index.php?topic=124140.0

 

 

ACTIVE DIRECTORY

If using Active Directory you can easily create an installation package to push the client remotely through the network with Network Administrator password and in the Deploying Group. The Endpoint client will remove existing installation of avast! 4 only.  Any other avast! version or other anti-virus should be un-installed prior to Endpoint deployment.

[sc302]

http://www.advantage77.com/Files/avast_Quick_Guide_AEA.pdf

 

Read the how to deploy section, around page 19.  I think someone messed up the install package, based on what I just briefly read..

[Bryan R.]

http://forum.avast.com/index.php?topic=124140.0

Yes, I know it should work. I have the account filled in on the deployment task but it's still not authenticating.

 

Edit: I did find where the account was not entered correctly. So, now it is authenticating. Basically, the log in account detail asks for domain, username, and password fields. I entered them and assumed it would use the domain field to authenticate the domain admin account to the end machine but it needed the username field to also have the full domain\username as well as the domain field.

 

 

Still I need to be able to enable and reset all local admin accounts. Some of them will have a password that needs to be updated for security reasons. So, anyone have one of these working scripts to push through group policy?

[sc302]

try this in a batch file

 

 

net user administrator anypasswordyoudecide

 

try this in a vbscript

Set oShell = CreateObject("WScript.Shell") 
Const SUCCESS =  
 
sUser = "administrator" 
sPwd = "Password2" 
 
' get the local computername with WScript.Network, 
' or set sComputerName to a remote computer 
Set oWshNet = CreateObject("WScript.Network") 
sComputerName = oWshNet.ComputerName 
 
Set oUser = GetObject("WinNT://" & sComputerName & "/" & sUser) 
 
' Set the password 
oUser.SetPassword sPwd 
oUser.Setinfo

 

test first then deploy

[Bryan R.]

You can also do it through GP Preferences I believe, I've not tried this.  Within GP Management Editor expand; Computer Configuration>Control Panel Settings>Local Users and Groups and Right click for New Local User.  Leave the action as update and select Administrator (Built-in) and then update the password fields and deploy.  At least this is where it is in 2008 R2, not setup a test environment yet for 2012 R2.

Who would have thought it would be so easy. Loving group policy preferences. Every time I look there's something new and amazing :p

[MorganX]

Who would have thought it would be so easy. Loving group policy preferences. Every time I look there's something new and amazing :p

 

GP preferences is worth it's weight in gold!

[+BudMan]

"Some of them will have a password that needs to be updated for security reasons. So, anyone have one of these working scripts to push through group policy?"

So how I use to do this back in the day when I use to have to do such things was this tool

http://technet.microsoft.com/en-us/sysinternals/bb897543

Systems administrators that manage local administrative accounts on multiple computers regularly need to change the account password as part of standard security practices. PsPasswd is a tool that lets you change an account password on the local or remote systems, enabling administrators to create batch files that run PsPasswd against the computers they manage in order to perform a mass change of the administrator password.

PsPasswd uses Windows password reset APIs, so does not send passwords over the network in the clear.

I would create a file with the the command to talk to each machine and in the file would be all the different passwords. It is not good practice for every local admin account to have the same password. Because if one is compromised they then have local admin for every machine in your network. So I would use a password generator and generate different password for every machine. Then paste them into my script and just run it from my workstation, it would go out to every machine and change the local admin password to new one.

So I could set the local admin password on 1000+ machines in a matter of couple of minutes.

[Colonel-Sanders]

I feel the need to point out that passwors in batch / vbscript files via Group Policy are not secure and can be read by all users (or malware) if they know where to look.  It is convenient, but not 'secure'.
 

You can also do it through GP Preferences I believe, I've not tried this.  Within GP Management Editor expand; Computer Configuration>Control Panel Settings>Local Users and Groups and Right click for New Local User.  Leave the action as update and select Administrator (Built-in) and then update the password fields and deploy.  At least this is where it is in 2008 R2, not setup a test environment yet for 2012 R2.

 
Also, passwords in GP Prefrences are NOT secure - They are jumbled up, still available to any user (or malware) on any domain joined PC that knows where to look.  Again it is convenient, but not 'secure'.
 

However, the password is not secured. Because the password is stored in SYSVOL, all authenticated users have read access to it.[/size]
http://blogs.technet.com/b/grouppolicy/archive/2009/04/22/passwords-in-group-policy-preferences-updated.aspx

You can use a script like this from the server that takes in a text file list of PC's to remotely change passwords. A little less convenient, and each PC needs to be on when you run the script, but the passwors are never exposed to users this way.

- J

[Bryan R.]

I feel the need to point out that passwors in batch / vbscript files via Group Policy are not secure and can be read by all users (or malware) if they know where to look.  It is convenient, but not 'secure'.

 

 

Also, passwords in GP Prefrences are NOT secure - They are jumbled up, still available to any user (or malware) on any domain joined PC that knows where to look.  Again it is convenient, but not 'secure'.

 

You can use a script like this from the server that takes in a text file list of PC's to remotely change passwords. A little less convenient, and each PC needs to be on when you run the script, but the passwors are never exposed to users this way.

- J

Yes, you are correct. I don't like scripts for this reason. I understand GPP doesn't hide the password either (a dialog box warns of this). I am willing to compromise and remove this policy when it's purpose is fulfilled ;) A nice trade off between meticulous detail and convenience.

[AStalUK]

Looking at PsPasswd that BudMan mentioned it would seem to be a good option for securely changing passwords on a network.  Reading the text I can see how it would be used to change the admin password on multiple PC's but I'm not clear on how you would set different passwords for each PC, PsPasswd would seem to set the same password against all PC's within the file specified.  Presumably to set different passwords against different PC's this would need to be used in conjunction with some form of script/batch file running from the admin PC which also had a separate file containing a list of passwords?

[farmeunit]

Not sure with Avast, but with other pieces of software, for the admin credentials to work, we've had to disable Simple File Sharing.

 

Regarding your installation, just create a package in the management console, then install using GPO or another desktop management.

 

I skimmed some, but it looked like you're trying to push from server?

[+BudMan]

By design reading the @file with a list of computer yes it would set the same password for each machine - bad admin! ;)

So just have your script that uses the command for each machine, something like this

pspasswd \\computer1 -u domainadmin -p domainadminpassword administrator O*o]Z>0_4}+J

pspasswd \\computer2 -u domainadmin -p domainadminpassword administrator &z63K683td11

pspasswd \\computer3 -u domainadmin -p domainadminpassword administrator =+2]3)L{o81Q

You only need to use the domainadmin and password if your account does not have permission on the remote box. Which is normally shouldn't in an enterprise, not a good idea to run with an account that has equiv of domainadmin, etc. but if your setup has say your admins accounts in the local admin group then you don't need to specify it in the commandline

example - here is me changing administrator account password to Test123 on my nas box in my home network from my pc at home where my account matches up with an admin account on the storage box so do not need to send creds to auth to the machine in the cmd line.

C:\>pspasswd \\storage administrator Test123

PsPasswd v1.23 - Local and remote password changer

Copyright © 2003-2010 Mark Russinovich

Sysinternals - www.sysinternals.com

Password successfully changed.

So you put all commands in a batch and run it, and if you send the output to a file you have a listing of what machines where off or failed on, etc.

C:\>pspasswd \\notstorage administrator Test123

PsPasswd v1.23 - Local and remote password changer

Copyright © 2003-2010 Mark Russinovich

Sysinternals - www.sysinternals.com

Error changing password:

The RPC server is unavailable.

Now yes all the password are in the script you create. But you are the admin :) When I use to to have to do this I would print out the passwords and put in the vault. then put my script and log in secure location that other admins had access to.

Also - as mentioned it uses the MS api's and the password is not sent in clear - now would it be possible for say someone sniffing while you do this to decode?? Not sure on that - prob yes!! But your not doing this over the public internet, your doing it over YOUR network.. So if your users are sniffing on your network that is on you in the first place ;)

[AStalUK]

Okay interesting, something I will need to keep in mind.

 

How would you go about creating a script for say 500 people? For me a simple batch file would be best as my VBS skill's are lacking.  But then I wouldn't fancy going through and editing 500 lines for machine names and separate passwords.

[sc302]

I gave a vb script example above. 1 script, 1 gpo in active directory...and boom, 500 computers get the script and execute it.

 

You can do a few things that would make it tough for someone to get the password if they were browsing and find something out in the open. 

 

there are a few ways to encrypt your scripts so that your password isn't in the open.  kixtart you can do what is known as tokenizing, you can use resource hacker to compile your script so the info isn't readily available.  You can encrypt with microsoft script encoder.  You could simple obsure the batch file by making it an exe, it would require someone with a good computer understanding of what is going on to think about it.  As always, you do not want to keep this active for a long period of time.  As with anything, the encryption used is only a way to keep it safe for a short period of time.  Put it on and get it off as quickly as possible. 

[techbeck]

You can also do it through GP Preferences I believe, I've not tried this.  Within GP Management Editor expand; Computer Configuration>Control Panel Settings>Local Users and Groups and Right click for New Local User.  Leave the action as update and select Administrator (Built-in) and then update the password fields and deploy.  At least this is where it is in 2008 R2, not setup a test environment yet for 2012 R2.

 

How we do it at work.  We have to change the admin passwords when an IT employee leaves the company.  Works great.

[+BudMan]

"How would you go about creating a script for say 500 people"

 

Well how I did it was leverage excel to copy and paste into columns, simple enough to dump computer list from your domain - paste into excel, plenty of tools to generate lists of passwords paste into excel - then just use something like

 

=CONCATENATE(A1," ",B1,C1," ",D1," ",E1) to put it together and then just copy paste that into text editor and save as .bat or .cmd and bing bang zoom done.  If it takes you more than 2 minutes to generate such a file - your doing it wrong ;)

 

 

 

 

 

 

 

[AStalUK]

Nice solution, I was thinking it would be more complicated.  I had it in my mind that there would be two text files one for password and another for computers and then some form of recursive command line to run through the files.

[+BudMan]

While that would be another way to skin the cat.  How do you really easy match up what computer got which password that way when in 2 different files.  This gives you simple listing computer - password in 1 place to view.  Print it out and put in your vault and you have your passwords when/if ever needed.  If you have a lot of computer, its unlikely you get them all done in one run - people out sick, laptop offline, etc.  So this way just delete the the lines of machines that work via the output and you have script to run later to catch the machines that offline/etc/  Use that list to send out WOL, etc..

 

First run would get majority - but always had a few straggler machines to work through.

 

Problem I see with GP -- are you 100% that machine did it?  With this method you have instant feedback if password was changed or not, etc.  And if you save the log, you have validation in audit that you changed all the passwords, etc.