About the Technical Reviewers

Understanding and Deploying LDAP Directory Services > 3. An Introduction to LDAP > What Is LDAP?

<  BACK CONTINUE  >
153021169001182127177100019128036004029190136140232051053055078209011141238121153014244

What Is LDAP?

At its core , LDAP is a standard, extensible directory access protocol ”a common language that LDAP clients and servers use to communicate with each other. Standardization of the protocol has the benefit that client and server software from different vendors can interoperate . When you buy an LDAP-enabled program, you can expect that it will work with any standards- compatible LDAP server. This has many advantages, but we'll discuss those later in this chapter.

LDAP is a "lightweight" protocol, which means that it is efficient, straight- forward, and easy to implement, while still being highly functional. Contrast this with a "heavyweight" protocol, such as the X.500 Directory Access Protocol (DAP). X.500 DAP uses complex encoding methods and requires use of the OSI network protocol stack ”a networking system that has failed to gain wide acceptance.

LDAP, on the other hand, uses a simplified set of encoding methods and runs directly on top of TCP/IP. Every major desktop and server computing platform currently available (Microsoft Windows, DOS, UNIX, and the Apple Macintosh) either ships with a TCP/IP implementation or can be easily equipped with one. OSI networking, on the other hand, is not universally available, and it is almost always an extra-cost option. LDAP, by virtue of its light weight, removes significant barriers to implementation and deployment.

As mentioned in Chapter 2, there have been two major revisions of the LDAP protocol. The first widely available version was LDAP version 2, defined in RFCs 1777 and 1778. As of this writing, LDAP version 3 is a Proposed Internet Standard, defined in RFCs 2251 through 2256. Because it is so new, not all vendors completely support LDAPv3 yet. As we discuss LDAP in this chapter, we will focus our discussion on LDAPv3. However, we will point out new features found only in LDAPv3 so that you can understand the limitations you will encounter if you are using LDAPv2.

In addition to its role as a network protocol, the LDAP standards also define four models that guide you in your use of the directory. These models promote interoperability between directory installations while still allowing you the flexibility to tailor the directory to your specific needs. The models borrow concepts from X.500, but they generally lack many of the restrictions that the X.500 models include. The four LDAP models are as follows :

  • The LDAP information model, which defines the kind of data you can put into the directory.

  • The LDAP naming model, which defines how you organize and refer to your directory data.

  • The LDAP functional model, which defines how you access and update the information in your directory.

  • The LDAP security model, which defines how information in the directory can be protected from unauthorized access.

In addition to guiding you in the use of your directory, the LDAP models guide directory developers when designing and implementing LDAP server and client software. The LDAP models are discussed in detail later in the chapter.

There are several LDAP APIs, the oldest of which is for the C programming language. The C API is supported by several freely available software development kits (SDKs), including one available in binary and source code format from Netscape Communications Corporation. In addition to the C API, Netscape's freely available Java SDK (also available in binary and source code formats) supports all LDAPv3 features. Netscape also provides PerLDAP, a toolkit for the Perl language that allows you to access LDAP directories.

SunSoft's JNDI is a proprietary, unified directory access API that supports access to multiple types of directory services (NIS+, LDAP, and others). Microsoft offers its own proprietary unified directory access API, known as Active Directory Services Interface (ADSI). These APIs and their various strengths are covered later in this chapter and in Chapter 20, "Developing New Applications."

LDAP also defines the LDAP Data Interchange Format (LDIF), a common, text-based format for describing directory information. LDIF can describe a set of directory entries or a set of updates to be applied to a directory. Directory data can also be exported from one directory and into another using LDIF. Most of the commonly available command-line utilities also read and write LDIF. The LDIF format is discussed in more detail later in this chapter.

What Can LDAP Do for You?

If you are a system administrator, then LDAP

  • Makes it possible for you to centrally manage users, groups, devices, and other data.

  • Helps you do away with the headache of managing separate application-specific directories (such as LAN-based electronic mail software).

If you are a IT decision maker, then LDAP

  • Allows you to avoid tying yourself exclusively to a single vendor and/or operating system platform.

  • Helps you decrease the total cost of ownership by reducing the number of distinct directories your staff needs to manage.

If you are a software developer, then LDAP

  • Allows you to avoid tying your software exclusively to a single vendor and/or operating system platform.

  • Helps you save development time by avoiding the need to construct your own user and group management database.

For example, before the advent of LDAP, each of your applications probably had its own directory of user information. If you had a LAN-based email package, there was probably an interface you used to create and manage users and groups. If you had a LAN-based collaboration package from a different vendor, it most likely had its own directory and method of accessing that directory. And, often, if you used LAN-based file server software, it probably had its own distinct user directory.

Some vendors offered packaged solutions, which made it possible to manage users and groups in one place ”as long as you used only their software suite. However, if you needed to mix and match software from multiple vendors, you probably ended up developing an elaborate procedure for ensuring that new employees were added to each package's proprietary directory.

With LDAP comes the promise of eliminating this management nightmare. Instead of creating an account for each user in each system he or she needs to access, you will be able to simply create a single directory entry for the user ”and all directory-enabled applications will simply refer to the user's entry in the LDAP directory. When an employee is terminated , access to all systems can be revoked by removing the user's directory entry instead of hunting down all accounts granted to the person and disabling each one. Users benefit as well because they need to remember and manage only a single password instead of one for each system.

In addition to consolidating the management of your users' access privileges, LDAP directories allow easier sharing of directory information with trading partners in an extranet environment. If you have established business relationships with other companies, you can use the directory to share common user information between your two organizations. This allows you to set up workflow processes that cross company boundaries, making both organizations more efficient.

LDAP directories also can be used to build entirely new applications. An Internet service provider, for example, might create an LDAP directory that contains information about all its subscribers and the special add-on services it may have purchased. The directory can be consulted each time the user wants to access a given service. If the user has appropriate permissions, as registered in the directory, the application grants the user access; otherwise , access is denied . Management of all the value-added services is handled by updating the directory.

Not all software vendors have made the transition to LDAP-based management, but LDAP has tremendous momentum in the software industry. Over time, more and more applications will be directory-enabled with the net benefit of reducing the total cost of ownership of your applications.

How Does LDAP Work?

In this section, we'll delve into the LDAP protocol in detail. We'll start with an overview of LDAP as a client/server protocol. We'll then discuss the individual LDAP protocol operations and show how clients can use them to perform useful tasks such as sending secure email. We'll also discuss LDAP extensibility, and we'll conclude by showing you how LDAP works "on the wire" by discussing the actual wire protocol.

A client/server protocol is a protocol model in which a client program running on one computer constructs a request and sends it over the network to a computer (possibly the same computer) running a server program. The server program receives the request, takes some action, and returns a result to the client program. Examples of other client/server protocols are Hypertext Transfer Protocol (HTTP), which is typically used to serve Web pages; and Internet Message Access Protocol (IMAP) , a protocol used to access electronic mail messages.

The basic idea behind a client/server protocol is that it allows work to be assigned to computers that are optimized for the task at hand. For example, a typical LDAP server computer will probably have a lot of RAM that it uses for caching the directory contents for fast performance. It will also probably have very fast disks and a fast processor, but it probably doesn't need a large-screen monitor and expensive graphics support. A client computer, on the other hand, might be on an employee's desk, probably optimized for the type of work that the employee does. Rather than putting a copy of the corporate directory on every employee's workstation, it's a better idea to maintain the directory centrally on a server (or replicated set of servers).

The LDAP protocol is a message-oriented protocol. The client constructs an LDAP message containing a request and sends it to the server. The server processes the request and sends the result or results back to the client as a series of LDAP messages.

For example, when an LDAP client searches the directory for a specific entry, it constructs an LDAP search request message and sends it to the server. The server retrieves the entry from its database and sends it to the client in an LDAP message. It also returns a result code to the client in a separate LDAP message. This interaction is shown in Figure 3.1.

