This section provides information on the Lightweight Directory Access Protocol (LDAP). This information includes basic concepts, overview subjects and associated notes , along with querying, installing and configuring procedures. Links to related information appear at the end of this section.
|This section is applicable to all supported operating systems, except Linux for S/390.|
The following section addresses questions about what LDAP is and how it works, and provides high level overviews of X.500 and LDAP.
What is LDAP?
The Lightweight Directory Access Protocol (LDAP) exists as an information directory where you define users and groups once and share them across multiple machines and multiple applications.
How does LDAP work?
The IBM HTTP Server LDAP plug-in enables the directory to perform authentication and authorization required when accessing a protected resource. This capability greatly decreases the administrative overhead for maintaining user and group information locally for each Web server.
The IBM HTTP Server supports LDAP, a protocol that provides access to the X.500 directory, over a TCP or SSL connection. LDAP lets you store information in a directory service and perform queries in a database. When you use X.500 directories and LDAP, any LDAP-enabled application can store information, such as user authentication information, once other applications using the LDAP server can recognize this data.
LDAP reduces required system resources, by including only a functional subset of the original X.500 Directory Access Protocol (DAP).
IBM HTTP Server LDAP support offers a choice of LDAP configurations including:
This information assumes you have an existing X.500 directory service available, for example, the IBM SecureWay X.500 directory.
X.500 provides a directory service with components capable of more efficient retrieval. LDAP uses two of these components: the information model, which determines the form and character, and the namespace, which enables information indexing and referencing.
The X.500 directory structure differs from others in information storage and retrieval. This directory service associates information with attributes. A query based on attributes generates and passes to the LDAP server, and the server returns the respective values. LDAP uses a simple, string-based approach for representing directory entries.
An X.500 directory consists of typed entries, based on the ObjectClass attribute. Each entry consists of attributes. The ObjectClass attribute identifies the type of entry, for example, person or organization, which determines the required and optional attributes.
You can divide entries, arranged in a tree structure, among servers in geographical and organizational distribution. The directory service names entries, according to their position within the distribution hierarchy, by a distinguished name (DN).
Accessing an X.500 directory requires a certain protocol, for example Directory Access Protocol (DAP). However, DAP requires large amounts of system resources and support mechanisms to handle the complexity of the protocol. To enable desktop workstations to access the X.500 directory service, LDAP was introduced.
LDAP, a client and server-based protocol can handle some of the heavy resources required by DAP clients. An LDAP server can only return results or errors to the client, requiring little from the client. If unable to answer a client request, an X.500 server must chain the request to another X.500 server. The server must complete the request, or return an error to the LDAP server, which in turn passes the information to the client.
LDAP accesses the X.500 directory through human readable strings. When these query strings pass to the LDAP server, the server returns the distinguished name of the entry.
You find LDAP entries typed, or classified, by an ObjectClass attribute to simplify searches. For example, you can search an LDAP directory with objectclass=acl to locate all entries using access control lists.
A search filter for an LDAP entry has the following structure:
For more information on LDAP search filters, see RFC 1960.
The following LDAP search filter: (cn=Joe Smith) searches the directory service for the common name of Joe Smith. Possible matches include:
The following search filter: (!(cn=Jane Doe)) queries the directory service for entries whose common name does not equal Jane Doe. Possible matches include:
Joe Schmoe Adam Fosset any name other than Jane Doe
The following search filter: (&objectClass=acl)((sn=Johnson) queries all access control list (ACL) entries matching a surname of Johnson. Possible matches include:
Peter Johnson Davey Johnson
The following search filter: (o=univ*of*carolin*) queries the organization attribute. Possible matches include:
University of North Carolina Chapel Hill University of South Carolina
LDAP can return more than one entry. However, the Web server does not authenticate when multiple entries return. If the directory queried by this example contained both the University of North Carolina and the University of South Carolina, the server returns both entries, and authentication fails. You must alter the search filter.
Running the IBM HTTP Server LDAP module requires a separate download of the LDAP client. You can obtain the LDAP client by either:
If you download the client from a Web site, you can see references to the SecureWay directory. The SecureWay directory contains the LDAP client, which provides access to LDAP-capable servers. These instructions pertain to the Windows NT operating system only.
To download the LDAP client from a Web site:
You do not need to download the LDAP Client on the AIX, HP, Linux and Solaris operating systems.
To configure LDAP on the IBM HTTP Server to protect files, follow these steps:
LDAPRequire filter "ldap_search_filter"
The LDAPRequire directive only works if manually inserted into the httpd.conf file.