DOWNLOAD THE CODE:
Download the Code Listing_01.txt

Download the Code Listing_02.txt

Download the Code Listing_03.txt

SetPassword doesn't require the current password as an argument, whereas UserChangePassword does. SetPassword is equivalent to using NT's User Manager for Domains to change a password, while UserChangePassword is equivalent to using NT's Change Password dialog box. Another difference between SetPassword and UserChangePassword is who can use them. Only Administrator accounts can use SetPassword, and they can change any account password. User accounts can use UserChangePassword, but they can change only their account password.

How PWManager.pl Works
Now that you know the strategy for automating password changes and how to set up the password database, let's examine how PWManager.pl works. This script uses command-line arguments to determine what task to perform. Table 2 (page 194) lists the supported command-line arguments and corresponding actions. Figure 1 (page 194) contains examples of how you use the options with PWManager.pl.

PWManager.pl has three sections: the main script block, the format definition, and the subroutines. Because the main script block calls the subroutines, let's look at the subroutines first.

The Subroutines
PWManager.pl uses seven subroutines: CreateHostList, CreateReport, Password, ReadRecord, SortPasswordDB, Usage, and WriteRecord. Here's a brief description of each subroutine.

CreateHostList. When the script passes a valid password database filename to this subroutine as an argument, CreateHostList returns an array of hostnames from the first field of the password database. CreateHostList uses Perl's map function to extract the server names.

CreateReport. This subroutine generates the formatted password report. CreateReport accepts two arguments: the password database filename and the username.

Password. This subroutine generates a random eight-character alphanumeric password. The script writes the new password to the second field of the password database.

ReadRecord. This subroutine fetches and returns the current password for a specified system from the password database. ReadRecord accepts two arguments: the password database filename and the server name.

SortPasswordDB. When the script passes a valid password database filename to the subroutine as an argument, SortPasswordDB sorts the password database. SortPasswordDB sorts the database records without regard to individual fields. Because field one contains the hostname, it sorts the database by hostname.

Usage. When the question mark character (?) appears in the first command-line argument, Usage prints script instructions on the console of the person executing PWManager.pl (i.e., the user). The instructions state that the user must have Administrator privileges, describe how to set up the CSV database, and provide other information and examples.

WriteRecord. This subroutine writes one data record to the password database. WriteRecord requires six values: the password database filename, server name, new password, old password, time stamp, and status.

The Main Script Block and Format Definition
Now that you know what the subroutines do, let's look at how the main script block uses them. The main script block begins by importing the AdminMisc module with the use command. The script tests to see whether the first command-line argument includes the ? character. If it does, the script calls the Usage subroutine, which displays the script instructions on the console of the person executing the script, and then exits.

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

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

 
 

ADS BY GOOGLE