One truth about companies is that people come and go. Another truth is that sometimes a person is very unhappy when he or she leaves a company. If an unhappy ex-employee has keys to the office, you change the locks. If the ex-employee has a user account, you need to make sure that he or she can't use it—especially if that user account has privileges that would let the employee do damage. This month, I show you how to programmatically enable and disable user accounts and set passwords for accounts. I also show you a script you can use to permit users to change their own passwords, even if you've disabled access to the Windows Security dialog box for security reasons.
Enabling and Disabling Accounts
Even if an employee's gone only temporarily, rendering his or her account unusable while he or she is gone is often a good idea so that intruders can't use the account to break into the system. (As you might remember, the security breach in Clifford Stoll's The Cuckoo's Egg—Doubleday, 1989—originally took place through the account of an authorized user who was out of the office for an extended period.) However, you don't want to delete an inactive account, because if you do, you'll have to recreate all the security settings associated with that account if or when the user returns. Rather, as any experienced administrator knows, you should disable the account while it's not in use, deleting it only when you're positive that you'll never need the account again.
To make disabling and enabling user accounts easy, you can use the script that Listing 1 shows to disable a user's account when the user leaves and reenable it when he or she returns. The script is simple: It connects to the account in question, then sets the AccountDisabled property. (You can also disable an account by editing a user flag associated with the account, but the method I've shown here is simpler and just as effective for our purposes.) You can make the same code do double duty (i.e., enable or disable the account) by making the value of AccountDisabled an argument to the script; a short Help subroutine tells the user what value to enter to get the desired result. Because the script uses the WinNT namespace, it'll work with both SAM and Active Directory (AD) domains. When you refresh the view in the Microsoft Management Console (MMC) Active Directory Users and Computers snap-in on the domain controller (DC), you'll see that the named account has been enabled or disabled as specified.
Changing Account Passwords
Sometimes disabling the account isn't an appropriate solution—for example, you can't disable an administrative account that multiple people use just because one person leaves under unhappy circumstances. In such a case, you'll need to change the account password.
Active Directory Service Interfaces (ADSI) supports two methods for changing passwords: ChangePassword and SetPassword. ChangePassword requires that the person doing the changing know the original password. ChangePassword isn't much of a tool for administrators because in an ideal world, administrators don't know user passwords. However, ChangePassword is handy when you've used Group Policy or some other means to shut off access to the Windows Security dialog box but want to let users change their passwords. SetPassword, in contrast, just overwrites the existing password with a new one.
A script that lets the currently logged-on user change his or her password should do the following:
- detect the name of the currently logged-on user
- ask for the user's current password
- prompt the user for the new password
- prompt the user to confirm the new password
- compare the two passwords and reject them if they don't match
- change the password and write the new password to the security database
- report that the password has been changed
I've shown you how to script most of these steps in previous columns, so I focus here on how the steps fit together in the script that Listing 2 shows.
First, you need to identify the currently logged-on user. As you might recall, the WshNetwork object's UserName property returns the username of the currently logged-on user. So, to obtain the username, you create the WshNetwork object (WScript.Network), associate that object with a variable (oNet), then use the UserName property to retrieve the username, as the code at callout A in Listing 2 shows.
Now that you have the username for the current user, you can use the InputBox function to ask the user for the current and new passwords. Creating a little subroutine to handle these tasks is the simplest approach. The CheckPwd subroutine uses the global variables sPword1, sPword2, and sPword3 to store the current and new passwords. The subroutine prompts the user for the current password (sPword1), for the new password (sPword2), and for the new one again (sPword3) for confirmation. If the new password and the confirmation password don't match, the subroutine informs the user and starts over. The comparison of sPword 2 and sPword 3 is case sensitive, so FROG and frog won't match.
As I explained in an earlier column, VBScript's InputBox function always displays an OK button and a Cancel button and can take as many as three arguments, as in
InputBox(prompt, title, default)
where prompt is the text within the message box, title is the text in the title bar, and default is the default value. Because you separate these arguments with commas, you can't use commas within the prompt or title. Instead, you must use the concatenation operator (&) as I've done in the CheckPwd subroutine.