Although Active Directory (AD) provides convenient centralized account management for complex domains, it doesn't handle one account management problem: updating passwords for local Administrator accounts that reside on a member server that isn't a domain controller (DC). The more solid a network is, the easier it is to forget that local Administrator accounts also have local passwords. These accounts can be helpful when you need to get into a computer that can't access a DC and the cached credentials of a domain administrator are absent from the system. However, local Administrator accounts are security vulnerabilities if their passwords are weak or aren't updated regularly. (For more information about cached credentials, see the Microsoft article "How Interactive Logon Works," http://www.microsoft.com/technet/prodtechnol/windowsserver2003/library/TechRef/779885d9-e5e9-4f27-9c14-5bbe77b056ba.mspx.)
If you have a solid network infrastructure with user profiles stored centrally, one security option is simply to disable the local Administrator account, or deny access to it if you're on Windows 2000. (For more information about disabling the local Administrator accounts, see the Microsoft article "How to disable the Local Administrator account in Windows," http://support.microsoft.com/?kbid=281140.) Disabling the local Administrator account means you'll no longer have administrative concerns about it, and you can enable the account temporarily for planned offline work. If you should have a workstation OS failure, the worst problem you're likely to face is automatically rebuilding the workstation using the user's data, which should be safely stored on the network.
However, organizations without a neatly centralized network infrastructure need more options for changing passwords. Some organizations might not have the option of disabling the local Administrator account. For example, they might need to keep that account enabled so that they can still get into the system if the computer loses its connection with the DC.
Other organizations might need to deal with regular offline use, so they must disable cached credentials as part of their security policies. For these organizations, one option is to automate password updates with the Microsoft Active Directory Service Interfaces (ADSI) WinNT provider. Designed for compatibility with Windows NT 4.0 networks, this provider lets you access individual workstation security databases. The WinNT provider is available on Win2K and later systems; you can install it on NT 4.0 by adding the ADSI client extensions from the Windows Server 2003 or Win2K Server CD-ROM.
Using the WinNT provider to change local Administrator account passwords looks extremely easy in the ADSI documentation because the demonstration script consists of only a few lines of code. However, problems often arise when this demonstration script is used in the real world. Let's look at the problems that occur as well as at other considerations to keep in mind when you create a script to update local Administrator account passwords.
Welcome to the Real World
As the demonstration script in the ADSI documentation shows, you can remotely change local Administrator passwords using only a few lines of Windows Script Host (WSH) VBScript code. Let's say you have a computer named PC903 with a local account named la whose password you want to set to tw1nkl3. PC903 is a member of a domain, and you're logged on to that domain as a domain Administrator, which by default has sufficient privileges to remotely administer PC903. The following script is all you'll need:
Set user = GetObject( _
"WinNT://ws903b/la,user")
user.SetPassword "tw1nkl3"
user.SetInfo
This demonstration script is concise, as are most of the sample scripts you'll find in the ADSI documentation. But you have a bit more to do to turn this code into a robust, reliable real-world tool.
One difficulty with this demonstration script is that it doesn't perform any authentication. It simply uses your current credentials to confirm that you have the right to connect to the remote system and change a password. Theoretically, you could stay logged on as a non-administrative user and specify an administrative username and password in the script for when it connects to AD through ADSI on the remote computer. However, after trying this approach, I discovered it produces too many secondary problems while providing minimal extra value.
The first problem I encountered involved maddeningly erratic logon failures on a small domain. After some research, I found that this is a known problem documented in the Microsoft article "User authentication issues with the Active Directory Service Interfaces WinNT provider" (http://support.microsoft.com/?id=218497). If a connection is already established to the computer you want to administer, specifying other credentials will fail.
After I reconciled myself to using the RunAs command or logging on directly as an administrative user, I realized that doing so made this demonstration script simpler and more secure. If you use workstation administration privileges to log on to an account and run the script, you no longer need to worry about how to handle and pass administrator credentials. Windows handles everything automatically.
Demonstration scripts written by programmers generally seem to use one of two error-handling strategies: completely suppress errors, or simply fail and exit. Those strategies are useful for demonstrating a technology, but neither approach is an option when your goal is a robust script.
Ideally, a password-update script should notify you when a password change fails and tell you why it failed. However, you don't want the script to exit just because the first of 200 machines whose Administrator passwords need to be changed is offline. Instead, for each password change attempt, the script should return the machine name, whether the attempt succeeded or failed, and if it failed, the best short explanation possible. Before I go into details about how the script displays output, let's look at the common causes of error.
Using connection strings (e.g., WinNT://ws903b/la,user) makes WinNT calls simple. However, if the call fails, the WinNT provider returns only a numeric error code that requires research to understand. Fortunately, only three errors are common in LAN-based remote connections. All three errors have clear causes, so if you have the script test for those errors and return useful information, the script can be very robust.
The first error occurs when the remote system isn't available. In this case, you usually have to wait a few seconds before the script errors out. In a network situation, this error typically occurs when some machines are inaccessible, usually because they're offline or because they're laptop units that aren't currently connected to the network.
The second error occurs when the user doesn't have sufficient privileges to connect, typically because the user's account doesn't inherit permissions to manage the remote workstation. This situation can arise when the user doesn't log on as a user with domain administration privileges or when the remote system doesn't participate in domain security.
The third error occurs when the specified username doesn't exist on the workstation. This error is a common side effect of irregular naming practices.
As I mentioned previously, these are the three errors most often encountered, but they don't constitute an exhaustive list. You need to account for other possible errors—whatever their causes—in your script. Although your script doesn't need to provide definitive descriptions for them, it should at least return the hexadecimal-formatted error code and a failure message. If you have the hex-formatted error code, you can research a particular problem in the ADSI Error Codes Web page at http://msdn.microsoft.com/library/en-us/adsi/adsi/adsi_error_codes.asp.