Accessing AD Through IIS

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.

   Previous  [1]  2  Next