DOWNLOAD THE CODE:
Download the Code Listing_01.txt

Download the Code Listing_02.txt

Download the Code Listing_03.txt

Use Perl for Win32's AdminMisc extension

Irecently received an email from a reader who said, "I saw your article on Perl scripting, and I want to know if there is an automated utility I can use to change the administrator password on the local Security Accounts Manager (SAM) for every workstation within my domains. I must change my administrator password every 90 days, so it's unrealistic to walk to each machine to accomplish this task. Also, using User Manager for Domains to access each local SAM is very inefficient. If no utility exists, how do I go about creating such a tool?"

Sound familiar? I'm aware of only one commercial solution that helps with this classic Windows NT systems administration chore. Furthermore, the chore isn't limited to workstations, but includes domain and member server accounts. The good news is that you can write a simple script to automate this task.

Choose Your Weapon
You can take many different routes to write the password automation script. For example, you might use:

  • Microsoft's Active Directory Service Interfaces (ADSI) 2.0 and Perl for Win32's OLE Automation extension
  • ADSI 2.0 and Windows Scripting Host (WSH)
  • Third-party scripting and command languages, such as Advanced Systems Concepts' eXtended Language for Windows NT (XLNT) or FastLane Technologies' FINAL
  • Perl for Win32's AdminMisc extension

Because of limitations with ADSI's and WSH's support of NT 3.51, the first two options might not be your best choice. And if you don't have a third-party scripting solution, the third option isn't viable. So, Perl for Win32's AdminMisc extension is a good option to use. AdminMisc provides a variety of NT systems administration functions that are not part of the standard Perl for Win32 distribution.

Listing 1, page 192, contains an excerpt from a script, PWManager.pl, written with Perl for Win32's AdminMisc extension. (For the entire PWManager.pl script, a complete list of AdminMisc functions, and information about how to obtain and install AdminMisc, go to Windows NT Magazine's Web site at http://www.winntmag.com.) PWManager.pl is a Perl for Win32 script that manages the passwords for identically named accounts (e.g., NT's Administrator accounts) located in multiple-user account databases (e.g., SAM databases). Specifically, the script uses AdminMisc's UserChangePassword to generate a random eight-character alphanumeric password for each account. It maintains the passwords and other related data in a comma-delimited file (i.e., database) that you access in either interactive or batch mode. Interactive mode lets you change one account password in the database; batch mode lets you change all account passwords in the database. At any time, you can generate a formatted report showing the current database contents.

Requirements for Success
You must satisfy two requirements for PWManager.pl to run successfully. First, you must give the account or service that invokes the script (e.g., the NT Scheduler service) administrative privileges on the domain's Primary Domain Controller (PDC), member servers, and workstations. Second, you must properly set up the password database. The database needs to be a Comma Separated Values (.csv) file that resides in the working directory and contains one record per line, five comma-delimited fields per record. Table 1 (page 193) lists the five fields and what they must contain. One field contains the current account password. Maintaining account passwords outside NT's security subsystem is certain to raise eyebrows within many companies. Thus, make sure you have a well-defined security policy that protects and audits this file. (At a minimum, you need to store this file on an NTFS partition.) NT provides the tools with which to develop and implement this security policy.

You need to manually create the password database, ensuring that the passwords in the second field are the current passwords. If you don't know the current passwords and have administrative access to the systems, you can use AdminMisc's SetPassword function to reset the account passwords to a known state. Listing 2 contains an example script, SetPW.pl, that changes the administrator account password on each system listed in the input file, servers.txt. If SetPassword succeeds, the script displays the server name followed by a 1, which is the value of $result. The script assigns $result the return value from the SetPassword function. SetPassword returns 1 if the function succeeds or 0 if it fails. By printing the value of $result along with the hostname, the user can easily see which accounts changed and which did not. If SetPassword fails, the script displays only the server name.

   Prev. page   [1] 2 3     next page



You must log on before posting a comment.

If you don't have a username & password, please register now.

Reader Comments

I read Bob Wells’ interesting August Scripting Solutions column, “How to Manage Your Enterprise’s Passwords the Easy Way,” about changing the administrator’s password across Windows NT systems in one or more domains. In my situation, most of the NT systems are in a large workgroup, not a domain. Can you tell me how to modify the code to work in that environment?<br> --Rich Lichvar<br><br>

<i>If you have administrator access on the target machines the accounts reside on, the script should work without any changes. Of course, in a workgroup environment, you need to have multiple administrator accounts (one on each workstation, member server, domain) with the same name and password. If you tried the script and it failed, check to see that you have an administrator account on the target system with the same name and password as the account you’re running the script under.<br> --Bob Wells</i>

Rich Lichvar- August 11, 1999

Some customers have asked me questions about the script in “How to Manage Your Enterprise’s Passwords the Easy Way” (August), Bob Wells’ article about managing remote accounts via Perl. My customers were confused about the effects of changing the passwords of accounts that they run various services under (e.g., MTS, SQL Server, IIS). They were thinking (hoping) that if they changed the password for an account, they would not have to bounce the service. I hated to tell them they would have to bounce the service after they change the account password.<br> --Jim Carroll<br><br>

<i>Thanks for the feedback. As you point out, I didn’t design the password-manager script to manage service-related accounts. That is, the script doesn’t handle updating the Service Control Manager (SCM). Thus, if a service account password changes, the user will have to update the applicable service in Control Panel’s Services applet and restart the service. Thanks for reading, and keep your eyes peeled for a Service Account Password Manager script in the near future.<br> --Bob Wells</i>

Jim Carroll- August 11, 1999