Figure 3.1 A client retrieves a single entry from the directory.

If the client searches the directory and multiple matching entries are found, the entries are sent to the client in a series of LDAP messages, one for each entry. The results are terminated with a result message, which contains an overall result for the search operation, as shown in Figure 3.2.

Figure 3.2 A client searches the directory, and multiple entries are returned.

Because the LDAP protocol is message-based, it also allows the client to issue multiple requests at once. Suppose, for example, a client might issue two search requests simultaneously . In LDAP, the client would generate a unique message ID for each request; returned results for specific request would be tagged with its message ID, allowing the client to sort out multiple responses to different requests arriving out of order or at the same time. In Figure 3.3, the client has issued two search requests simultaneously. The server processes both operations and returns the results to the client.

Figure 3.3 A client issues multiple LDAP search requests simultaneously.

Notice that in Figure 3.3 the server sends the final result code of message ID 2 to the client before it sends the final result code from message ID 1. This is perfectly acceptable and happens quite frequently. These details are typically hidden from the programmer by an LDAP SDK. Programmers writing an LDAP application don't need to be concerned with sorting out these results; the SDKs take care of this automatically.

Allowing multiple concurrent requests "in flight" allows LDAP to be more flexible and efficient than protocols that operate in a "lock-step" fashion (for example, HTTP). With a lock-step protocol, each client request must be answered by the server before another may be sent. For example, an HTTP client program ”such as a Web browser that wants to download multiple files concurrently ”must open one connection for each file. LDAP, on the other hand, can manage multiple operations on a single connection, reducing the maximum number of concurrent connections a server must be prepared to handle.

The LDAP Protocol Operations

LDAP has nine basic protocol operations, which can be divided into three categories:

  • Interrogation operations: search , compare.   These two operations allow you to ask questions of the directory.

  • Update operations: add, delete, modify, modify DN (rename).   These operations allow you to update information in the directory.

  • Authentication and control operations: bind, unbind, abandon.   The bind operation allows a client to identify itself to the directory by providing an identity and authentication credentials; the unbind operation allows the client to terminate a session; and the abandon operation allows a client to indicate that it is no longer interested in the results of an operation it had previously submitted.

We will discuss each of the individual protocol operations when we describe the LDAP functional model later in this chapter.

A typical complete LDAP client/server exchange might proceed as depicted in Figure 3.4.

Figure 3.4 A typical LDAP exchange.

In Figure 3.4, an LDAP client and server perform the following steps:

Step 1: The client opens a TCP connection to an LDAP server and submits a bind operation. This bind operation includes the name of the directory entry the client wants to authenticate as, along with the credentials to be used when authenticating. Credentials are often simple passwords, but they might also be digital certificates used to authenticate the client.

Step 2: After the directory has verified the bind credentials, it returns a success result to the client.

Step 3: The client issues a search request.

Steps 4 and 5: The server processes this request, which results in two matching entries.

Step 6: The server sends a result message.

Step 7: The client then issues an unbind request, which indicates to the server that the client wants to disconnect.

Step 8: The server obliges by closing the connection.

By combining a number of these simple LDAP operations, directory-enabled clients can perform complex tasks that are useful to their users. For example, as shown in Figure 3.5, an electronic mail client such as Netscape Communicator can look up mail recipients in a directory, helping a user address an email message. It can also use a digital certificate stored in the directory to digitally sign and encrypt an outgoing message. Behind the scenes, the user's email program performs a number of directory operations that allow the mail to be addressed, signed, and encrypted. But from the user's point of view, it is all taken care of automatically.

Figure 3.5 A directory-enabled application performing a complex task.

Although end-user applications can certainly be directory enabled, they are not the only kind of directory enabled applications. Server-based applications often benefit from being directory enabled, too. For example, the Netscape Messaging Server can use an LDAP directory when routing incoming electronic mail, as shown in Figure 3.6.

