An OpenLDAP server can have multiple naming contexts. Generally speaking, each naming context has a separate database. In reality, multiple suffixes can be associated with a single database, but the OpenLDAP team discourages this practice. You can potentially use different kinds of databases on the same OpenLDAP server, but there is little practical reason to do so.

Because each naming context is a separate database, greater design flexibility is possible. For example, each naming context can have different configuration settings, including different replication topology, attribute indexing, or forcing the naming context to be read-only. These different configuration settings are set in the slapd configuration file under the appropriate database directive section. Alternative maintenance and optimization configurations for each naming context are also possible, which may be useful depending on the type of data in each naming context. For example, one naming context might contain data that is accessed frequently and needs a great deal of indexing for optimal performance. Another naming context might contain highly confidential data that is accessed infrequently and requires more frequent backups.

As you might have gathered already, OpenLDAP supports referrals. Both subordinate and superior referrals are supported, and the referrals can be internal or external to the directory namespace.

You can create subordinate referrals by creating an objectclass=referral entry in the appropriate location within the namespace. OpenLDAP supports the ManageDsaIT control with the add, modify, and delete operations to allow changes to referral entries. This control allows an administrator to suppress the usual behavior of the referral entry to return a client referral to another location.

Superior referrals are created in the slapd configuration file as a directive. A superior referral to the OpenLDAP root server noted above would consist of the following line:

referral        ldap://root.openldap.org/ 

OpenLDAP's referral support allows the creation of a directory distributed across multiple servers. Each server might host a separate portion of the namespace, depending on the needs of the organization. As noted in Chapter 5, there are many possible reasons for such a design, including segmenting data to a specific location or segregating client groups to a specific server.

As noted earlier, OpenLDAP supports directory replication across multiple servers. The slurpd process performs this functionality. OpenLDAP supports only single-master replication at this time. Multimaster replication is possible with the existing versions, but it is considered experimental and is poorly documented.

The slurpd process works closely with the slapd process running on the same server. The slapd configuration file controls much of the behavior of the slurpd process. Two things are needed in the master server's slapd configuration file. First, a replica directive is needed that specifies what server the replication should be directed toward as well as the authentication method and credentials that should be used in the LDAP session with this other server. The slurpd process uses the LDAP operations to perform the replication. Second, a replogfile directive is needed to instruct the slapd process to log all changes to file. This file is in turn used by the slurpd process to determine what operations need to be replicated. You may have wondered how the portion of directory to be replicated is specified in this scheme. The replication directives are placed in the same database section as the naming context that you want to replicate. You are really replicating a database via LDAP operations, and the databases on the server represent the partitions you can replicate. You'll notice this same approach to replication in many other LDAP products. In fact, Chapter 8 describes something remarkably similar with slight improvements.

OpenLDAP gives administrators a choice of databases to support the directory functionality. OpenLDAP favors the LDBM database type, and it has built-in configuration options for this database type.

However, OpenLDAP can use other types of databases, including SQL. OpenLDAP accomplishes this functionality via what it calls the Shell backend database type. The Shell backend is really just the basic interface that OpenLDAP supports to interact with other types of databases. In the slapd configuration file, you would specify an external database command for each of the ten LDAP operations. After this configuration, the OpenLDAP directory would be able to use the external database. In this case, database configuration, indexing, and optimization would all be external to OpenLDAP.

For more integrated database support, you can write your own backend. A backend is code that redirects LDAP operations to a database, thus acting as a proxy. By writing your own backend, you can allow any special database functionality to interoperate more closely with the LDAP configuration.

Indexing is an important consideration as a directory grows. When the commonly searched attributes are indexed, performance is better. Indexing all the attributes would require more resources and performance would suffer, so you should index only those attributes that are frequently used in search filters.

The level of indexing support OpenLDAP provides is dependent on the database employed. OpenLDAP favors the LDBM database type, and you can include indexing directives in the slapd configuration file only when you are using this type of data base. The indexing directives for an LDBM database are specific and support a higher degree of optimization than LDAP servers from other vendors.

The OpenLDAP indexing directives let you optimize the indexing to the type of search filter match operator that is most relevant. For example, imagine a directory with the following frequently used search filters:

(st=CA) 
(userCertificate=*)

The following indexing directives would optimize the indexing:

index st eq 
index userCertificate pres

The first directive indexes the st attribute for the equality operator, which means that the DN of every entry that has a st value needs to be kept in the index, and further that every value of the st attribute must be kept in the index so each value can be quickly matched. The second directive indexes the userCertificate attribute for the presence operator, which means that the DN of every entry that has a user certificate value needs to be kept in the index, but the values of that attribute are not needed.

