Handy Web Script Creates User Accounts, Part 1

Give your Help desk an easy way to add user accounts to AD

The Microsoft Management Console (MMC) Active Directory Users and Computers snap-in is a fine place to create user accounts in Windows 2000 domains. You can customize an MMC snap-in for your Help desk staff and limit staff members' access to management functions, then send the customized console to the users or make it accessible through Win2K Server Terminal Services. But an even better approach is to script user-account creation and make the script available from a Web page. Then, all your Help desk staff needs is a URL and Microsoft Internet Explorer (IE) to administer user accounts. This two-part article explains how to create such a script. In Part 1, I provide an overview of how the script works and how to configure your scripting environment for the script. In Part 2, I'll show you the details of the script and how to customize it for your network.

Configuring the Web-Script Environment
To use Microsoft technologies for Web-based scripting, you need to install Win2K Server. A default installation includes Microsoft IIS 5.0 and all the scripting components necessary to create the user-account—creation tool.

Before you begin to script, you must set up an IIS virtual directory to host the account-creation site and configure IIS so that it accesses Active Directory (AD) securely. First, determine where you want to put the script and the virtual directory. The best location for the user-creation script is on a domain controller (DC). The script uses a COM object to bind to AD, and COM objects won't use integrated Windows authentication (NT LAN Manager—NTLM—or Kerberos) through the IIS service. The script could specify username and password information when binding to AD, but this approach compromises security. The best solution is to place the script and file structure on a DC and point to them from an IIS virtual directory running on another server. This setup requires that you specify the user account and password information in the IIS interface.

Just because the script resides on a DC doesn't mean that the virtual directory and IIS must run there, too. You can place the virtual directory on another computer, such as a member server. Locating the virtual directory on a member server offloads IIS processing from the DC. Also, if different teams manage your Web server and DC, placing the virtual directory on a Web server better accommodates your IT operations structure. You can't place the physical directory on a member server that runs IIS because such a configuration won't pass authentication information to the DC.

After you've decided where you want to place your script and virtual directory, create a physical directory on a DC to house the script. I named the directory UA, but you can give it any name that seems fitting. Place the directory on an NTFS partition, and use NTFS permissions to restrict access to only those users who you want to run the script. If you plan to create a virtual directory on a member server, create a share that makes the physical directory available on the network. Follow these steps to create the virtual directory that points to the physical directory:

Next, you need to configure the virtual directory. In ISM, right-click the virtual directory, select Properties, and go to the Virtual Directory tab. Figure 1 shows how I configured a virtual directory on a member server to point to the share on DC server1 that houses the Web content. The configuration of the virtual directory affects the way in which users authenticate to the Web pages within it. Integrated Windows authentication is crucial to the proper function of the user-creation script and is important for securing access to administrative functions. Follow these steps to enforce integrated Windows authentication:

After you create your virtual directory and configure its properties, you're ready to create a directory structure below the parent directory to house the user-creation script. Open Windows Explorer to the virtual directory's physical location, and create a subdirectory named Main. You'll place the user-creation script in the Main directory.

The user-creation script uses a global.asa file, which Listing 1 shows. A global.asa file is a central repository of scripts that an application's Web pages use. You place the file in the root directory of the application's virtual directory. IIS processes the file automatically when IIS starts and stops and when you start and stop browser sessions that access Web pages in the virtual directory. You can use a global.asa file to initialize application or session variables, connect to databases, send cookies, make type libraries available throughout an application, or perform other operations that pertain to multiple pages, or scripts, in an application. The default global.asa file contains more code than Listing 1 does; Listing 1 shows only what's relevant for running the user-creation script.

The user-creation script uses the global.asa file to maintain type libraries. Although you could maintain the type libraries in the user-creation script, using a global.asa file for this purpose is a good idea. If you added to the user-creation application another script that used these libraries, the global.asa file would save you the trouble of specifying again the libraries or constants contained in the libraries.

Place the global.asa file in the virtual directory's root directory (i.e., UA, in my virtual directory). Modify the path in global.asa's two METADATA TYPE lines to match your system's path to the two specified files: msado15.dll and activeds.tlb. These files are installed by default when you install Win2K Server and IIS 5.0. Msado15.dll is the ADO type library included with IIS 5.0. Placing it in global.asa provides global access to the ADO object model. Activeds.tlb is the Active Directory Services type library. Placing this file in global.asa makes the Microsoft Active Directory Service Interfaces (ADSI) object model available to your scripts. You need both ADO and ADSI to run the user-creation script.

A Bird's-Eye View of the User-Creation Script
When the Help desk staff member enters the user-creation script's URL, the script displays the form that Figure 2 shows. After the Help desk operator completes and submits the form, the script checks the form's entries. If the entries look OK, the script uses a process called binding to establish a connection to the AD store. When binding is completed, the script checks whether the user already exists in the AD store. If the user doesn't exist, the script retrieves the AD organizational unit (OU) in which it will create the user. Finally, the script creates a new user account and informs the Help desk operator whether account creation was successful.

In Part 2, I'll point you to the functions and procedures that perform the user-creation script's main tasks. However, I won't describe the fundamentals of scripting, such as variable declaration, variable initialization, functions, and subprocedures. For some resources that describe scripting fundamentals as well as Active Server Pages (ASP) fundamentals, see the Web-exclusive sidebar "Resources for the Script's Technologies" in "Create Home Directories and Set NTFS Permissions with a Web Script," http:// www.winscripting solutions.com, InstantDoc ID 22048. In addition, if you're unfamiliar with ADSI basics and how to use ADSI to create user accounts, see Alistair G. Lowe-Norris's 12-part series "An ADSI Primer," January through December 1999, and Thomas Eck, "Practical Usage of ADSI: Managing User Accounts in Win2K and NT," March 2001. In addition, in Windows 2000 Magazine (http://www.win2000mag .com), check out Bob Wells, "Easy Active Directory Scripting for Systems Administrators, Part 1," InstantDoc ID 9168, and "Easy Active Directory Scripting for Systems Administrators, Part 2," InstantDoc ID 15734.

Just the Beginning
Now you should have a sense of what this script does and how to prepare your environment to support it. If some of these technologies are new to you, find the articles I reference and review them. Begin to prepare your scripting environment. Next month, I'll show you the details.