Accessing AD Through IIS

Using ASP and Kerberos authentication to administer AD from the Web

Securely administering Active Directory (AD) from anywhere in the world sounds like a great idea. However, Microsoft doesn't have the tools, and third-party tools that permit such an option aren't currently available. Fortunately, Windows 2000 makes remote server administration possible, provided you have an Internet-accessible Web server running Win2K and IIS 5.0 and access to Microsoft Internet Explorer (IE) 4.0 or later.

In this two-part series, I explain how to create a Web-based application to search and modify AD. This month, I introduce you to the search function; next month, I'll show you how to modify the data that the search returns.

The Problem: Remote Network Administration
Let's take, for example, a multinational corporation that has its parent company in Sydney and servers around the world. The corporation has operations centers in New Delhi, Singapore, and Los Angeles. At 4:00 p.m. on a Monday in Sydney, the company's two primary network administrators are meeting to discuss how the company is going to merge its network operations with its parent company. One network administrator is checking his email and notices that a new employee, who is to be a Web server administrator, is starting on Monday in Los Angeles, and somehow the new-user request slipped through the cracks. The two network administrators with the power to create the new administrator-level account are now in Australia, and they have no direct connectivity back to the operations center.

This situation poses a problem because the network security team allows administrative-level connectivity only through a console connection or by way of the corporate dial-up solution. However, burdening the slow 56Kbps connection from Sydney to Los Angeles with a Win2K Server Terminal Services or equivalent session is a dismal administrators have implemented a Web-based solution that works at the speed of the Internet from any connection that has an IE 4.0 or later browser. This solution gives them complete administrative abilities over all the company's users without using the dial-up connection. In addition, this solution saves the network administrators a lot of time and frustration and saves the company the added expense of the dial-up connection.

In a similar scenario, the network administrators have extended the AD Schema to support some custom applications' specific attributes. Under these circumstances, user administration is an extremely time-consuming task, and performing such a task from halfway across the world seems like a crazy idea. Perhaps for this reason, many companies haven't yet begun to use AD to its full potential. Currently, developers can use C++ to write Microsoft Management Console (MMC) extensions for administering custom attributes, but the interfaces available are still somewhat limiting and difficult to interpret and use. If, however, administrators could easily write custom administrative tools, then perhaps manipulating the AD Schema would be a more common practice. The examples I give provide you with the knowledge necessary to write Web-enabled custom tools quickly and easily.

Server Administration Through IE
You can enable server administration through IE in one of two ways. The first option uses Active Server Pages (ASP) files, which let you connect directly to the Directory Service (DS) to perform operations. The second option is to write ASP files that communicate with a middle-tier DLL (written in either C++ or Microsoft Visual Basic—VB), which in turn acts as an intermediary for communications to the DS. I describe the first option. By using ASP files on a properly configured IIS Web server to communicate directly to the DS, you can be assured that the user making the request is the user performing the requested action. If you use a DLL to access the DS, a malicious user could configure that DLL through options in the COM+ application's Component Services to impersonate another user on the network. Although the option to run the DLL as a specific user might be useful in some environments (e.g., if a component were meant to run on a server as a service or that service needed to run as a specific user, such as to gain special rights or privileges on the system—note that this practice isn't recommended), doing so represents a definite security risk, depending on the functions you let the DLL perform on the DS.

The basic premise for the Web administration concept is centralized around the use of Kerberos for user authentication and subsequent server-to-server communications. Kerberos, which Microsoft has adopted as a Win2K standard, allows for authentication from both a client-server environment and the Internet. Kerberos uses authentication tickets, which let users move freely between trusted servers and workstations within a given domain. Using Kerberos in a Win2K environment requires that a Key Distribution Center (KDC) be available to grant users session tickets that they can use to access other workstations, servers, or services. In Win2K, if Kerberos is available, the OS will use it by default over NT LAN Manager (NTLM). If Kerberos is unavailable, all communications will attempt to fall back onto NTLM and finally to Basic authentication until the OS finds an available authentication type. If no authentication type is present, the request for service will fail. If Anonymous access is an available option, the OS will always use it before any form of authenticated communication.

