This section describes LDAP server software available for Linux from different vendors.
All applications reside on top of two libraries: liblber, which handles the ASN.1 encoding, and libldap, which handles the application layer protocol. The package includes all the applications, which were already present in the distribution from the University of Michigan, namely the command line tools to search and update the directory, a standalone directory server (slapd) and slurpd, the standalone ldap update replication deamon. slurpd can be used to implement a single-master replication architecture.6.4 OpenLDAP does not have the ability to do online back-ups. The server has to be shutdown before administrative utilities can be used to dump or restore the database to or from an LDIF file.
The slapd directory server consists of a front-end, which handles the communication with a client according to the LDAP protocol specification, and a number of back-ends, which implement non-volatile data storage. The most commonly used back-end is called gdbm. It stores directory information using the Berkeley embedded database system from Sleepycat.6.5 Other back-end modules have been written to allow LDAP access to various existing data sources:
OpenLDAP offers a wide range of security features. It makes use of the libraries from the OpenSSL6.7and Cyrus SASL6.8projects to support transport layer security and offer the most complete support for authentication features.
Some features, which would be needed to make OpenLDAP a ``really grown up'' server, are currently only available from the head branch. This includes support for multi-master replication and the ability to store access control information in the directory itself. Until the latter feature becomes available, access control lists will have to be statically configured in a config file. Changing one of these directives requires a restart of the server, as do changes to the schema. As the directives are evaluated on a first match basis, great care must be taken in writing them to achieve the desired result. The common approach is to write rules that affect large parts of the directory and then to specify stricter or more relaxed rules for subordinate areas. However, this scenario is not possible because in practice, evaluation is stopped at the first matching rule.
Directories for large enterprises or directories with a flat DIT structure can contain thousands of entries in a container. Clients trying to browse such a server might not have the required resources to handle this kind of result set or could be connected to the server over a low-bandwidth connection. LDAP controls have therefore been defined which allow the client to specify that the server should only return parts of the complete result set at a time. The OpenLDAP slapd does not support either of the two proposed mechanisms [99,1]; however, they are supported in the client library. In a similar vein, the SDK supports a control that instructs the server to sort matching entries before returning them [33], while the OpenLDAP server does not.
Another area which could be improved, is documentation--especially documentation that keeps up with rapid development. To fully keep up with the most recent versions, one needs to monitor the relevant mailing lists. They are a valuable source of information and can offer help in the case of problems arising as the developers themselves respond to postings on these lists.
Today the directory activities lie with ``iPlanet e-commerce solutions'', an alliance formed by Netscape, Sun and AOL in 1999. The current release of the directory server software is version 4.13. In March 2000 Sun Microsystems also acquired Innosoft International, Inc., whose products included Innosoft Distributed Directory Server. The upcoming 5.0 release of the iPlanet directory server will incorporate Innosoft's technology and will offer advanced features such as multi-master replication and LDAP chaining. The beta version of this product has been available since December 2000, not for the Linux platform however, and is therefore not been dealt with by this thesis.
iPlanet offers a plug-in interface [34] to extend the capabilities of the server. With it, a developer can write modules that provide additional checks on LDAP operations, add new syntaxes and matching rules, implement support for extended operations or new authentication mechanisms, and can even use a custom database back-end.
The Netscape Directory Server comes with a Java based management tool and a HTTP-to-LDAP gateway.
The provided plug-in API is compatible to that which would be found in the Netscape Directory Server.
IBM uses the relational DB2 Universal Database as a back-end storage mechanism for the SecureWay directory server. To administrate the server a web based tool is provided, which is not yet available for Linux. Additionally the software package includes a schema-aware Java application to manage the directory.
The current source code release R6.0v3p2 implements both the X.500 (93) standard and LDAPv3. Like OpenLDAP, it uses the Berkeley database system as a back-end storage mechanism. An LDAP-to-HTML gateway (WebXS) is included in the package as well as two TCL script based administration tools, one for the server administration (EDM) and one for data maintenance (DDM).
Outstanding is lbe's drag&drop support. This feature can be used to move or copy entries in the DIT but also to add the dragged entry's DN to an attribut of another entry. This way, an administrator can intuitively manage group memberships or role assignments. lbe lacks support for schema information offered by the directory server. Instead, it employs a template mechanism to aid the administrator in creating new entries.
Applications under Linux interact with the system by calling functions of the C library. As part of the C library an API exists, which allows data to be searched for in administrative system databases. This API includes functions to enumerate (e.g. getpwent to consecutively list all users) and search (e.g. getpwnam to search for a user by name) for users and groups as well as IP services, protocols, hosts and networks.
Originally, these databases were stored as plain text files on a
host's local file system (e.g., /etc/passwd or
/etc/groups). This was followed by proprietary extensions
that used a special entry in these files to signal that data should
instead be retrieved from other sources. For Solaris 2, Sun designed a
modular architecture--called Name Service Switch--that
defines an interface between the core C library and a service module
that implements a particular type of information storage (see
Figure
. The GNU C library, which Linux uses, follows
this concept.
nss_ldap6.14 is a NSS service module that retrieves information from an LDAP server. It is the reference implementation of [23], which proposes a schema for storing name service related data in a directory.
pam_ldap6.15 implements authentication, account and password management with LDAP as data store. To authenticate a user, pam_ldap first searches for the provided username in the directory. If a match is found, pam_ldap then tries to bind to the entry found. It does this with call to ldap_simple_bind. To protect the transferred password, security layers provided by LDAPS or StartTLS are supported.
In the account management stage, pam_ldap retrieves the information stored under the user's entry to be able to check for account and password expiration, groupmember ship and host restrictions.
Finally, the password management section provides the user with the
ability to change his password on the LDAP server. Besides a plain
replace on the ``userPassword'' attribute, pam_ldap supports the LDAP
password modify extended operation [106] as well as password
changing for NDS and Active Directory (see Section
).
The upcoming 8.12 release will also be able to natively use LDAP look-ups for a wide range of configuration properties (i.e. Aliases, Maps and Classes).
Norbert Klasen 2001-10-22