Accessing AD Through IIS, Part 2


Putting your Web-based application to work

\[Author's Note: In this issue, I build on information from my article "Accessing AD Through IIS," June 2001. Please refer to that article for server configuration information.\]

In "Accessing AD Through IIS," I began showing you how to create a Web-based application to search and modify Active Directory (AD). In this issue, I describe in more detail how you can implement this type of interface in a real-world environment. In particular, I use some Active Server Pages (ASP) coding examples that illustrate how to use Microsoft Internet Explorer (IE) to modify information stored in AD.

A Real-World Scenario
Let's start by looking at a company that has 500 employees. The IT department is made up of 20 people whose main responsibility is day-to-day maintenance of the Windows 2000 server environment, routers, the corporate intranet portal, dial-up connectivity, and security. These folks don't have time to manage a lot of user requests; thus, each department manages its environment with respect to users and applications.

When the company hires a new sales person, the human resources (HR) department adds the user to the payroll and HR management system. Using an email-based user template, the HR department passes information about the new employee to the sales department Help desk personnel, who add the user to the Win2K network with the appropriate rights and permissions.

When the user starts working, his job function requires that he have access to sales department customer relationship management (CRM) systems and the salestracking systems. The new employee must contact the person managing each of those systems to obtain the required access. The number of systems-management personnel responsible for that user has increased because all the user's information must be maintained across multiple systems and, potentially, multiple platforms.

Managing all a user's information, including associated accounts and security information, through one far-reaching application, such as a Web application, would be a great enhancement. By extending AD to allow for application-specific attributes, you can create an integrated security store that will alleviate the need for multiple points of administration. Then, your developers can create a Web-based interface to securely manage attributes, including custom attributes, associated with a user through an intranet, an extranet, or even the Internet. With such an interface in place, you can then use Group Policy Objects (GPOs) to restrict those objects and attributes to the departmental administrator or application administrator who has rights to administer them.

GPOs and AD
GPOs are Microsoft's core Win2K components for Change and Configuration Management (CCM). GPOs let you use a distributed security-administration model by delegating permissions to manage objects in AD to users who might not be full systems security administrators.

GPOs are stored in AD, so they're secure. You can apply group policies based on local, site, domain, and organizational unit (OU) memberships. Similarly, the system loads group policies in the same order.

For example, the system applies group policies that you set at the local level before those from the site level and the domain level. The system also uses inheritance, but in a reverse order. For example, OUs inherit from domains, domains inherit from sites, and so on. Group policies are replicated throughout the domain through the File Replication service (FRS) and are applied on a regular schedule (by default, every 90 minutes). Because you can apply GPOs under realtime conditions, they're a rich enhancement over system policies, which are applied only at computer startup or user logon.

A Need for a Tool
From an administrative standpoint, Microsoft doesn't provide many user tools for managing the default user attributes stored in AD. Although Microsoft provides a robust scripting interface, only a limited set of utilities for user and group administration are available. Unfortunately, those tools are restricted in scope, and Microsoft didn't design them to be modified or customized. In addition, no Web-based management utility for AD ships with Win2K.

Fortunately, by configuring your Web server to allow user authentication through the Web, you can have an application that permits Web-based user management. You can also use AD as a centralized security store for all applications you want to integrate. Such a centralized security and Web-based management system lets you access the security store to create or manage user accounts for applications or manage other custom attributes associated with an application from the Internet through a standard browser. As wireless technology increases in popularity, you might ultimately need the ability to access such administrative tools from anywhere in the world at any time.

Building the System
To create a system like the one I'm describing, you must begin by making all the necessary modifications and extensions to the AD schema. (See "Related Reading" for more AD resources.)

After you've modified and documented the schema, you need to configure your IIS 5.0 Web server, which will run the Web-based management application. Kerberos, which is the default authentication protocol in Win2K, lets you use the Delegate Trust function on the Win2K domain for the Web server. Delegating trust to the Web server gives it the ability to properly pass the credentials of incoming users for authentication and authorization purposes. You must select the Delegate Trust function for the Web server on a domain controller (DC). My June 2001 article lists the steps necessary for configuring changes on the DC.

When you've made changes to the DC, your developers can write a Web-based application to interface with AD; through this interface, you can customize AD attributes. Here's how you'll use the Web-based application when it's in production:

  1. Access the application through the Web server (either an Internet or an intranet server).
  2. Authenticate to the domain through the Web server.
  3. After successful authentication, the application loads and displays all the application-specific attributes available through AD.
  4. Make any necessary changes to the administrator's account through the Web-based application.
  5. Save the changes.

Let's look at two examples of how you can use a Web-based interface to perform programmatic management on AD. The first scripting example is ChangePass.asp, which Listing 1, page 9, shows. This script shows how you can easily create a Web form that lets users reset their passwords through a secure connection from an intranet, an extranet, or the Internet. The script is simple, and it uses an exposed interface from the Active Directory Service Interfaces (ADSI) API in Win2K.

ChangePass.asp starts with a Web entry form. The first field collects the common name (CN) of the user whose password is to be changed, as callout A in Listing 1 shows. The CN is an attribute associated with all objects in AD. All CNs are unique, and searches use them to find an object in the directory. When the script finds the CN, the script binds to the object and uses it for additional operations such as Get (which displays properties associated with the object) or Put (which updates properties associated with the object). After you specify the CN, you enter the new password, then verify the new password. Finally, the administrator submits the form, and the ASP code verifies that the password and the password confirmation match. Assuming the two passwords match, the code at callout B invokes the IADs interface's SetPassword method with the CN and new password as properties. The method then processes the request and changes the user's password to the password the user specified.

The ASP code that processes an AD attribute change is similar to the ASP code that performs the user-password change because that code uses the same IADs interface. PutScript.asp, which Listing 2 shows, first creates a connection to the user object in AD whose attribute the code will update. Next, the code at callout A puts the update into a local Lightweight Directory Access Protocol (LDAP) cache by calling the IADs interface's Put method and specifying the attribute you want to update with the attribute's new value. Finally, the code at callout B uses the SetInfo method to flush the local LDAP cache and commit the changes to AD, thus completing the transaction.

When you initially bind to an object in AD, a property cache address space is initialized in memory for that object. All IADs methods then use that property cache for the calls they make until the script calls the SetInfo method. The cache saves a significant amount of network bandwidth by eliminating the need to go to AD for every read or write action. When the script calls the SetInfo method, the script empties the property cache and transmits the modified properties across the network to AD as one transaction. PutScript.asp doesn't commit the change to the directory until it calls the SetInfo method. Unlike the SetPassword method, which performs a set as an inherent part of the method, if the script doesn't call the SetInfo method, the modified data won't move from the local cache to the directory.

The attribute that I used to test PutScript.asp is wwwHomePage, which is a standard user attribute that the User class inherits by default. This attribute is an AD property available with an out-of-the-box installation of Win2K. However, the script works for most attributes that are available to a user, including custom attributes that you add to AD through an extension to the User class of the AD Schema (provided that the user attempting to make changes to the custom attribute has the appropriate security permissions for that object). In addition, you must specify the correct AD container in the LDAP path and correctly type-cast (i.e., define what type of object will be returned to a variable as the result of performing the programmatic function) the variable pertaining to the modifiable attribute's value.

Controlling Your AD
By facilitating Web-based management, you gain greater control over AD and the attributes stored in it. In addition, you have the option to create custom management interfaces for other applications that can take advantage of AD. As time goes on, more applications will take advantage of this kind of technology, and their management interfaces will be available in a more flexible fashion than the Win32 interface. Web-based administration applications let you work from anywhere in the world from any number of IP-based devices, whether wired or wireless.

Note: The AD schema extensions are necessary for managing any customized (i.e., non-Win2K default) data through AD. If you aren't interested in managing custom attributes, the AD schema extensions might not be necessary.

Related Reading
You can obtain the following articles from Windows 2000 Magazine's Web site at

"Importing and Exporting AD Information," November 21, 2000, InstantDoc ID 16170
"Extending AD Schema," May 9, 2000, InstantDoc ID 8738

You can obtain the following article from IIS Administrator's Web site at
"Extending the User Class in the AD Schema," September 2000, InstantDoc ID 9738
Hide comments


  • Allowed HTML tags: <em> <strong> <blockquote> <br> <p>

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.