Using the InputBox function has one problem: It doesn't support input masking. Thus, when Joe User types swordfish into the dialog box as his password, he'll see swordfish on the screen, rather than the preferred row of asterisks (*********). If you're running the password-changing script on Windows 2000 or earlier, you'll have to live with this limitation, but if you're running the script on Windows Server 2003 or Windows XP, you have another option. These versions of Windows support the scriptpw.dll component, which masks user input. Scriptpw isn't perfect—it doesn't represent each character with one asterisk to help the user see what he or she is doing—but it's more secure than letting users type unhidden passwords into an input box.
The HidePwd subroutine shows the code for using Scriptpw. HidePwd's code is similar to that of CheckPwd except that HidePwd prompts the user for input from the command line instead of from a dialog box and HidePwd hides the user input. The echoed line feed after each request for the password inserts a carriage return after the script output. Without the return, all the output would be on one line, which is ugly.
So that you don't have to have two versions of the password-changing script, Userpword.vbs tests for the OS, then runs the appropriate password-collecting subroutine. The object that represents the computer has an OperatingSystemVersion property that you can query. You don't need an exact match. You just need to know whether the version is less than 5.1, which is the version number for XP. The script already used the WshNetwork object to collect the computer's name, so the code at callout B in Listing 2 checks the OS version on the local computer.
Whichever password-collecting subroutine it uses, the script stores the new password in sPword2 and the old password in sPword1, then plugs them into the code at callout C, which actually changes the password. If the user doesn't provide the correct old password, the script fails with a relatively self-explanatory error: The specified network password is not correct.
Setting Account Passwords
To set a password for an account for which you don't have the current password, you take a slightly different approach. Your script needs to
- accept the input of a username and domain
- look up the username in the security database
- prompt for the new password
- set the new password
- require the user to change the password at the next logon (so that the administrator will no longer know it)
- record that the password has been changed
The password-setting script called Adminpword.vbs, which Listing 3 shows, uses a lot of code already written for the first two scripts. From Disableuser.vbs, Adminpword.vbs gets the code that accepts a username and domain and connects to the appropriate user account. From Userpword.vbs, Adminpword.vbs gets the subroutines that prompt the user for a new password. The subroutines in Adminpword.vbs are slightly modified because you don't need the current password. (You could hard-code a new default password into Adminpword.vbs, but doing so isn't a good idea. If you hard-code a password into a .vbs file, it's saved in plain text.) The remaining tasks of setting the new password, forcing the user to change it at the next logon, and recording that the password has been changed are pretty simple to code.
To set the new password, you substitute the SetPassword method for the ChangePassword method and supply only the new password, as the code at callout A in Listing 3 shows. The PasswordExpired property controls whether users must change the password when they next log on. If the property's value is 0, the password is still valid; if 1, the password has expired. Therefore, to force the change, you just write a value of 1 to this property. If oUser represents the user account, the code at callout B in Listing 3 forces the change.
The final step in disabling an account or changing its password should be to note the change in the Event Log so that you have a record of it. As you'll recall from a previous column about editing the Registry, to write to the Event Log, you need to connect to the WshShell object and use the LogEvent method with the event type and some explanatory text as arguments. In this case, the event is informational, so it's a type 4 event. The time and date will be recorded with the event, so you don't need to include them. To record password changes, include event-logging code at the end of the main body of the script, as the code at callout C in Listing 3 shows.
Disabling unused user accounts and changing passwords are important tasks that need to be as simple as possible to execute so that you'll actually get them done. But changing a password from Win2K's GUI, for example, requires six steps. By using the scripts in this column, you can easily enable and disable user accounts, let users change their own passwords without having access to the Windows Security dialog box, and set new passwords on important accounts. You've also seen how to check the OS of the computer on which a script is running so that you can use the code that's appropriate to that platform.
End of Article
danny_satterlee August 21, 2004 (Article Rating: