The ABCs of LDAP

How to Install, Run, and Administer LDAP Services

Reinhard E. Voglmaier

• Publisher: Auerbach Publications
• Year: 2003
• ISBN:
  9781135511579
• Edition: 1
• Topic: Computer Science
• Subtopic: Information Technology
• Index: Computer Science

This book explores the use of Lightweight Directory Access Protocol (LDAP) as an efficient protocol. It combines all of the relevant information available on the Internet along with a number of arguments treated in the various books that are available, and provides many examples of LDAP code.

Chapter 1

The LDAP Protocol

This chapter has two goals. The first goal is to introduce the basic concepts of the Lightweight Directory Access Protocol (LDAP). To do this, we will have to answer four questions:

1. What is a directory?

2. What is a protocol?

3. What is a Directory Access Protocol (DAP)?

4. Why is LDAP called a “lightweight” Directory Access Protocol?

The second goal of this first chapter is to introduce some of the terminology you will need to know to work with LDAP. This is important because these terms are used repeatedly throughout this book, and they are part of the everyday vocabulary for someone working in LDAP production. After reading this chapter, you will have a basic understanding of what a Directory Access Protocol is and what it is used for.

The remaining chapters should help you in exploring the details and enable you to begin working with LDAP. After finishing this book you will understand the basics of LDAP and be ready to explore the subject further on your own. Further research will be necessary because LDAP is a work in progress, and at the time of this writing, some aspects of the protocol have not yet been clearly defined. One of these points is replication between directories. We will hear more about replication in Chapter 5, which explains the use of distributed directories. For now, it is enough to know that LDAP is not yet a fully defined protocol. Other aspects of the protocol are still in development, and yet others are not even at the planning stage. For example, the question of transaction management is still open. A transaction is a number of actions that, together, build a single atomic operation. (“Atomic” means that a number of physical operations can be logically considered as one single operation. Or that all single physical operations are completed or none at all.) Transaction management guarantees that the system executes all these steps together or does nothing at all (more about this at the end of this chapter). A banking application example makes this clear. The transfer of money from account A to account B consists of subtracting an amount from account A and adding the same amount to account B. This should be an atomic operation. If one of these actions fails, the other one should not be performed. At the moment, the issue of transaction management is not even on the table, although there are user requirements. A future version of LDAP will likely include transaction management. The Lightweight Directory Access Protocol is a very interesting and dynamic topic, so you will have to stay tuned to keep up with the latest developments.

In this chapter, we first look at what LDAP can do for you. This section introduces the concepts of a “directory” and a “directory server,” and it explains the function of each.

In the next section, we begin to develop a more technical understanding of LDAP, which involves a discussion of protocols. We learn what a protocol is and are introduced to protocols relevant to LDAP. As we will see, these protocols and, most importantly, LDAP itself are protocols in the networking environment. We learn how the concepts of networking and internetworking have evolved over time and how LDAP fits into this picture. We then encounter the TCP/IP (Transmission Control Protocol/Internet Protocol) and OSI (Open Systems Interconnection) protocol stacks, which are the foundation for all modern network implementations. The most commonly used directory access protocols are laid on top of one of these two protocol stacks, depending on the operating system. After reading this section, you will understand how a protocol stack works, where a Directory Access Protocol is located, and how the network protocols interact with the DAP. If you are not very interested in these concepts, you can skip this section about protocols entirely and continue at the point where we discuss the LDAP protocol. These protocols are presented here only as background to help you better understand the networking aspects of the LDAP protocol.

Another concept closely linked to LDAP is the “request for comments” (RFC). RFCs are used as a tool for proposing, discussing, and defining standards in the Internet community. Many readers may never have to deal with documents defining the LDAP standards, and they can safely ignore the RFCs and still work with LDAP. However, a basic knowledge of RFCs is useful for those readers who need to dig more deeply into the details than this book will do.

After this, we finally address the main topic of this book: the Directory Access Protocol. First we look at X.500, also called DAP, which was developed together with the OSI protocol stack. The lightweight counterpart of DAP (LDAP) is a subset of DAP that was developed for use with TCP/IP. Again, it is helpful to understand the basics of OSI and TCP/IP because the concepts of DAP and LDAP are tightly connected to these two protocols. You will see that DAP requires the OSI protocol and that the lightweight version of DAP (LDAP) runs happily atop TCP/IP. The fact that a given protocol stack is required to run DAP or LDAP has a number of implications. A discussion of these will help you understand the need for the lightweight version of DAP.

In the next section we learn what kind of data travels over the network and see what a typical LDAP conversation between client and server looks like.

In the final section, we learn where the data is kept. Up to this point, the discussion has focused on protocols, i.e., how the communication between client and server occurs. Using the LDAP protocol, clients ask a server to perform certain actions. As you will see, the LDAP server performs its actions on data – data maintenance, data administration, and data delivery to the clients. This data clearly has to be stored somewhere, and this “somewhere” is a repository or database. At this point, you might wonder whether it might be better to use a database instead of implementing yet another new technology. The chapter concludes with a brief discussion about the differences between a relational database management system (RDBMS) and a directory accessed via the LDAP protocol.

