| Downloads |
|---|
| 24595.zip |
I'm trying to add the currently logged on user to the local Administrators group on Windows 2000 Professional workstations in a Windows NT 4.0 domain. The users are members of the local Users group and aren't administrators on the local computers. I know the script must run under the security context of the local administrator, but I'm uncertain about how to proceed. Can you help?
You can use the Microsoft Active Directory Service Interfaces (ADSI) IADsOpenDSObject interface's OpenDSObject method to supply the local administrator's security credentials to the script, as Listing 1 shows. To use OpenDSObject, you must first bind (i.e., connect) to the target ADSI provider, which is WinNT: in your case, and use the returned reference to call OpenDSObject.
Let's take a closer look at the script in Listing 1. I begin the script by defining the ADS_SECURE_AUTHENTICATION constant, which I later pass to OpenDSObject to specify the type of authentication to use. ADS_SECURE_AUTHENTICATION tells the ADSI WinNT provider to use NT LAN Manager (NTLM) authentication.
Next, I create a Windows Script Host (WSH) WshNetwork object and use this object's ComputerName property to retrieve the name of the local computer. I then initialize a string variable named strGroup, which identifies the target group.
The code at callout A in Listing 1 binds to the WinNT provider. The sole purpose of this code is to obtain an ADSI reference, which I subsequently use to call OpenDSObject. OpenDSObject accepts four parameters:
- The ADsPath to the target object, which is the local computer's Administrators group
- The username with which to authenticate the connection, which is the local computer's Administrator account
- The password for the user account that the second parameter identifies
- Authentication flags that identify the type of authentication to use for the connection
If the connection succeeds, the last line of the script adds the currently logged on user to the local computer's Administrators group. To obtain that user's name and domain, I use the WshNetwork object's UserName and UserDomain properties.
Knowing the code to use is only half the battle. The other challenge is safely providing the local administrator's password to the script. You can approach the problem several ways:
- You can prompt the user for the password. This approach requires that the users know the local Administrator account's password. Giving users this password defeats the purpose of trying to safely provide it to the script.
- You can hard-code the password in the script, then use the Microsoft Script Encoder to encode the script. Bear in the mind that the Script Encoder uses a relatively simple encoding algorithm that's intended to protect the script's source code from being modified or viewed by casual observers. A determined intruder would likely be able to crack the encoding algorithm and thereby gain access to the script's source code.
- You can store the password in an external file and store that file on a file server. The script must have read access to the password file, which means the users running the script must also have read access to that file.
- You can split the script into multiple scripts and store the sensitive script on a file server. You can then use a stub script on the client to run the sensitive script. The stub script is a client-based script that spawns the server-based script. The server-based script adds the current user to the local Administrators group.
- You can host the sensitive portion of the script in an ActiveX component.
Each solution represents different risks and provides varying degrees of safety. Regardless of the solution you implement, the bottom line is that storing passwords outside a secure repository is dangerous. Understanding the risks and designing a solution to minimize them is key to implementing the safest possible solution. I also encourage you to implement some sort of auditing, logging, or tracing function in the event someone compromises the solution.
To learn more about the IADsOpenDSObject interface's OpenDSObject method, see the ADSI software development kit (SDK) documentation in the online Microsoft Developer Network (MSDN) Library (http://msdn.microsoft.com/library/default.asp). You can easily locate the information by searching for IADsOpenDSObject.
