Rem: Adding the Currently Logged On User to the Administrators Group

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:

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:

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.