Directories and Directory Server

Everyone working in information technology (IT) knows what a directory is, and even people who only occasionally use a computer encounter a directory sooner or later. To be more precise, they do not encounter a directory, but what they see is a directory listing similar to that shown in Exhibit 1. Note that the exact layout of a directory listing depends on the computer’s operating system and the type of view configured for the directory listing.

Exhibit 1 shows a listing of a directory. This kind of directory may be helpful as a first approach, but in the context of our particular needs, this view is somewhat specialized and we would like to have a broader view. For our purpose, it is more instructive to use the definition of “directory” as we find it in a general dictionary, i.e., one that is not specialized on information technologies. For example, the Oxford Dictionary defines a directory as a “book containing a list of telephone subscribers, inhabitants of a district, members of a profession.” This gives exactly the concept of directory that we will use throughout this book.

Exhibit 1. A Typical Directory Listing

For our purposes, a directory is an ordered list of objects. For example, the “white pages” of a telephone book is an ordered list of persons arranged in alphabetic order by surname and given name or initials. Using the white pages, one can find the phone number, street, and district of anyone listed in the book. In contrast, the “yellow pages” provides an ordered list of professions where one can look up, for example, a nearby barbershop. A further example from an IT environment might be a list of printers ordered by printer name. Using this directory, one could find the printer’s location, the printer model, or the server to which the printer is attached. You could also search for a postscript-enabled printer near your office or base a search on some other criterion. Even whole network information systems can be stored in a directory.

As an ordered list of objects, a directory is an information storehouse that can be searched swiftly and easily. There are many potential applications for directories. Consider a domain name system (DNS) that correlates the human-friendly name of a computer (e.g., Google.com) with that computer’s Internet Protocol (IP) number. NIS+ allows us to get information about users and groups. NIS+ is an improvement over NIS, the Network Information Service invented by Sun Microsystems. It allows the central administration of hostnames, users, and user home directories. If you want to find out more about NIS/NIS+, go on to Sun’s Website. Gerald Carter dedicates a chapter of his book, LDAP System Administration,¹ to replacing NIS/NIS+ with LDAP. Both of these applications can be implemented as a directory, allowing the user to query the directory for information. The last two examples point out a further strength of LDAP. LDAP offers centralized information services across a whole network. Because LDAP is running over TCP/IP, all computers using the TCP/IP protocol can access the services offered by LDAP.

Exhibit 2 illustrates the hierachical structure of a directory where information is stored in a treelike structure that uses the DNS name space. As you can see, a hierarchical structure can accelerate searches by limiting the scope of the search to a branch of the tree. A further example of how to organize a hierarchy of different levels is shown by the number of names stored in the white pages. You can put the address where the person lives at the base level. The next higher level would be the district where that person lives. If you know the district, this knowledge will accelerate the performance of the query. The district furthermore is located in a city, the city in the country, and the country in a continent. The underlying hierarchy accelerates the search process, since you don't search for John Smith in the whole world, but you will first limit the search to Europe, then to the United Kingdom, then to London, and at the end to Bayswater. This hierarchical structure speeds the search process while keeping the results set low. You will find many more people named “John Smith” in the United Kingdom than in the district Bayswater. A smaller results set reduces network traffic and requires less work to elaborate the results.

The hierarchical structure depicted in Exhibit 2 also suggests the possibility of storing other attributes about the computer beyond its name and the IP number. For example, we might also want to record the disk space available, the memory available, the installed software, and similar relevant information. The directory stores all of this information in an object called an “entry.” Thus the directory is an object-oriented repository. Note, however, that the LDAP standard does not specify how the information is stored in the repository. We will return to this subject later in this chapter. Note also that directories are stored on hard disks on computers. The precise method of storage is discussed at the end of this chapter. For now, we will simply assume that information is held “somewhere.”

Exhibit 2. Hierarchical Structure of DNS

Imagine several people trying to look up the information stored ...

Table of contents

• Cover
• Half Title
• Title Page
• Copyright Page
• Table of Contents
• 1 The LDAP Protocol
• 2 LDAP Basics
• 3 LDAP Models
• 4 LDAP: Some Practical Details
• 5 Distributed Architectures
• 6 LDAP APIs
• 7 LDAP Directory-Server Administration
• 8 LDAP and Web Services
• 9 The Design of Directory Services
• Appendix A Acronyms
• Appendix B LDAP Requests for Comments and Drafts
• Appendix C Useful Links
• Appendix D Standards
• Appendix E Configuration of OpenLDAP
• Appendix F Playing with Replication in OpenLDAP
• Appendix G Playing with OpenLDAP Proxy Server
• Index