Change Admin password via script

I have to update all of the Local Administrator Passwords on my network.
I have a logon script already in place to redirect our users desktops and my documents folders.

I would like to add a few lines to my batch script to change the local admin password. Also would it be possible to add a condition like for it not to run if the computer is named "fs1"?

Can someone please help me with this?

Find more posts tagged with

Free for TechExams community: Cybersecurity salary guide

Compare cert salaries and plan your next career move

Button

Comments

tiersten

Hey, Scripting Guy!

hypnotoad

qwertyiop wrote: »

I have to update all of the Local Administrator Passwords on my network.
I have a logon script already in place to redirect our users desktops and my documents folders.

I would like to add a few lines to my batch script to change the local admin password. Also would it be possible to add a condition like for it not to run if the computer is named "fs1"?

Can someone please help me with this?

One liner...make a .bat file:

net user administrator %1

set this in group policy and pass your password as the parameter (from the GP console).

astorrs

hypnotoad wrote: »

One liner...make a .bat file:

net user administrator %1

set this in group policy and pass your password as the parameter (from the GP console).

In my opinion this would be a very bad way of tackling the problem. Although it would work, it would then be possible for any user in the domain to determine the local administrator password because GPOs are just human readable files in the SYSVOL share on any domain controller. While unlikely to happen it's still a huge security hole.

It would be much better to use the script linked to by tiersten. Even better would be a script that generated a random password for each computer and wrote the output to a CSV file.

HeroPsycho

astorrs wrote: »

It would be much better to use the script linked to by tiersten. Even better would be a script that generated a random password for each computer and wrote the output to a CSV file.

Technically better for security, but may cause difficulties to manage the computers. Setting them all to the same is easier to manage.

Here's a PowerShell script I made to do it, which includes a CSV report of which ones failed and succeeded to have their password changed. The error handling isn't the best way of doing it, but I never had a chance to go back and improve it.

#Sets a variable for today's date. This will be used below to generate a uniquely named report each time the script is run.
#Ex: Friday, March 27, 2009 2:09:40 PM = 03272009-140340
$date = get-date -uformat "%m%d%Y-%H%m%S"

#Sets the report's file name consisting of (failedpwdchanges + $date.csv)
$filename = "pwdchanges" + $date + ".csv"

#Sets the target local account on the remote machine for the password change.
$account="administrator"

#Sets the new password
$password="Passwordhere"

#sets the servers which the account password will be changed.
$computers = get-content C:\temp\computers.txt

#Clears the special $error variable. This is to ensure that only failed target computers will be captured to build the failure list.
$error.clear()

#On each computer in the $computers collection, set $account's password to $password, and write the change to the account.
foreach ($computer in $computers) {
Write-Host "Changing $account password on $computer"

#Since $computers is an array, and a CSV report will be created, this puts the computer name into a Name property of the object that can be included in the report.
$computer | Add-Member noteproperty -name Name -value $computer -force -passThru

#Creates a variable of user to ADSI object of the user $account on computer $computer.
[adsi]$user="WinNT://$computer/$account,user"

#This sets $user password to $password and writes the password to the object permanently.
$user.SetPassword($password)
$user.SetInfo()

#Error logic to determine if the above failed using special $error variable.
if (($Error | measure-object).count -ne $null){
Write-Host "Computer $computer failed admin password change!"
$computer | Add-Member noteproperty -name pwdchange -value "FAIL" -force -passThru
}

if (($Error | measure-object).count -eq $null){
Write-Host "Computer $computer admin password changed!"
$computer | Add-Member noteproperty -name pwdchange -value "SUCCESS" -force -passThru
}

#Clears $error variable for next computer in collection so above logic will still function.
$Error.clear()
}

#Displays the list of failed computers and creates a complete report in a csv file named $filename.
Write-Host "The following computers failed to have the local account changed. A complete report will be saved as $filename."
write-host ($computers | Where-Object {$_.pwdchange -ne "SUCCESS"})
$computers | select name,pwdchange | Export-Csv $filename -NoTypeInformation

astorrs

HeroPsycho wrote: »

Technically better for security, but may cause difficulties to manage the computers. Setting them all to the same is easier to manage.

How often do you find yourself needing the local admin password? The answer should be almost never. If someone compromises a single desktop/laptop on your environment and all computers (inc servers) have the same local admin password then they can technically compromise your entire network.

Claymoore

astorrs wrote: »

How often do you find yourself needing the local admin password? The answer should be almost never. If someone compromises a single desktop/laptop on your environment and all computers (inc servers) have the same local admin password then they can technically compromise your entire network.

