This is still very helpful though written 4 years back. The script that brought this article to my attention involves automating the routine of replacing local administrator passwords. The suggestions of using error handling and an output txt list of the failed computer accounts so that you correctly and completely standardize the passwords at some future time. A heterogeneous password environment could be nightmarish to manage.
Automate Your Security
Many security-related tasks can be tedious—and, therefore, overlooked. Using these 10 scripts can make your life easier, while simultaneously locking down your network.
by Don Jones
Security, of course, has become a lot more important than it used to be in the “old days,” when we were merely concerned about keeping all the servers up and running. Unfortunately, much of security involves routine, repetitive tasks, like backing up event logs, keeping track of service account passwords and so on. There’s a growing market of third-party utilities out there to help manage those tasks, but the concern about security has coincided with reductions in IT budgets, making it difficult to buy every new tool that promises to do the job for you.
Fortunately for the harried administrator, Windows comes with two perfect built-in tools that can handle much of your security automation: Windows Script Host (WSH), and VBScript. While I won’t promise that WSH can stop hackers and take your next certification exam for you, it certainly can remove the monotony out of many security-related tasks. In fact, simply having some automation around makes it more likely that you’ll do these boring tasks to begin with, thereby making your environment that much more secure.
Changing the Local Administrator Password
Enough with services and service accounts. Another tedious task is periodically changing the local Administrator password on every computer in your company. You know you should do it, but who has that kind of time? Scripts do! Once again, start with an input text file that lists one computer per line. In case you’re wondering, it’s also possible to retrieve a list of computers from AD, an NT domain or even a database, with a little bit of extra programming.
This script starts out similarly to the last, by opening a text file and using a “Do…Loop” construct to iterate through each line of the file. However, this script doesn’t connect to a WMI provider on each computer. It relies on the Active Directory Scripting Interface, or ADSI, to connect. Wait a sec—ADSI? Does this only work on 200x domain controllers? Nope, this script will run against everything from NT 4.0 on up, including NT Workstation, 2000 Pro, and XP Pro, because all NT-based operating systems have an NT domain-like Security Accounts Manager (SAM). Notice how the ADSI connection uses the “WinNT://” moniker, which tells ADSI to stay NT-compatible.
The ADSI connection specifically queries a user account named “Administrator,” and then changes its password and saves the change back to the SAM. You can run this script on a monthly basis, if you like, with a word of warning: As written, the script doesn’t include any error handling, so it will crash if one of the specified computers isn’t available at the time. A quick and dirty way to bypass the crash is to add:
On Error Resume Next
As the first line of script code. This will cause the script to ignore any errors and try the next computer in sequence. If you want to be a bit more thorough, you could save the failed computer names to a new text file, which could be used to run the script again the next day.
‘Create a FileSystemObject
Set oFS = CreateObject(“Scripting.FileSystemObject”)
‘Open a text file of computer names
‘with one computer name per line
Set oTS = oFS.OpenTextFile(“c:\computers.txt”)
‘go through the text file
Do Until oTS.AtEndOfStream
‘get the next computer name
sComputer = oTS.ReadLine
‘retrieve that computer’s local Admin
Set oUser = GetObject(“WinNT://” & _
sComputer & “/Administrator, user”)
‘reset the password
‘save the change
‘close the text file