In IIS, the authentication features that Kerberos grants to the user are especially unique, because if you've correctly installed and configured Kerberos, end users can take advantage of many features that they might otherwise access only from their desktop in the client-server environment or by means of a Terminal Services or similar session. Take, for example, access to AD. Most corporate firewall administrators don't allow open access to AD Services on port 389; however, most administrators allow Web traffic on port 80. So, if you configure your IIS Web server to act as a middle-tier architecture component between the client's Web browser and AD Services, you could write scripts to let you administer your company's AD Services or other directory-enabled services from anywhere in the world.

This capability reduces the time necessary to perform administrative functions; it also lets you feel confident in extending the AD Schema because you can build a custom administrative interface by which you can administer new attributes. Even allowing administration of applications such as Microsoft Exchange 2000 Server would be possible because Exchange Server extends the AD Schema and integrates directly into AD. You can imagine how much easier it would be to manage a user in multiple applications from one location.

To allow Web-administration scripts, you need an IIS Web server, Win2K Advanced Server with AD configured, a KDC, and a client host running IE 4.0 or later. When the client connects to the Web server, the system issues a Kerberos session ticket to that client. As the client calls the scripts, the Web server requests a Kerberos session ticket from the Win2K AS machine for the client. The Win2K AS machine issues the client a session ticket, which lets the user perform functions based on the rights that user has in the domain. If the user is an administrator and can add new information or make changes to information stored in the directory, those rights will be present through the Web client, provided the script has the ability to take advantage of those rights. Likewise, if the user has only Read access to the directory (which is usually the case with domain users), the user can't make changes through the scripts. To take this concept one step further, if you usually administer multiple domains, you can allow this functionality.

Server Configuration
The Web server's configuration is an important component of the overall function of the Web-administration concept. Therefore, you must make sure that the configuration is correct. These steps explain how to accurately configure the server to make the Web-administration scripts function properly:

After you've successfully configured the Web server, you can install the scripts in the new virtual directory you created. The script that Listing 1 shows—ADLookup.asp—lets the client return information about a user from AD. The script works by first prompting the user to enter a common name (CN) on which to search, as Figure 4 shows. Next, the script initializes a resultset and uses the Microsoft Active Directory Service Interfaces (ADSI) provider, which uses the ADSI syntax (as opposed to the default MSDASQL provider, which uses Microsoft SQL Server syntax), to make an ADO connection to AD as callout A in Listing 1 shows. Then, the script queries AD for all the requested information relating to that CN and holds the results as an ADO recordset. Finally, the script parses the resulting recordset and returns the associated information about the target record to the browser in the form of an HTML table, as Figure 5 shows.

The Future of Web-Based Administration
As you see in the example I provide, you can use ASP, VB, or any COM-compliant language that has ADSI support to write effective management utilities for AD or DS-enabled applications. By introducing such management tools and techniques, you can perform maintenance from anywhere in the world, even from a Windows CE­powered PocketPC, provided it has Internet access.

In the future, you will be able to use similar techniques to administer all types of applications and network components. By using tools of this type, you're no longer limited to the AD functionality available through the limited set of MMC and Windows Script Host (WSH) tools that Microsoft provides. You can quickly and easily create your own management utilities for Win2K and take advantage of the full AD Schema.

Also, note that such administrative tools aren't limited to AD. You could just as easily write tools for any Lightweight Directory Access Protocol version 3 (LDAPv3)­compliant DS, such as Netscape's Directory Service or Novell's Directory Service. As wireless options improve and become more popular, you could expand on these interactive applications and make them available to a multitude of clients, including cellular telephones. Next month, I'll show you how to expand on the information I've provided and make changes to information resulting from a query.

Note: The DC must trust the Web server for delegation. By trusting the Web server for delegation, you're letting the Web server request a Kerberos ticket from the DC for the client, based on the client's authentication credentials.