Which is why the local admin password on your servers should be blank (although good luck getting an auditor to sign off on that). Since you cannot connect to a network resource with a blank password, you have to physically be standing at the server's keyboard to access the server with a blank password. If your servers aren't in a secure area, no amount of password complexity can protect you.

Tyrant1919

Claymoore wrote: »

Which is why the local admin password on your servers should be blank (although good luck getting an auditor to sign off on that). Since you cannot connect to a network resource with a blank password, you have to physically be standing at the server's keyboard to access the server with a blank password. If your servers aren't in a secure area, no amount of password complexity can protect you.

Never knew that, and I like it very much.

dynamik

Tyrant1919 wrote: »

Never knew that, and I like it very much.

Pfft, it's irritating. I never use passwords in my VM labs, and Windows always yells at me

I disable that ASAP

tiersten

Claymoore wrote: »

Which is why the local admin password on your servers should be blank (although good luck getting an auditor to sign off on that).

No chance of that ever happening here. Auditors would freak out if that ever happened. Freaking out is probably an understatement actually...

astorrs

Claymoore wrote: »

Which is why the local admin password on your servers should be blank (although good luck getting an auditor to sign off on that). Since you cannot connect to a network resource with a blank password, you have to physically be standing at the server's keyboard to access the server with a blank password. If your servers aren't in a secure area, no amount of password complexity can protect you.

You're right in that audit never approves that one.

I've found disabling the local admin account accomplishes the same thing (and audit/compliance seems to like it). You can always login as administrator at the console (even if the account is disabled) in safe mode. It's usually less than an annual occurrence that someone needs to do that.

What I said about using the same password on all desktops/laptops still holds true though, compromise one compromise all on the network - and a blank password wouldn't be so great there...

royal

Claymoore wrote: »

Which is why the local admin password on your servers should be blank (although good luck getting an auditor to sign off on that). Since you cannot connect to a network resource with a blank password, you have to physically be standing at the server's keyboard to access the server with a blank password. If your servers aren't in a secure area, no amount of password complexity can protect you.

Bad idea. There's a GPO that actually allows you to access a server/workstation with a blank password which is obviously not enabled by default. If you have everything blank and for some reason (purposely or accidentally) this GPO gets enabled, you have complete open access for all servers to anybody.

Claymoore

royal wrote: »

Bad idea. There's a GPO that actually allows you to access a server/workstation with a blank password which is obviously not enabled by default. If you have everything blank and for some reason (purposely or accidentally) this GPO gets enabled, you have complete open access for all servers to anybody.

And with Group Policy Preferences you can reset the local admin password to anything you want. Either way, you need an account that has the ability to create and link group policy objects. With Advanced Group Policy Management in 2008 you can separate the responsibility of creating and approving GPOs for an extra layer of protection.

Nothing can completely prevent admins from doing stupid things that compromise servers - like keep all the passwords in a spreadsheet on the file server or prop the server room door open with a box fan for extra ventilation. I'm sure the pen testers on the forum have crazy stories about admins that went full retard.

HeroPsycho

astorrs wrote: »

How often do you find yourself needing the local admin password? The answer should be almost never. If someone compromises a single desktop/laptop on your environment and all computers (inc servers) have the same local admin password then they can technically compromise your entire network.

Almost is the key here. A simple situation like the server becomes screwy on the domain, and can't authenticate, and there are no cached creds with admin rights on the computer. Always good to have access in emergencies like that for the right people.

FYI, your suggestion is more secure. There's no doubt about that, and I'd recommend doing it that way in most situations, too. It's also tougher to manage, too.

In our situation, we needed them all the same because we're about to migrate the entire AD forest to another forest. Field techs simply don't have time to look up the password in case they need to troubleshoot a workstation that failed the migration.

You could adapt my script though to easily generate random passwords and note them into the spreadsheet report.

royal

Claymoore wrote: »

And with Group Policy Preferences you can reset the local admin password to anything you want. Either way, you need an account that has the ability to create and link group policy objects. With Advanced Group Policy Management in 2008 you can separate the responsibility of creating and approving GPOs for an extra layer of protection.

Nothing can completely prevent admins from doing stupid things that compromise servers - like keep all the passwords in a spreadsheet on the file server or prop the server room door open with a box fan for extra ventilation. I'm sure the pen testers on the forum have crazy stories about admins that went full retard.

Agreed/True. And speaking of AGPM:
Advanced Group Policy Management 3.0 | Elan Shudnow's Blog