The only applied guide for LDAP development in Active Directory and NDS environments.
Lightweight Directory Access Protocol (LDAP) is an open, vendor-neutral standard for accessing directory information. Using LDAP, developers can transform directories built in Active Directory and Novell Directory Services (NDS) into extendable, multiplatform, Internet-enabled solutions. In this book, Bruce Greenblattone of the world's leading directory expertsshows exactly how to develop custom LDAP solutions in both Active Directory and NDS environments. With examples in Java, and with the near-universal access afforded by LDAP, this book provides the tools you need to make your distributed applications more widely available than ever before.
Greenblatt begins with a discussion of LDAP and how it fits in with Internet standards, then explains LDAP schema design and security concepts. After detailed coverage of LDAP implementations in Active Directory and NDS, and an overview of how to use LDAP with Java, Greenblatt gives a first-hand look at Internet directories in action and walks through three complete application case studies-storage management, e-commerce, and a Web-based chat room. He then demonstrates how to access LDAP-enabled applications using Java servlets, Java applets, and Active Server Pages. Finally, you'll learn about LDAP's limitations (and how to work around them!) and also how to use XML with LDAP. Background information on Internet technologies, networking, and security is provided throughout. You'll learn how
This book is designed for Active Directory and NDS software developers, especially those involved with client-server or three-tier software development tools.
PART I.1. Introduction.
What Is Driving LDAP Application Development? Who Is the Target Audience of This Book? What Background Is Needed to Understand This Book? How to Obtain Documentation on the Internet. Organization of This Book.2. An Overview of LDAP and the Internet.
The Internet. The TLS Layer. The TCP Layer. The UDP Layer. Tying the Layers Together. Directories. LDAP. Data Storage. Protocol Usage. Distributed Operation. White Pages Service. Chapter Summary.3. LDAP Overview.
LDAP Namespace and Information Model. LDAP Functional Components. Command Details. Bind and Unbind Commands. Search Command. Making Changes (Add, Modify, and Delete Commands). Lesser Used Commands (Modify DN, Compare, and Abandon). Extended Commands and Controls. What APIs Are Available for Programming to LDAP? What Kind of LDAP Server Is Included with NDS and Active Directory?4. Principles of LDAP Schema Design.
Typical Problems with LDAP Schema Design. Relational Database Normalization. Data Redundancy. Retrieval of Unwanted Data. Delete and Update Anomalies. An Example. Summary.5. LDAP Security.
Network Security. Secret-Key Encryption. Public-Key Encryption. Message Digests, Digital Signatures, and Authentication. TLS. Access Control. Native NDS Access Control. Application-Defined Permissions. Authentication.
PART II.6. Using an Installation of Active Directory.
A Typical ADS Installation. ADS Replication.7. Using an Installation of Novell's NDS.
A Typical NDS Installation. NDS Replication.
PART III.8. Building LDAP Programs Using Java.
LDAP APIs for Java. The Netscape LDAP API for Java. Connecting to the LDAP Server. Searching the Directory. Adding Entries. Modifying Entries. Deleting Entries. Using Compare. Renaming Entries. Using Asynchronous Commands. Ending the Connection. Using LDAP in Java Applets. Using LDAP in Servlets.9. Example LDAP Applications.
Using LDAP to Store User Configuration Information. Using LDAP to Store Application-Defined Access Control Information. An LDAP-Enabled Mailing List Administration Application. Installing LDAP-Enabled Applications.10. Limitations of LDAP.
A Quick XML Overview. DSML.Index.
Many years ago (in 1983), I was taking a Computer Architecture course in graduate school. Most of the final grade in the course was derived from the semester-long project to design a computer. This project was to be done in three separate parts. Interestingly enough, when we were given the first part of the assignment, we didn't yet know exactly what the second or third parts of the assignment were. The first part of the assignment was to design the "exoarchitecture" of our computer, most of which involved creating the computer's assembly language. Once we had completed that stage, we were handed the second phase of the assignment, which was to design the "endoarchitecture" of our computer. This mostly involved designing the machine language of the computer. In addition, there were specific requirements added to part two that were not mentioned in part one. This was no big deal, except that part two built on part one and we were not allowed to change anything in the design of our exoarchitecture. As might be expected, quite a few students made many mistakes in their designs, which unfortunately had to be carried forward into the later stages of the project. So, of the original 75 or so students, about a third dropped the class after the first phase of the project.
For my part, I had made a choice in phase one to build an 8-bit computer so that the design of the assembly language and its implementation would be simpler. Unfortunately, there were several requirements in phase two that made this a seriously bad choice. Had I known of these requirements, I would have decided to build a 16-bit computer in phase one. This situation is unfortunately common in software development. Midway through the development of a project, new requirements come in and oftentimes seriously invalidate earlier assumptions. If the developers are lucky, they have time to go back and redesign the software system. The students in this class were not so lucky.
The third phase of the project completed the design of the computer. This part of the assignment involved designing much of the "microarchitecture" of the computer, which revolves around the microprogramming aspects of the hardware. Again, this assignment included some new requirements that made some of the students' earlier choices unfortunate. So, at the end of the three phases of the course project, I had assembled a seriously convoluted design for a computer. Many students had similar stories, and other students weren't around to complete the project. Only 22 of the original 75 students remained to the bitter end. Of these, only 11 received a passing grade (I was fortunate enough to be among that number).
While there were many books available that described existing computer architectures (most of them used the IBM 360 series mainframe as the principle example), very little material described the design process as a whole. Thus, unless we could have had access to Fred Brooks's1 diaries, we didn't really know what lay ahead of us. Even though the project was an interesting learning experience, it was very difficult to implement a top-notch computer design for this project. In many respects this is similar to the state of affairs of Lightweight Directory Access Protocol (LDAP) integrated application development today. There are several references available that define the basics of LDAP, but nothing is available that goes into any detail of design concepts that are unique to LDAP integrated application development. This book is intended to build on other references that explain the LDAP protocol and the functions of the LDAP Application Programming Interface (API).
LDAP has been available for several years as an add-on component to various server operating systems. Starting with Windows 2000 Server and NetWare 5.0, the LDAP server is built into the operating system. Windows 2000 Server includes the Active Directory. NetWare 5.0 includes the Novell Directory Service (NDS). So, application developers now have available a new piece of infrastructure technology which will always be available in the most popular network operating systems. Thus, there is no additional dependency for LDAP-enabled applications that are expected to run on a network, since virtually all local area networks in the future will use either Windows 2000 Server or NetWare 5.0.
The future utilization of LDAP in Internet applications is potentiallyif not inevitablyexplosive. The corporate networks built using Windows 2000 and NetWare 5.0 are now running the same Transport Control Protocol/Internet Protocol (TCP/IP) based networking protocols that are used on the Internet. This was not true in previous versions of these network operating systems. In the corporate network, LDAP Directories are responsible for making available information about network accessible resources, such as host machines, printers, users, and so forth.
An LDAP Directory provides a set of names and properties in such a way that Directory users can easily search them. Each name in the Directory and its associated properties are collected together as a Directory entry. LDAP Directories operate in client-server mode; LDAP clients submit service requests to Directory servers and Directory servers handle the requests and provide responses to the Directory clients. The core services provided by an LDAP server include property- or attribute-based information storage, manipulation, and retrieval. The most frequently utilized and hence most essential Directory service is property- or attribute-based information retrieval. Other services provided by a Directory server, such as data addition, deletion, and modification services, exist to support this primary service and are considered ancillary to the information retrieval service.
Throughout this book, the explanations of the various components of LDAP technology have been supplemented by making extensive use of examples. The examples of code are written exclusively using the Java programming language. Software developers desiring to create an application that is to be integrated with an LDAP Directory will find the treatment of technology, as well as the data organization in the examples, helpful in their efforts. I believe this to be the case even for developers whose principal programming language is not Java. Thus, the principal target audience for the book includes any application developer that wants to integrate his (or her) application with the network.
This book assumes the reader has a basic background in computer science. Nearly all computer professionals will find most of this book easy to understand. Computer programming experience will be very helpful in understanding Chapter 8, Building LDAP Programs Using Java, and Chapter 9, Example LDAP Applications. The reader does not need to have a deep understanding of computer networking. It is helpful to have experience in using Internet applications, such as a Web Browser.
This book provides basic tutorial information on several different Internet technologies, as well as LDAP itself. Background material in computer networking and security is provided at appropriate points, when this material is needed to provide a complete treatment of the LDAP technology being discussed. This background material is provided for readers with limited backgrounds in those areas.
LDAP is a specification of the Internet Engineering Task Force (IETF) and provides the specifications that define the protocols that are used in the Internet. The IETF notes on its Web site (located at
www.ietf.org), "The IETF is a large open international community of network designers, operators, vendors, and researchers concerned with the evolution of the Internet architecture and the smooth operation of the Internet." The IETF publishes its specifications in documents that are known as Requests for Comments (RFCs). RFCs document various aspects of computer communications mainly in the area of protocols that are to be used for the exchange of information between two (or more) Internet hosts. These protocols fall into three main categories:
An example of a Network Layer protocol is Internet Protocol (IP). Examples of Transport Layer protocols are Transport Control Protocol (TCP) and User Datagram Protocol (UDP). These layers will be summarized in the next chapter. Examples of Application Layer protocols are LDAP and SMTP.
RFCs are freely available from a number of sites around the world, including the IETF's own Web site mentioned above. The work of the IETF that has yet to be published as RFCs is available from these same sites in the form of Internet Drafts. Drafts are work-in-progress documents that are either being investigated by one of the many working groups of the IETF or are individual contributions.
An important difference between IETF and other standards-making bodies in terms of Internet documentation is that IETF documents are always free and, with only very rare exceptions, contain no patented or copyrighted information or ideas. Documentation from virtually every other standards body (e.g., ITU, ANSI, IEEE, ECMA) is prohibitively expensive to obtain. The IETF views this expense as a barrier to the implementation of standards and encourages implementations far and wide. As evidence of this strategy, RFC 2026 (the Internet Standards Process) defines the various types of RFCs and the stages in which they proceed. It defines the conditions that must exist before an RFC can proceed from the first level (Proposed Standard) to the first level on the IETF standards track (Draft Standard type RFC). "A specification from which at least two independent and interoperable implementations from different code bases have been developed, and for which sufficient successful operational experience has been obtained, may be elevated to the Draft Standard level." Other standard bodies typically introduce their standards prior to any implementation experience.
This book contains eleven chapters organized into three parts, arranged as follows: