LDAP: IBM HTTP Server
System Administration IBM HTTP Server documentation

Using the Lightweight Directory Access Protocol

This section provides information on the Lightweight Directory Access Protocol (LDAP). This information includes basic concepts, overview subjects and associated notes Note:, along with querying, installing and configuring procedures. Links to related information appear at the end of this section.
Pertains to Linux for S/390 users Note: This section is applicable to all supported operating systems, except Linux for S/390.

Introducing the Lightweight Directory Access Protocol

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:

  • A single LDAP server
  • Different LDAP servers accessed for different requests. For example, requests can come in from two different IP addresses, and the Web server can contact a different LDAP server for each request.

This information assumes you have an existing X.500 directory service available, for example, the IBM SecureWay X.500 directory.

X.500 overview

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).

LDAP overview

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.

Querying the LDAP server using LDAP search filters

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:

  • Filters must begin and end with parentheses. See the following examples which show the placement of parentheses in complex queries.
  • Filters can contain the following Boolean comparisons:
    • & - Boolean AND
    • | - Boolean OR
    • ! - Boolean NOT
  • A particular object class, can require an attribute name.
  • Filters can contain the following equality expressions
    • = - equal to
    • ~= - approximately equal to
    • >= - greater
    • <= - less
  • Filters must contain the value of the attribute on which to search. This value can contain wildcards.

For more information on LDAP search filters, see RFC 1960.

Looking at examples of LDAP search filters

The following LDAP search filter: (cn=Joe Smith) searches the directory service for the common name of Joe Smith. Possible matches include: 

Joe Smith

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

Tip: 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.

Pertains to Windows NT users Pertains to Windows 2000 users

Installing the LDAP client

Running the IBM HTTP Server LDAP module requires a separate download of the LDAP client. You can obtain the LDAP client by either:

  • Installing the client from the SecureWay directory CD, shipped inside the IBM WebSphere Application Server V3.5 and later.
  • Downloading the client from a Web site and installing the client outside of the IBM HTTP Server installation.

Tip: 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.

Pertains to Windows NT users Pertains to Windows 2000 users

To download the LDAP client from a Web site:

  1. Open a browser and go to: LDAP Download
  2. Click the applicable platform version. The SecureWay Directory Evaluation Code window appears.
  3. Click Download.
  4. Click the applicable V4.1 platform version of the listed directory server software and Client Software Developer Kits.
  5. Click Download.
  6. Select the appropriate language for the platform choice at the SecureWay directory and Client SDK Version 4.1 window, by clicking the down arrow key and clicking the language.
  7. Click Continue.
  8. Register for the download and provide a user ID and password, if asked at the next window.

  9. Unzip the file.
  10. Install the client, following the instructions in the Installation and Configuration Guide.
Pertains to AIX users
Pertains to the HP-UX users
Pertains to the Linux users
Pertains to Solaris users

You do not need to download the LDAP Client on the AIX, HP, Linux and Solaris operating systems.

Configuring LDAP on the IBM HTTP Server

To configure LDAP on the IBM HTTP Server to protect files, follow these steps:

  1. To define by user:
    1. Launch the IBM Administration Server.
    2. Go to Access Permissions > General Access and insert the file, LdapConfigFile (C:/Program Files/IBM HTTP Server/conf/ldap.prop) in the LDAP: Configuration File field. This file is required.

    3. Enter the authentication realm name for the directory in the Authentication Realm Name field.
  2. To define by group:

    LDAPRequire group "group_name"
    Example: LDAPRequire group "Administrative Users"

  3. To define by filter:

    4. LDAPRequire filter "ldap_search_filter"
    For example: LDAPRequire filter "(&(objectclass=person)(cn=*)(ou=IHS)(o=IBM))"

    Note The LDAPRequire directive only works if manually inserted into the httpd.conf file.

  4. To create an LDAP connection, provide information about the LDAP server used. Edit your LDAP properties file, sample ldap.prop, found in the IBM HTTP Server conf directory and insert the applicable directives:
    • Enter the Web server connection information
    • Enter client connection information
    • Enter timeout settings

  5. Click Submit to continue, or Reset to clear the form.
Finding related information
     (Back to the top)