In addition to the equality and presence index parameters, OpenLDAP supports several others. These include the approximate operator (the “sounds like” operator), attribute subtyping, and language attribute options (which OpenLDAP calls language tags).

Indexing is not the only factor in optimizing OpenLDAP performance. For example, the access controls employed can greatly affect directory performance.

A variety of client-based tools are provided with the OpenLDAP distribution. These tools range from ones to support the basic

LDAP operations to a few more advanced tools. Support for these tools is an integral part of the distribution, because each one uses the API library that OpenLDAP provides.

A command-line executable for a client is included in the distribution for each of the LDAP operations. The client executables include ldapdelete, ldapmodify, ldapadd, ldapmodrdn, ldapsearch, ldap_abandon, ldap_bind, and ldap_compare. Variants of each of these executables are also offered. All of the client tools are fully documented at the online OpenLDAP man pages at http://www.openldap.org/software/man.cgi, and this documentation is included in the distribution.

In addition to these basic commands, executables that support basic functionality are also included. These include operations to use the password modify control, encode elements using BER, and format the output from an entry, as well as the operations needed to step through the LDAPMessage returned by the primary operations.

By default, OpenLDAP supports only two LDAP controls. In addition to the aforementioned Password Modify Control, the ManageDsaIT control (2.16.840.1.113730.3.4.2) is supported. It allows an LDAP client to add, modify, or delete a referral internal to the directory namespace. The referral must be an entry of objectclass=referral. External referrals cannot be modified with this control. The small number of controls implemented is indicative mostly of how long OpenLDAP has been around. After a year, I'd expect that many of the common controls will be implemented. But for the time being, the lack of control support is a weakness of OpenLDAP when compared to other offerings.

By default, the OpenLDAP schema supports 81 classes. As noted earlier, these classes are primarily standard classes denoted in RFC standards. In fact, there is little in the default schema that isn't documented in an Internet standard. And unlike other vendors, OpenLDAP doesn't arbitrarily change the standards to meet some proprietary need. The only modifications to the schema elements are minor changes to allow all the schema elements to be implemented despite minor discrepancies between the standards.

OpenLDAP uses a multiple-class inheritance model, in which more than one class can be superior for any given object class. For example, the openLDAPperson class has both inetOrgPerson and pilotPerson as superior classes. This class inheritance model provides greater flexibility than the single-class model that most LDAP servers employ, and it is a nice feature for organizations looking to design a new class combining several existing definitions.

OpenLDAP implements the alias object class, which provides a level of intra-directory redirection. OpenLDAP also implements the ref object class, to support referral functionality. The combination of these two classes allows for any organizational hierarchy or distribution of a directory across multiple servers.

By default, the OpenLDAP schema supports 192 attributes. As mentioned earlier, attribute subtypes are supported as well as attribute options, including language tags. This diversity of basic attribute support means that organizations can easily implement custom attributes.

OpenLDAP implements several operational attributes. These include the modifiersName, modifyTimestamp, creatorsName, and createTimestamp attributes to track modifications to entries. These attributes will be automatically maintained by slapd if the lastmod on | off directive is set in the slapd configuration file. By default, the lastmod directive is on. Following the LDAP standards, the subschemaSubentry operational attribute is also on every entry.

There are also a few interesting attributes that OpenLDAP requires for basic functionality. Among these are the entry and children attributes. These cannot be modified by users and are maintained by the slapd process. They are used primarily to enable access control settings, but there may be secondary uses. The entry attribute allows access control of the modifyRDN operation, so when a client wants to change the name (RDN and DN) of an entry, there is an attribute to be used as a target in an ACL. The children attribute is used for a similar purpose to indicate the names of all the entries that are immediate children of the entry. How these attributes are used is covered in more detail in Appendix D.

Configuration parameters are primarily set in the slapd configuration file via directives. But because the code base is open source, motivated organizations can implement their own changes and settings as needed. We've already discussed most of the directives that can be set, except for a few omissions, which are covered here.

Backends are a way to support databases smoothly. Backends can be any module that you want to implement to extend the functionality of the slapd process. They are not limited to new database functionality. To create a backend, you use a backend directive.

OpenLDAP supports the typical limit settings that most LDAP servers support. An idletimeout directive specifies how long slapd should wait before forcibly closing idle connections. A sizelimit directive specifies the maximum number of directory entries that can be returned from a search operation. A directive called loglevel controls the logging performed by the slapd process and the level of detail.

Carnegie Mellon University's Cyrus Project provides the SASL module used with OpenLDAP. The code is freely available and widely used. The Cyrus SASL module supports several strong authentication mechanisms. The full set of supported mechanisms consists of ANONYMOUS, CRAM-MD5, KERBEROS_V4, PLAIN, SCRAM-MD5 (deprecated), GSSAPI (MIT Kerberos 5 or Heimdal Kerberos 5), DIGEST-MD5, LOGIN, and SRP.

After installing and configuring the SASL module to support authentication, you must perform additional work to establish an authorization identity on the OpenLDAP server. When a user has successfully authenticated, the SASL module passes an authentication identity to OpenLDAP. This identity does not necessarily exist within the LDAP namespace, but it does exist within the namespace of the authentication mechanism used. Usually you will map this successful authentication identity to the DN of a directory entry. This step simplifies interaction within the directory and clearly establishes the identity of the user in the context of the LDAP namespace, so the directory entry can be used as authorization information. This step isn't strictly required, however, because you can use the native authentication identity that SASL returns in access control lists.

For example, the SASL module might pass to OpenLDAP the authentication identity: uid=barkills,cn=MYCOMPANY.COM, cn=KERBEROS_V4,cn=AUTH. This identity appears to correspond to an LDAP DN, but it does not exist within the directory namespace (but it could if you just happened to use this model). The authentication identities that are passed correspond to the following format: uid=<username>,cn=<realm>,cn=<mechanism>, cn=auth. The cn=<realm> component is not used by all the mechanisms, and it may be absent.

To map the SASL authentication identity to a directory entry, you need to create one or more directives in the slapd configuration file that effectively transform the identity to correspond to a valid directory entry. The saslRegexp directives perform this transformation by using a few simple text-based pattern-matching rules to search and replace text. You must use great care in forming these directives so the wrong entry isn't mapped.

The regex or Regular Expression documentation is at http://www.openldap.org/software/man.cgi. This man page can be consulted for details. Regular expressions are a lengthy subject unto themselves, but a brief example will illustrate their use. I want to map the identity I noted above to the directory entry with the DN uid=barkills,ou=People,dc=Mycompany,dc=com. I might use the following directive to accomplish my goal:

saslRegexp 
    uid=(.*),cn=MYCOMPANY.COM,cn=Kerberos_v4,cn=auth
    uid=$1,ou=People,dc=Mycompany,dc=com

The first line has the pattern match statement that must be met for the second line to be triggered. The pattern match statement uses parentheses to denote what text to save for later use. The first set of parentheses is saved to a temporary variable called $1, and additional sets of parentheses would likewise be saved to temporary numbered variables. The period character is used as a wildcard to denote any character. The asterisk character is used to denote one or more occurrences of a character. So a period followed by an asterisk could potentially match any text string, if the two were all that was used in a pattern match. The pattern-matching statement used here basically says match any identity that employs Kerberos 4 and is in the MYCOMPANY.COM realm, while saving the uid value. The second line has the replacement statement that maps to a directory entry. The variable $1 is used and would be replaced by barkills, in my example. This would yield the DN I wanted.

More complicated statements are possible, including replacement statements that use an LDAP URL with a search filter. This would be especially useful if the DN of entries in Mydirectory didn't use the uid attribute as the RDN, but the uid attribute was a mandatory attribute. An example of this might be

saslRegexp 
uid=(.*),cn=MYCOMPANY.COM,cn=Kerberos_v4,cn=auth
ldap://server1.mycompany.com/ou=People,dc=Mycompany,
    dc=com??sub?uid=$1

OpenLDAP also offers an impersonation feature within its authentication support. An impersonation feature helps to simplify authorization and allows special directory services to act on behalf of other identities. The online OpenLDAP documentation calls the impersonation functionality “authorization,” which is a less descriptive name than is deserved and can be confusing.

Impersonation is directed using the same syntax as was used with the regex directive, but it is not done via the slapd configuration file. Instead, two attributes are used on the authorization entry that is mapped from the authentication identity. The attribute saslAuthzTo is used as a source rule, and the attribute saslAuthzFrom is used as a destination rule. The source rule lists what other authorization identities can impersonate this authorization entry. The destination rule lists what authorization identities this authorization identity can impersonate.

You can use both source and destination rules, but only one is required. Suppose I wanted to allow my entry, DN cn=Brian Arkills,ou=People,dc=Mycompany,dc=com, to be able to impersonate Han Solo's entry with DN cn=Han Solo,ou=People, dc=Mycompany,dc=com. I could enable this impersonation in either of two ways. Using my entry, I could set saslAuthzTo= cn=Han Solo,ou=People,dc=Mycompany,dc=com. Using Han Solo's entry, I could set saslAuthzFrom= cn=Brian Arkills, ou=People,dc=Mycompany,dc=com. Either is effective and would accomplish the same end.