Figure 3.6 A directory-enabled server application.

These are just two examples of how directory-enabled applications can leverage the power of the directory to add functionality and ease of management. We will see more and more of this in the future.

In addition to providing the nine basic protocol operations, LDAP version 3 is designed to be extensible via three methods:

  • LDAP extended operations ”   A new protocol operation, like the nine basic LDAP operations discussed earlier. If in the future there is a need for a new operation, it can be defined and made standard without requiring changes to the core LDAP protocol. An example of an extended operation is StartTLS, which indicates to the server that the client wants to begin using transport layer security (TLS) to encrypt and optionally authenticate the connection.

  • LDAP controls ”   Extra pieces of information carried along with existing LDAP operations, altering the behavior of the operation. For example, the manageDSAIT control is sent along with a modify operation when the client wants to manipulate certain types of meta-information stored in the directory (this meta-information is normally hidden from users of the directory). In the future, additional controls may be defined that alter the behavior of existing LDAP operations in useful ways.

  • Simple Authentication and Security Layer (SASL) ”   A framework for supporting multiple authentication methods. By using the SASL framework to implement authentication, LDAP can easily be adapted to support new, stronger authentication methods. SASL also supports a framework for clients and servers to negotiate lower-layer security mechanisms, such as encryption of all client/server traffic. SASL is not specific to LDAP, though; its general framework can be adapted to a wide range of Internet protocols.

How does an LDAP client know whether a particular LDAP extended operation, LDAP control, or SASL mechanism is supported by the server it is in contact with? LDAP version 3 servers are required to advertise the extended operations, controls, and SASL mechanisms they support in a special directory entry called the root DSE. The root DSE contains a number of attributes that describe the capabilities and configuration of the particular LDAP server.

Standardization of LDAP Extensions

How does an enhancement such as a new extended operation, LDAP control, or SASL authentication method become a standard? It goes through a standardization process in the Internet Engineering Task Force (IETF).

First, the enhancement is described in a document called an Internet Draft. The draft is reviewed by participants in the IETF, changes and improvements are made, and revised drafts are submitted by the authors. Once there is consensus in the IETF that the enhancement is a good idea, and is soundly designed, the document becomes a Proposed Internet Standard. It then goes through more peer review, becomes a Draft Standard, and finally becomes a full Internet Standard. However, multiple interoperable implementations are required before a document makes it all the way through the standards process to prove that implementation is feasible .

At all times during this process, the document is freely available on the Internet for anyone to download, read, comment on, and implement. The whole process is designed to encourage open development of standards and thorough peer review, without bogging it down with a complex standardization process. This approach has worked quite well historically; it's how the Internet was designed and built!



The LDAP Protocol on the Wire

What information is actually transmitted back and forth between LDAP clients and servers? We won't go into a great deal of detail here because this book isn't about protocol design, but we do feel that there are a few things you might want to know about the LDAP wire protocol.

LDAP uses a simplified version of the Basic Encoding Rules (BER). BER is a set of rules for encoding various data types, such as integers and strings, in a system-independent fashion. It also defines ways of combining these primitive data types into useful structures such as sets and sequences. The simplified BER that LDAP uses is often referred to as lightweight BER (LBER). LBER does away with many of the more esoteric data types that BER can represent, and instead it represents most items as simple strings.

Because LDAP is not a simple text-based protocol like HTTP, you can't simply telnet to the LDAP port on your server and start typing commands. The LDAP protocol primitives are not simple strings, so it's difficult, if not impossible , to converse with an LDAP server by typing at it. If you are familiar with text-based Internet protocols such as POP, IMAP, and SMTP, this may seem like an unfortunate limitation. On the other hand, DNS, a very successful distributed system, uses a protocol that has nontextual protocol primitives. The presence of universal implementations of client libraries for both DNS and LDAP makes this limitation less problematic .



