LDAP: IBM HTTP Server
System Administration IBM HTTP Server documentation
Applies to AIX Applies to Solaris Applies to Windows NT

LDAP


Introduction and Concepts

What is LDAP?

LDAP (Lightweight Directory Access Protocol) is an information directory where users and groups can be defined only once and shared across multiple machines and multiple applications.

How does LDAP work?

The IBM HTTP Server LDAP plugin allows authentication and authorization (which is required when accessing a protected resource) performed by the directory. This capability greatly decreases the administrative overhead for maintaining user and group information locally for each Web server.

IBM HTTP Server supports the use of Lightweight Directory Access Protocol (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 once, such as user authentication information, and other applications using the LDAP server will recognize it.

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 is extremely scalable. You have 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 could contact a different LDAP server for each request.

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

X.500 Overview

X.500 is a directory service with components that provide more efficient retrieval. LDAP uses two of these components: the information model, which determines the form and character, and the namespace, which allows information to be indexed and referenced.

The X.500 directory structure differs from others in the way the information is stored and retrieved. Information is associated with attributes. A query based on attributes is generated and sent 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 entries, which are typed, depending on the ObjectClass attribute. Each entry is composed of attributes. The ObjectClass attribute identifies the type of entry (for example, person or organization), which determines which attributes are required, and which are optional.

Entries, arranged in a tree structure, can be divided among servers in geographical and organizational distribution. Entries are named 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 allow desktop workstations to access the X.500, LDAP was introduced.

LDAP is client/server based and some of the heavy resources required by DAP clients are handled by the LDAP server. An LDAP server can only return results or errors to the client, requiring little from the client. If an X.500 server is unable to answer a client request, it 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 (Lightweight Directory Access Protocol) is an information directory where users and groups can be defined only once and shared across multiple machines and across multiple applications. The IBM HTTP Server LDAP plugin allows authentication and authorization (which is required when accessing a protected resource) by the directory, thereby greatly decreasing the administrative overhead for maintaining user and group information locally for each Web server.

Querying the LDAP Server

LDAP Search Filters

LDAP accesses the X.500 directory through human readable strings. When these query strings are passed to the LDAP server, the server returns the distinguished name of the entry.

LDAP entries are typed, or classified, by an ObjectClass attribute to simplify searches. For example, you can search an LDAP directory whose objectclass=acl to locate all entries that are 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 may contain the following Boolean comparisons:
    • & - Boolean AND
    • | - Boolean OR
    • ! - Boolean NOT
  • Depending on the objectclass, an attribute name may be required.
  • 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.

Examples of LDAP Search Filters

(cn=Joe Smith)
searches the directory service for the common name of Joe Smith. Possible matches are:
Joe Smith

(!(cn=Jane Doe))
queries the directory service for entries whose common name is not Jane Doe. Possible matches are:
Joe Schmoe
Adam Fosset
any name other than Jane Doe

(&objectClass=acl)((sn=Johnson)
queries all acl entries matching a surname of Johnson. Possible matches are:
Peter Johnson
Davey Johnson

(o=univ*of*carolin*)
queries the organization attribute. Possible matches are:
University of North Carolina Chapel Hill
University of South Carolina
Note:LDAP can return more than one entry. However, the Web server will not authenticate when multiple entries are returned. If the University of North Carolina and the University of South Carolina were included in the directory queried by this example, both would be returned, and the authentication would fail. The search filter must be altered.

Installing 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.
  • Downloading the client from a Web site and installing the client outside of the IHS installation.
Note:If you download the client from a Web site, you might see references to the SecureWay directory. The SecureWay Directory contains the LDAP client, which provides access to LDAP-capable servers.

To download the LDAP client from a Web site:

Applies to AIX platform Applies to Solaris platform Applies to Windows platform
  1. Open a browser and go to: LDAP Download
  2. Click on the applicable platform version. The SecureWay Directory Evaluation Code window appears.
  3. Click on the Download button. SecureWay directory, Version 3.2.1 provides a different encryption support library than that shipped in the IBM HTTP Server. To enable LDAP authentication over SSL, download the correct version of the encryption support library at the Downloads site.
  4. Click on the 3.2.1 platform version of the listed Directory Server software and Client Software Developer kits.
  5. Click on the Download button.
  6. Select the appropriate language for the platform choice at the SecureWay Directory and Client SDK Version 3.2.1 window, by clicking on the down arrow key and clicking on the language.
  7. Click Continue.

    Note:Triple DES on AIX, Solaris and windows NT is available only in Canada and the U.S.

    Register for the download and provide a user ID and password, if asked at the next window.

  8. Unzip the file.
  9. Install the client following the instructions in the Installation and Configuration Guide.
Applies to Solaris platform There is no need to download the LDAP Client on Solaris for this release.

Configuring LDAP on IBM HTTP Server

Using LDAP to Protect Files

  1. To define by user:

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

    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"
    Example: LDAPRequire filter "(&(objectclass=person)(cn=*)(ou=IHS)(o=IBM))"

    Note: LDAPRequire will only work if it is manually inserted into httpd.conf.

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

  6. Click Submit to continue or Reset to clear the form.
Related information...

     (Back to Top)