| Downloads |
|---|
| 4658.zip |
Your company has just fired a systems administrator. You now need to quickly change all the Domain Admins passwords in your company's Windows NT network. Instead of manually changing passwords, you can use NT shell scripts to automate the process. These scripts will save you even more time in the future, because you can reuse them as long as you're running NT.
Because your WAN probably has several NT service accounts with Domain Admins privileges, you also need to update the NT services' configurations. Otherwise, the accounts will likely lock themselves out the first time they attempt to perform a task requiring the use of those privileges. The NT shell scripts in this article let you change most of your NT service accounts rapidly and securely, thereby maintaining security with a minimal interruption to functionality. However, some NT service accounts require special procedures to change. For example, if you change the Exchange Service Account incorrectly, the consequences are catastrophic. (The sidebar "Changing the Exchange Service Account Password," page 12, describes the special procedure you need to implement to change the password for Microsoft Exchange Server.) So before you create the NT shell scripts, you need to check the documentation to find out whether you need to implement any special procedures for your NT service accounts.
To create password-change scripts, you need domain administrator permissions, knowledge about which systems are running the services you need to change, and attention to details. (As with any procedure to change passwords, carelessness can have serious consequences.) The only tools you need are a blank disk, the Microsoft Windows NT Server 4.0 Resource Kit, spreadsheet software (e.g., Microsoft Excel), and a text editor (e.g., Microsoft Notepad). With these tools in hand, you are ready to perform the following 11 steps.
Step 1. Prepare Safety Nets
As a precaution, you first need to prepare two safety nets: a recovery disk and a duplicate of the current Domain Admins account. To make a recovery disk, insert your blank disk in the disk drive of your Primary Domain Controller (PDC). Click Start, Run, and type rdisk /s. To make a duplicate of the current Domain Admins account, copy your account into a new account with a name such as DoNotChangeMe. (You might need to assign special privileges to this account in applications such as Exchange Server.) Do not include this account in your scripts.
Step 2. Make Sure You Have the Necessary Utilities
To make sure the resource kit utilities are in your search path, open a command prompt in a clean directory in an uncluttered folder. Type PATH, and press Enter. If you don't see the resource kit utilities directory in the path (typically c:\ntreskit), you can either temporarily add it to your current command-line session or permanently add it as a global element of the PATH system variable. To add the resource kit utilities to your current command-line session, type
SET PATH=%PATH%;c:\ntreskit
Press Enter. To add the resource kit utilities as a global element of the PATH system variable, select Start, Settings, Control Panel. Double-click System, and select the Environment tab. In the System Variables dialog box, select Path. In the Value field, add the full path to the resource kit (e.g., c:\ntreskit). Click Set, then OK. You will need to restart the system for the change to take effect.
Step 3. Dump the Computer List
Dumping a list of computers to a text file is optional. However, I highly recommend the procedure because you eliminate the possibility of misspelling the computers' names. Placing a list of computers in your working directory is easy. At the command prompt, simply type
NET VIEW >systems.txt
Step 4. Dump the Users List
Dumping a list of usernames to a text file is also optional, but I recommend it. To get a list of the usernames in the Domain Admins group, go to a command prompt on a domain controller and type
NET GROUP "Domain Admins">admins.txt
Delete your safety net account (e.g., DoNotChangeMe) and any other special NT service accounts from the user dump file.
Step 5. Dump the Services List
Dumping a list of running services to a text file is mandatory, because many services have a user-friendly display name that differs from the name that the OS recognizes (i.e., the service name). You can use two tools to output a list of services: netsvc.exe or sclist.exe. The tool of choice is netsvc.exe from the resource kit because the output from netsvc.exe is easier to manipulate.
The service for which you want to change the passwords must be installed on the system you query so that you can see the proper spelling of the service name. (If you use the display name or misspell the service name, the tool won't work.) At the command prompt, type
netsvc /list \\computer name>services.txt
in which the variable computer name is the name of the computer whose services you want to list. As Screen 1 shows, the output includes all services, running or not.
Step 6. Create the Scripts
You need to use a text editor to prepare your dump files (i.e., systems.txt, admins.txt, and services.txt) for import into a spreadsheet. Begin by deleting the headers, footers, and unnecessary white space so all that remains are the applicable computer names, service names, or usernames. Next, remove any extra formatting characters (e.g., tabs) from all three lists. Manually deleting the unnecessary formatting can be tedious, so use a search-and-replace function to pare all three files down to three simple single-column text files containing the relevant information (i.e., computer names, usernames, and service names).
For example, as Screen 1 shows, the raw service name output from the netsvc.exe dump has a tab before the first < symbol. Search for tab< and replace it with nothing. (You need to use a word processor rather than Notepad, because Notepad can't search for tabs.) Then search for the > character and replace it with nothing. Finally, import the text file into your spreadsheet as comma-delimited text and delete the column containing the display name information, leaving you with the list of service names.
Preparing the computer names and usernames is trickier, especially if any of the desired names include a space. I recommend that you first delete the unnecessary computer names and usernames and then look closely at the remaining names to see whether they contain spaces. If so, manually replace the space with an illegal character, such as a backslash. Next, import the files into your spreadsheet as space-delimited files, treating consecutive delimiters (i.e., more than one space) as one space. Delete columns of useless information, such as the remarks in the systems dump. Finally, use the spreadsheet's search-and-replace function to replace the backslashes with spaces.
Keep all three spreadsheets in the same file. Make sure you have at least two empty spreadsheets for script building.
Now you can create the scripts to change the passwords in the domain. You might be tempted to create one large script that includes all the password changes for your Domain Admins account (i.e., user-management changes) and all the changes to update the configurations of your NT services (i.e., service-management changes). However, I recommend that you create a user-management script and a separate service-management script for each service, because you can troubleshoot glitches more easily.
For example, if you must update the Directory Replicator service account and the Monitor service account, you should have three scripts: one user-management script, one service-management script to change the Directory Replicator service account, and one service-management script to change the Monitor service. That way, if one script fails, you can focus on correcting that script instead of reprocessing any changes that the script might have made before it failed. This approach also lets you process and monitor several service updates simultaneously.
After you determine how many scripts you need, you can start creating them. Suppose you determine that you need two scripts: one to change the Domain Admins account passwords and another to change the Directory Replicator service account passwords. Here's how you create them.
Domain Admins account script. In the script to change the Domain Admins account passwords, you use the syntax
ECHO username>>AdminError.txt & NET USER username new password 2>> AdminError.txt
in which username and new password are variables. Start your script with the ECHO command, which redirects the output to the file that the >> character specifies. In this case, the output goes to the AdminError.txt file. If the file already contains contents, the command interpreter adds the new content at the end of the file. (Be careful not to use the > character, because the > character overwrites rather than appends preexisting file content.) You can index the operation by simply placing the username after ECHO.
Next, use the logical AND (&) operator, then the NET USER command. You use NET USER to manage user accounts; in this case, you're giving users new passwords. Finally, use 2>> to redirect the command error output to the end of the AdminError.txt file.
Because each line in this script has the same syntax, you can use a spreadsheet to do much of the work. Create a new spreadsheet and name it something like ChangeAdminPW.xls.
In this spreadsheet, type ECHO in cell A1, >> in C1, AdminError.txt in D1, & in E1, NET in F1, USER in G1, 2>> in J1, and AdminError.txt in K1. For each of these columns, use the Fill Down option under the Edit menu to quickly copy the entry down the entire column. Format columns C and J as text to avoid having the spreadsheet program enclose these logical operators in quotation marks. (When you save and export a spreadsheet, the spreadsheet program encloses any logical operator in quotation marks by default.) In columns B and H, paste the list of usernames from the spreadsheet containing the admins.txt dump file. In column I, type each user's new password. The completed spreadsheet will look similar to the one in Screen 2.
Now, save the spreadsheet as a comma-delimited file (.csv), close it, and open the file in a text editor. Use the search-and-replace function to replace all the commas with spaces, and tweak the file (e.g., add quotation marks to strings) if necessary. Finally, rename the file, and save it as a command (.cmd) file.
Directory Replicator service account script. In the script to change the Directory Replicator service account passwords, you use the syntax in Listing 1. In this syntax, target_system and password are variables.
As before, start this script with the ECHO command, redirecting the command output to Config.txt. Next, use the logical & operator, then the SC command, which manages NT services. Use CONFIG with the service name (not the display name) to specify that you're reconfiguring the Directory Replicator service. Apply the OBJ= switch to specify the account and the PASSWORD= switch to specify the new password. (Switches modify the operation of a command.) If you have a lot of passwords to change, you can again use a spreadsheet to help you create the script. When you use the SC command, I recommend you get in the habit of enclosing the system name (e.g., "\\target_system") and service name (e.g., "Replicator") in quotation marks because then the syntax works, even when the system name or service name has non-alphanumeric characters in the string.
For the changes to take effect, you need to stop and restart that particular NT service. Using a script to stop and restart a service is the best approach. Use the SC STOP command to stop the service, and use the SC START command to restart it. Stopping and starting a service via a script is easier than rebooting your system or logging off and on. In addition, if you use a script, you can check the script's logs to immediately discover any failures.
Step 7. Test the Scripts
The first (and easiest) test is to try to open the scripts in your spreadsheet program. But first you must change each file's extension to something other than .csv. I recommend changing the extension to .txt; otherwise, the program fills one cell with an entire line, which makes checking syntax difficult. If the scripts open as nicely formatted space-delimited files, you have a consistent command structure.
The next test is to run the scripts in a test lab. If you don't have a test lab, consider testing the scripts on an isolated PDC. If that's impossible, you need to take an important precaution before you execute the scripts: Create additional scripts with all the current passwords so that you can quickly restore your system if the scripts don't work as you planned. Remember to store any scripts containing passwords or other restricted information in a secure directory.
After you test the scripts, open the output files (i.e., AdminErrors.txt, Config.txt, Start.txt, and Stop.txt) and look for error messages. You might want to comment out your first script and process a few bogus usernames and passwords to get accustomed to identifying error output.
Step 8. Fix the Scripts
Error messages usually result from punctuation, spelling, and other syntax errors. After you correct the errors you find, test the scripts again. Continue this process until you get a clean run. Although repeating this process can be tedious, it's worth it. Once you get a clean run, you've got a tool that you can use for the life of your NT domain. You will need to make only a few minor periodic modifications, such as adding new service accounts to the script when you add them to the domain.
Step 9. Use the Scripts
When you perform the full-scale implementation of the scripts, I recommend that you be in a room with at least three systems: a PDC, a Backup Domain Controller (BDC), and an NT 4.0 workstation loaded with the Server Admin tools (especially User Manager for Domains and Server Manager). Enable the PDC's auditing and alert functions. Launch the Domain Admins account script first, then log off. Log on again using a new domain administrator password.
If you can log on successfully, run the Directory Replicator service account script and keep your eye on the PDC security log. If you made a mistake in the script, you'll soon know. A service account that fails to authenticate generates a system error, and stopping and restarting the service will cause an authentication attempt. System errors can fill your logs quickly, so continually search for errors and account lockouts. Fix any problems immediately.
You'll probably find a couple of problems, especially in a WAN environment. Common errors include:
- Running the script from a system that is not a PDC or BDC. You can fix this error by formatting the service name in the OBJ= switch as domain\service name (e.g., OBJ= mydomain\ReplAcct) instead of specifying only the account (e.g., OBJ= ReplAcct).
- Forgetting to leave a space after either = symbol. You can fix this syntax error by adding the needed spaces.
- Restarting difficulties. Some services have difficulty restarting if there is less than a 10-second delay between stopping and restarting (especially over a slow link). You can fix this problem by using a different approach to stopping and restarting the service. For example, you can add the code & sleep 10 to the end of each SC STOP command or run all stops for a service before running any starts. As a last resort, you can reboot the system.
If you discover many problems, you must decide whether to fix them manually or stop the script so that you can correct it. To help you make this decision, look at event-log entries carefully to see whether they identify the name of the system generating the problems. If the problems stem from only one or two systems, you're better off fixing the problems manually. (Don't forget to stop and restart the service on each machine for your changes to take effect.) If the log entries identify more than two systems or don't identify any systems, you're better off correcting the script.
Step 10. Spread the Word
Unless you are the only systems administrator in your company, let the other systems administrators (including administrators of other domains) know about the changes you made as soon as possible. Place the proper permissions on all files containing the password list (including the spreadsheets). In addition, print a hard copy of the password list and place it in a secure location.
Step 11. Perform a Security Check
Do a routine security check. For example, make sure none of your Domain Admins account has dial-in privileges and make sure none of your lockout policies has changed.
If Successful, Treat Yourself
You'll know within a short time whether your script works. If it runs flawlessly, use the time that you set aside for troubleshooting for those tasks you never seem to have the time for, such as performing compatibility testing or running a test install of Windows 98. As for me, I'm now four chapters into Perl 5 for Dummies.
