$ cd openldap-2.1.8/
$ ./configure --enable-wrappers
Be sure to examine the output that follows this command to verify that the correct DBM libraries were located and any other options you defined were correctly configured. Once you are satisfied with the configuration process, building the OpenLDAP clients and servers is a four-step process:
$ make depend
$ make
$ make test
$ /bin/su -c "make install"
Here are some things to check if you have any problems:
On systems that support it, the ldd tool can be used to verify that the LDAP server binary, slapd, is linked with the correct shared libraries. For example, if libsasl.so cannot be located but is installed in /usr/local/lib/, check your system's documentation for adding directories to the library search path. Under Linux, add the directory to /etc/ld.so.conf and rerun ldconfig -v; under Solaris (or Linux), set the LD_LIBRARY_PATH environment variable.
Verify that DNS resolution for your host is configured correctly. In particular, reverse DNS resolution is important. Problems with DNS resolution can make it appear that the OpenLDAP server is not responding.
Verify that the network interface on the host is configured and functioning properly. I experience this problem quite often when using my laptop as a test server.
OpenLDAP Clients and Servers
The OpenLDAP package includes clients, servers, and development libraries. Table 3-1 gives an overview of the utilities that come with the package. All pathnames are relative to the installation location, which defaults to /usr/local.
Table 3-1. Installed components included with OpenLDAP
Name
Description
libexec/slapd
The LDAP server.
libexec/slurpd
The LDAP replication helper.
bin/ldapadd
bin/ldapmodify
bin/ldapdelete
bin/ldapmodrdn
Command-line tools for adding, modifying, and deleting entries on an LDAP server. These commands support both LDAPv2 and LDAPv3.
bin/ldapsearch
bin/ldapcompare
Command-line utilities for searching for an LDAP directory or testing a compare operation on a specific attribute held by an entry.
bin/ldappasswd
A tool for changing the password attribute in LDAP entries. This tool is the LDAP equivalent of / bin/passwd.
sbin/slapadd
sbin/slapcat
sbin/slapindex
Tools for manipulating the local backend data store used by the slapd daemon.
sbin/slappasswd
A simple utility to generate password hashes suitable for use in slapd.conf.
lib/libldap*
lib/liblber*
include/ldap*.h
include/lber*.h
The OpenLDAP client SDK.
The slapd.conf Configuration File
The slapd.conf file is the central source of configuration information for the OpenLDAP standalone server (slapd), the replication helper daemon (slurpd), and related tools, such as slapcat and slapadd. As a general rule, the OpenLDAP client tools such as ldapmodify and ldapsearch use ldap.conf (not slapd.conf) for default settings.
In the tradition of Unix configuration files, slapd.conf is an ASCII file with the following rules:
Blank lines and lines beginning with a pound sign (#) are ignored.
Parameters and associated values are separated by whitespace characters (space or tab).
A line with a blank space in the first column is considered to be a continuation of the previous one. There is no need for a line continuation character such as a backslash ().
For general needs, the slapd.conf file used by OpenLDAP 2 can be broken into two sections. The first section contains parameters that affect the overall behavior of the OpenLDAP servers (for example, the level of information sent to log files). The second section is composed of parameters that relate to a particular database backend used by the slapd daemon. It is possible to define some default settings for these in the global section of slapd.conf. However, any value specified in the database section will override default settings.
Here's a partial listing that shows how these two sections look:
# /usr/local/etc/openldap/slapd.conf
# Global section
## Global parameters removed for brevity's sake, for now . . .
#######################################################
# Database #1 - Berkeley DB
database bdb
## Database parameters and directives would go here.
#######################################################
# Database #2 - Berkeley DB
database bdb
## Database parameters and directives would go here.
## And so on . . .
The global section starts at the beginning of the file and continues until the first database directive. We will revisit the few parameters listed here in a few moments.
The start of a database backend section is marked by the database parameter; the section continues until the beginning of the next database section or the end of the file. It is possible to define multiple databases that are served by a single installation of slapd. Each one is logically independent, and the associated database files will be stored separately.
* * *
Warning
For security reasons, the slapd.conf file should be readable and writable only by the user who runs the slapd daemon, which is normally the superuser. A working server's slapd.conf often contains sensitive information that should be restricted from unauthorized viewing.
* * *
Schema Files
The first step in configuring your LDAP server is to decide which schema the directory should support. It's not easy to answer this question in a few lines. We'll start our example with the bare minimum.
OpenLDAP 2 includes several popular schema files to be used at the administrator's discretion. The needs of the applications that will use the directory determine which schema you use. All the attributeType and objectClass definitions required for a bare-bones server are included in the file core.schema. Some of these attributeTypes and objectClasses are:
Attributes for storing the timestamp of the last update on an entry
Attributes for representing name, locations, etc.
Objects to represent an organization or person
Objects to represent DNS domain names
And so on . . .
By default, this file is located in the directory /usr/local/etc/openldap/schema/ after installation. In the configuration file, the include parameter specifies schemas to be included by the server. Here's how the file looks for a minimal configuration:
# /usr/local/etc/openldap/slapd.conf
# Global section
## Include the minimum schema required.
include /usr/local/etc/openldap/schema/core.schema
#######################################################
## Database sections omitted
* * *
Tip
I won't discuss the details of what is contained in core.schema yet. I'll delay this discussion until adequate time can be spent on the syntax of the file. If you would like a head start, reading RFC 2552 will provide the necessary knowledge for understanding the majority of OpenLDAP's schema files.
* * *
There are several schema files included with a default OpenLDAP 2.1 installation:
corba.schema
A schema for storing Corba objects in an LDAP directory, as described in RFC 2714.
core.schema
OpenLDAP's required core schema. This schema defines basic LDAPv3 attributes and objects described in RFCs 2251-2256.
cosine.schema
A schema for supporting the COSINE and X.500 directory pilots. Based on RFC 1274.
inetorgperson.schema
The schema that defines the inetOrgP
erson object class and its associated attributes defined in RFC 2798. This object is frequently used to store contact information for people.
java.schema
A schema defined in RFC 2713 for storing a Java serialized object, a Java marshalled object, a remote Java object, or a JNDI reference in an LDAP directory.
misc.schema
A schema that defines a small group of miscellaneous objects and attributes. Currently, this file contains the schema necessary to implement LDAP-based mail routing in Sendmail 8.10+.
nis.schema
A schema that defines attributes and objects necessary for using LDAP with the Network Information Service (NIS) as described in RFC 2307 (see Chapter 6).
openldap.schema
Miscellaneous objects used by the OpenLDAP project. Provided for information purposes only.
The client applications that you want to support may require you to include schema files in addition to core.schema. Make sure you are aware of dependencies between schema files. Dependencies are normally described at the beginning of the file. For example, many applications require you to include the inetOrgPerson object class, which is frequently used to store contact information. The beginning of the inetorgperson.schema file tells you that you must also include cosine.schema.
Logging
The next group of parameters that you frequently find in the global section of slapd.conf control where slapd logs information during execution, as well as how much information is actually written to the log. Here's our configuration file with logging added:
# /usr/local/etc/openldap/slapd.conf
# Global section
## Include the minimum schema required.
include /usr/local/etc/openldap/schema/core.schema
## Added logging parameters
loglevel 296
pidfile /usr/local/var/slapd.pid
argsfile /usr/local/var/slapd.args
#######################################################
## Database sections omitted
The first new parameter is loglevel . This directive accepts an integer representing the types of information that should be recorded in the system logs. It is helpful to think of loglevel as a set of bit flags that can be logically ORed together. The flags are listed in Table 3-2. In this example, the logging level is set to 296, which equals 8 + 32 + 256. Table 3-2 tells us that this value causes slapd to log the following information:
8
Connection management
32
Search filter processing
256
Statistics for connection, operations, and results
Table 3-2. OpenLDAP logging levels
Level
Information recorded
-1
All logging information
0
No Logging information
1
Trace function calls
2
Packet-handling debugging information
4
Heavy trace debugging
8
Connection management
16
Packets sent and received
32
Search filter processing
64
Configuration file processing
128
Access control list processing
256
Statistics for connection, operations, and results
512
Statistics for results returned to clients
1024
Communication with shell backends
2048
Print entry parsing debug information
All debugging information is logged using the LOG_LEVEL4 syslog facility. Therefore, to instruct slapd to write log entries to a separate log file, add the following line to /etc/syslog.conf and instruct the syslogd daemon to reread its configuration file by sending it a hangup (kill -HUP) signal:
local4.debug /var/log/slapd.log
The syntax of syslog.conf on your system may be slightly different, so you should consult the syslog.conf manpage for details.
* * *
Warning
Some syslogd daemons require that the specified logging file exists before they write information to the log. If you think you have set up syslog correctly, but no data is being collected and your file doesn't exist, try creating the logging file with the touch command.
* * *
The remaining two parameters introduced in this section can be summed up in a sentence or two:
pidfile filename
This parameter specifies the absolute location of a file that will contain the process ID of the currently running master slapd process.
argsfile filename
This parameter specifies the absolute path to a file containing the command-line parameters used by the currently running master slapd. This parameter is processed only if slapd is started without the debug command-line argument.
SASL Options
When I first introduced the topic of installing the Cyrus SASL libraries, I said that SASL is not needed if only simple binds will be used to access the directory. However, it's often useful to allow a combination of simple binds and SASL mechanisms for user connections. For example, we might want to allow most users (who are only allowed to look up data) to authenticate via a simple bind, while requiring administrators (who are allowed to change data) to authenticate via SASL. So let's see how to configure the directory server to require the use of SASL for certain administrative accounts, while still allowing simple binds (possibly over TLS) for most clients.
slapd.conf has three SASL-related global options. These are:
sasl-host hostname
sasl-realm string
sasl-secprops properties
sasl-host is the fully qualified domain name of the host used for SASL authentication. For local authentication mechanisms such as DIGEST-MD5, this will be the host and domain name of the slapd server. sasl-realm is the SASL domain used for authentication. If you are unsure of this value, use sasldblistusers to dump the /etc/sasldb database and obtain the realm name to use.
The third parameter, sasl-secprops, allows you to define various conditions that affect SASL security properties. The possible values for this parameter are given in Table 3-3. Note that it is legal to use multiple values in combination. The default security properties are noanonymous and noplain.
Table 3-3. sasl-secprops parameter values and descriptions
Flag
Description
None
Clears the default security properties (noplain, noanonymous).
noplain
Disables mechanisms vulnerable to passive attacks, such as viewing network packets to examine passwords.
noactive
Disables mechanisms vulnerable to active attacks.
nodict
Disables mechanisms that are vulnerable to dictionary-based password attacks.
noanonymous
Disables mechanisms that support anonymous login.
forwardsec
Requires forward secrecy between sessions.
passcred
Requires mechanisms that pass client credentials.
minssf= factor
Defines the minimum security strength enforced. Possible values include: 0 (no protection), 1 (integrity protection only), 56 (allow DES encryption), 112 (allow 3DES or other string encryption methods), and 128 (allow RC4, Blowfish, or other encryption algorithms of this class).
maxssf= factor
Defines the maximum security strength setting. The possible values are identical to those of minssf.
maxbufsize= size
Defines the maximum size of the security layer receive buffer. A value of 0 disables the security layer. The default value is the maximum of INT_MAX (i.e., 65536).
To fully understand the sasl-secprops parameter, you must also understand the effects of the various cyrus-sasl plug-ins. Table 3-4 summarizes the available mechanisms and property flags.
>
Table 3-4. SASL authentication mechanism security properties
SASL mechanism
Security property flags
maxssf
ANONYMOUS
NOPLAIN
0
CRAM-MD5
NOPLAIN
NOANONYMOUS
0
DIGEST-MD5
NOPLAIN
NOANONYMOUS
128 if compiled with RC4; 112 if compiled with DES; 0 if compiled with neither RC4 nor DES
GSSAPI
NOPLAIN
NOACTIVE
NOANONYMOUS
56
KERBEROS_V4
NOPLAIN
NOACTIVE
NOANONYMOUS
56
LOGIN
NOANONYMOUS
0
PLAIN
NOANONYMOUS
0
SCRAM-MD5
NONE
0
SRP
NOPLAIN
0
Consider if you had added the following line to the global section of your current slapd.conf:
## No PLAIN or ANONYMOUS mechanisms; use DES encrpytion
LDAP System Administration Page 6