A Brief History of Directories | MicrosoftR WindowsR 2000 Active DirectoryT Programming

It's easy to see that network directories have enormous benefits for users, information technology professionals, and developers. How those benefits came about, particularly how Active Directory evolved, is rooted in the history of network directories, specifically in the development and evolution of DNS, X.500, and LDAP, three early directory services. Figure 1-3 shows a timeline of some of the significant events in directory history.

Figure 1-3 A history of directories.

Domain Name System

One of the first major electronic directories, the Domain Name System (DNS) matches domain names on the Internet with their corresponding hard-to-remember Internet Protocol (IP) addresses. Just as people have telephone numbers, computers on a TCP/IP network have IP addresses. In order for a computer to communicate with another computer on the network, it must know the other computer's IP address. The information that DNS uses is created locally and distributed globally. I can add a new computer to my network, give it the name copper1, and tell my DNS server the new computer name and IP address.

Since there are hundreds of thousands of computers on the Internet, it would be wasteful to replicate all the information to all the DNS servers. Instead, when a DNS server doesn't understand a name given to it, it refers the request to another DNS server up the chain. Eventually, the system finds the server that is responsible for the coppersoftware.com domain, asks it to look up copper1, and returns the IP address. Because DNS is incredibly robust, any computer connected to the Internet can communicate with copper1 by specifying the name copper1.coppersoftware.com, the complete domain name for my network. DNS is a good example of a purpose-specific directory. Not surprisingly, Microsoft implements its version of DNS within Active Directory.

If you are setting up an Active Directory–enabled network yourself, a thorough knowledge of how DNS and Active Directory work together is useful and will help avoid common problems. Please refer to the Windows 2000 Server Resource Kit and to Active Directory Services for Microsoft Windows 2000 Technical Reference by David Iseminger, both published by Microsoft Press. In addition, for common Active Directory/DNS setup issues, refer to the Microsoft Support documents at http://support.microsoft.com/support/win2000/dns.asp.

X.500 Directory Service

The proliferation of networked applications gave rise to a need for standardized directories that implemented common programming interfaces so that multiple applications could access the same information. This era began in the mid-1980s with several large business and academic organizations searching for a common directory solution. In 1988, the International Telecommunications Union published the X.500 directory service recommendation and defined the Directory Access Protocol (DAP). This standard was the culmination of efforts by International Telephone and Telegraph Consultative Committee (CCITT, now known as ITU-T) and the International Standards Organization (ISO) to produce a global directory service standard. The X.500 standard was updated in 1993 and again in 1997.

Developed from the outset to be an all-encompassing, global directory service, X.500 and DAP were considered difficult to implement and did not receive broad commercial acceptance. Another limiting factor was the fact that X.500 depends on the Open Systems Interconnect (OSI) network protocols instead of the (now) prevalent Internet model, based on TCP/IP. Although X.500 was unique in bringing a true distributed nature and a rich searching functionality to directories, those advantages came at the expense of requiring a large amount of computing resources.

When software vendors looked at X.500, they realized that the complexity of the interface was daunting, and they didn't see the potential rewards of this powerful and open standard. Vendors didn't grasp the importance of a global directory service, and proprietary directories simply evolved along with the software they were used in. Figure 1-4 shows the components of an X.500 system.

Figure 1-4 X.500 components.

Legacy Free

Working against X.500 was a widespread trend in the development of personal computing applications: build on previous technologies, make incremental technology enhancements, and preserve the customer's current investment. Whereas Windows evolved from MS-DOS, which evolved from CP/M, the X.500 standard was essentially a clean slate, requiring imple-menters to create a huge amount of new code. When new technologies de-part significantly from those used by the majority of the installed base, they suffer slow adoption rates, regardless of their benefits. The first release of Windows NT in 1993 was poorly received, despite a major push by Microsoft to get software developers to adopt its 32-bit programming interface, a moderate jump from the 16-bit Windows API that developers were accustomed to. Microsoft, throughout its history, has learned the importance of gradually moving its installed base and software developers to new technology. Active Directory is no exception, building on technology in Windows NT and products such as Exchange Server and Microsoft Site Server.

The Advent of LDAP

Early versions of collaborative applications such as Microsoft Mail and Lotus Notes used directories, but these were proprietary in the sense that only in certain cases was interoperability with other clients available. Flexibility, security, and replication were minimal or nonexistent. Network operating systems such as Banyan VINES, Microsoft Windows NT, and Novell NetWare started implementing forms of directories to manage users and network resources. NetWare had the Bindery, and Windows NT had the Security Account Manager (SAM) database. Banyan led the way with an integrated directory service called StreetTalk, which was innovative but never achieved widespread commercial success. Each directory stored information about network users and resources, but each was geared toward security and authentication, the primary needs of the network operating system at the time.

By 1993, with the second revision of X.500 generating little commercial interest, a group of researchers at the University of Michigan (an early X.500 adoption site) were developing an alternative to the complex DAP interface in X.500. The goal was to create a simpler access protocol for X.500 directories. The group created a protocol that removed many of the X.500 elements that had blocked adoption by developers, notably the OSI network model, and that eliminated many of the unused functions of DAP. This lean and mean version of DAP started out as DIXIE (RFC 1249) and became known as Lightweight Directory Access Protocol (LDAP). Even though this first version of LDAP was a great improvement over the complex X.500 DAP, it took some time for vendors to embrace it. Not until LDAPv2 was published (in proposed form in RFC 1487 and as a standard in RFC 1777) did LDAP and open directory services really take off.

The formal definition for LDAP is contained in documents known as Requests For Comments, or RFCs for short. RFCs have developed into a way of standardizing a technology to be used on the Internet. Many technologies and specifications, from DNS to how e-mail is passed around, are defined by RFC documents. The Internet Engineering Task Force (http://www.ietf.org) reviews and maintains RFC documents. A list of RFCs related to LDAP is included in Chapter 3.

At first, LDAP was simply an alternative to X.500's DAP. However, because LDAP defined the protocol, developers were free to do their own implementations of a directory service that merely complied with the requirements of LDAP and did not require X.500. The first such implementation was, unsurprisingly, at the University of Michigan, where SLAPD (stand-alone LDAP daemon) and its replication partner, SLURPD (stand-alone LDAP update replication daemon), were developed in 1995. SLAPD was a simple LDAP server that could communicate with several different databases serving as directories. SLURPD was the program that replicated the changes in the directory database to other computers acting as directory servers.

Also important to the success of LDAP was the development of the LDAP Application Programming Interface (or API) for the C language. Defined in RFC 1823, this API includes a set of functions that developers can use to access directory services. Windows NT and Windows 2000 support this API as part of the operating system to allow applications running on those platforms to access LDAP-based directories.

Parts of LDAP have been improved over the years, with a major effort directed at providing extensibility. The latest version, originally published in 1997 as RFC 2251, is known as LDAPv3. This version is a superset of LDAPv2 and includes new features such as extended controls and the ability to expose the directory data definition or schema. A major feature of LDAPv3 is the ability for LDAP directories to expose information about the services provided. Many vendors supporting LDAP do so at the v2 level, with some mixing in features from LDAPv3. Active Directory supports LDAPv2 and LDAPv3 with some custom extensions, known as controls.

It's interesting that X.400, the ITU standard for network messaging, shared a similar fate as X.500. While LDAP largely supplanted X.500, the Simple Mail Transfer Protocol (SMTP) became the de facto standard for e-mail on the Internet.