Understanding and Deploying LDAP Directory Services,  2002 New Riders Publishing
<  BACK CONTINUE  >

Index terms contained in this section

abandon operation
access
         user
                    directory entries 2nd
Active Directory Services Interface, see ADSI
add operation
administrators
         system
                    LDAP benefits
ADSI (Active Directory Services Interface)
APIs
          ADSI (Active Directory Services Interface)
          JNDI
APIs (application programming interface)
application programming interfaces, see APIs
applications
          building
          distinct directories
          proprietary directories
         server
                    directory enabling
         user
                    directory-enabling
authentication operations
Basic Encoding Rules, see BER
benefits
         LDAP
                    for IT decision makers
                    for software developers
                    for system administrators
BER (Basic Encoding Rules)
          LDAP wire protocol 2nd
bind operation
building applications
C API
client/server protocols 2nd 3rd 4th
clients
         requests
                    multiple 2nd 3rd
compare operation
control operations
controls
          protocol operations
delete operation
developers
         software
                    LDAP benefits
directories
         applications
                    building
          user entries 2nd
Draft Standards
          extension standards
extended protocol operations
extensions
          standardization
          standards
                    Draft Standard
                    full Internet Standard
                    IETF
                    Internet Drafts
                    Proposed Internet Standard
extranets
          resource sharing
full Internet Standards
          extension standards
functional model
HTTP (Hypertext Transfer Protocol)
Hypertext Transfer Protocol (HTTP)
IETF
          extension standards
IMAP (Internet Message Access Protocol
information model
Internet Drafts
          extension standards
Internet Message Access Protocol (IMAP)
interrogation operations
JNDI API
LBER(lightweight Basic Encoding Rules) 2nd
LDAP
          APIs
         benefits
                    for IT decision makers
                    for software developers
                    for system administrators
         clients
                    multiple requests 2nd 3rd
          exchange example 2nd 3rd
         extensions
                    standardization
                    standards
          LDIF (LDAP Data Interchange Format)
          models
          platform support
          protocol operations 2nd
          revisions
          vendor support
         wire protocol
                    LBER (lightweight Basic Encoding Rules) 2nd
LDAPv3
LDIF (LDAP Data Interchange Format)
manageDSAIT control
message-oriented protocols
messages
          search request
models
          LDAP
modify DN operation
modify operation
multiple client requests 2nd 3rd
naming model
networks
         extranets
                    resource sharing
operations
          LDAP 2nd
         protocol
                    controls
                    extended
platforms
          LDAP support
privileges
         user access
                    directory entries 2nd
Proposed Internet Standards
          extension standards
proprietary directories
          integrating applications
protocols
          client/server 2nd 3rd 4th
          HTTP (Hypertext Transfer Protocol)
          IMAP (Internet Message Access Protocol)
          message-oriented
          operations 2nd
                    controls
                    extended
requests
         client
                    multiple 2nd 3rd
resourcrs
         sharing
                    extranet environments
revisions
          LDAP
RFCs
          LDAP revisions
search operation
search request messages
security
          LDAP model
         operations
                    authentication
          TLS (transport layer security)
servers
         applications
                    directory-enabling
sharing
         resources
                    extranet environments
software
         developers
                    LDAP benefits
standardization
          extensions
standards
          extensions
                    Draft Standard
                    full Internet Standard
                    IETF
                    Internet Drafts
                    Proposed Internet Standard
StartTLS extended operation
support
          vendor
systems
         administrators
                    LDAP benefits
TLS (transport layer security)
transport layer security (TLS)
unbind operation
update operations
users
         applications
                    directory-enabling
          directory entries 2nd
vendors
          LDAP support
wire protocol (LDAP)
          LBER (lightweight Basic Encoding Rules) 2nd

2002, O'Reilly & Associates, Inc.



Understanding and Deploying LDAP Directory Services
Understanding and Deploying LDAP Directory Services (2nd Edition)
ISBN: 0672323168
EAN: 2147483647
Year: 1997
Pages: 245

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net