But impersonation is more useful than this example illustrates. For example, let's say I have a special Web site where users can change their directory entry without having to use unfriendly LDAP syntax. Users authenticate to the Web site, view their directory entry, and visually edit their information. Behind the scenes, an application service running at the Web site retrieves their entries using an LDAP search and makes modifications using LDAP operations. To do this, the application service must have an authorization entry in the directory, and that entry must be granted the ability to impersonate each of the users. For this purpose, its entry might have saslAuthzTo=uid=.*,ou=People, dc=Mycompany,dc=com or saslAuthzTo=ldap://host/ ou=People,dc=Mycompany,dc=com??sub?objectclass=Person. Many entries are indicated by the value. Another approach would be set the saslAuthzFrom attribute of every person's entry to the service's DN.

Some directory administrators use the concept of impersonation in a manner similar to how security groups are used in most file systems. They set a simple set of access controls on naming contexts that give access rights to a small set of authorization identities. These authorization identities are effectively proxy accounts that are used to provide different levels of access. Then users are given impersonation rights to these special accounts depending on the level of access they need. This scheme simplifies the access controls that need to be set on the directory while also simplifying the delegation needed. But it also obscures the audit trail and makes it difficult to monitor access. This is bad security practice but optimizes performance. However, if you keep this fault in mind and minimize the impact, you can use impersonation to simplify the access controls.

Speaking of access controls, it's high time to discuss how OpenLDAP provides this functionality. OpenLDAP implements an access control in the form of an open, flexible access control policy. A traditional access control list (ACL) model would place a separate ACL on each entry, possibly with inherited settings from parent entries. With OpenLDAP, there is not a separate access control list for each entry. Instead, directives in the slapd configuration file form the basis for an access control policy. The directives are set at two levels, one at the database level (in other words, the naming context level) and one at the global level. Access is determined by the first matching access directive, starting at the database level and proceeding to the global level. A simple example of an access directive is provided here. For more details and examples, see Appendix D.

The access directives themselves resemble access control entries (ACEs) with the added information of the directory entries to which the ACE applies. There are three primary elements to an access directive: <what> entries, <who> should have access, and what level of <access>. As you might expect, most of the format of these elements relies on the formatting expected by the regex command. The basic format of an access directive is:

access to <what> by <who> <access> 

There can be multiple instances of the by <who> and <access> elements for each <what> element.

Here is an example access directive:

access to dn=_.*,ou=People,dc=Mycompany,dc=com 
    by dn=_cn=Han Solo,ou=People,dc=Mycompany,dc=com
       write
    by dn=_.*,ou=People,dc=Mycompany,dc=com read

This directive gives control access to all the entries immediately subordinate to the People OU. The user authenticated as the Han Solo entry has write-level access, and users authenticated as one of the entries within the People OU have read-level access.

In addition to this traditional ACL approach, OpenLDAP supports many different access control factors. These factors include wildcards (used in the example above), membership in a group, dynamic access control, the DNS domain of the client, and the IP address of the client. Multiple combinations of these factors are also supported. You can also use authentication method as an access control factor, but not as part of the access directive. With a require directive, a certain type of authentication method can be mandated either on a global basis or by database. For example, you might accept access only via Kerberos authentication.

There is one problem with all of these access control methods. All of them are created in the slapd configuration file, and additions require that the slapd process be stopped and restarted. This means a short directory service outage on any access control configuration, which may not be acceptable in some environments. You can minimize this problem by configuring access controls that encompass all expected situations, but there will inevitably be situations that require a change.

OpenLDAP supports an experimental access control factor that is not subject to this problem. Experimental features in OpenLDAP are not fully supported, and assistance is on a best-effort basis. ACI expressions are considered experimental, mostly because the standard governing the definition hasn't been completed, but also because the full set of functionality in the existing definition hasn't been implemented in the code base yet. ACI expressions move the configuration and evaluation of access control from the slapd configuration file to an attribute on the entry. This approach provides a major benefit: access control changes can be made without restarting the slapd process. Appendix D includes pointers on how to find out more about ACI expressions.

There is a special entry called the rootdn that is not limited by any authorization factors. Administrators can use this account for various activities. Within the slapd configuration file, two directives are required to initially identify this account. The rootdn directive specifies the DN of this entry. The rootpw directive specifies a password for the entry specified by the rootdn directive. This password will work regardless of the userPassword attribute that is set on the entry. This password is in cleartext in the configuration file. You should take measures to restrict access to this file because it holds the key to all of your directory data.

Transport Layer Security is provided by the OpenSSL libraries for SSL and TLS. OpenSSL is open source software, just as OpenLDAP is. You download the code, compile it for your platform, then install and configure it. The OpenSSL Web site, http://www.openssl.org/, documents common issues, as well as providing support and instructions.