LDAP System Administration [Electronic resources] نسخه متنی

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

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.

3.5.1 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

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
inetOrgPerson 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
JDNI 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
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.

3.5.2 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

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.

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.

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

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.

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
sasl-secprops     noplain,noanonymous,minssf=56

Comparing the value of sasl-secprops with the
mechanisms listed in Table 3-4 shows that your
server will allow only the following mechanisms for authentication:

DIGEST-MD5
GSSAPI
KERBEROS_4

This configuration assumes that all of these SASL plug-ins have been
installed as well. Also remember that configuring these SASL
parameters does not require that an SASL mechanism must always be
used for authentication.

3.5.4 SSL/TLS Options

Like the SASL parameters,
slapd.conf offers several options for
configuring settings related to SSL and
TLS.
These parameters include:

TLSCipherSuite cipher-suite-specification
TLSCertificateFile filename
TLSCertificateKeyFile filename

The TLSCipherSuite parameter allows you to specify
which ciphers the server will accept. It also specifies a preference
order for the ciphers. The value for
TLSCipherSuite should be a colon-separated list of
cipher suites. The explanation of available cipher suites is lengthy,
so I won't reproduce it; refer to the
ciphers(1) manpage distributed with OpenSSL.
Here are a few common options; the order of preference is from left
to right:

RC4:DES:EXPORT40
HIGH:MEDIUM
3DES:SHA1:+SSL2

The next two parameters,
TLSCertificateFile and
TLSCertificateKeyFile, inform
slapd of the location of the
server's certificate and the associated private key.
This will be used to implement both LDAP over SSL (LDAPS) and the
StartTLS extended operation. However, you have yet to create a
certificate for your server.

3.5.4.1 Generating the server's certificate

The
CA.pl Perl script, installed in
/usr/local/misc/ as part of the OpenSSL
installation, provides a nice wrapper around the
openssl tool and its command-line arguments. To
use this script, openssl must be located in the
current search path.

The CA.pl script greatly simplifies the creation
of server certificates. In order to create a new certificate, use the
-newcert command-line option and answer the
questions as prompted. Here's how to use
CA.pl to create a new certificate:

$ /usr/local/misc/CA.pl -newcert
Enter PEM pass phrase:test
Verifying password - Enter PEM pass phrase:test
-----
You are about to be asked to enter information that will be incorporated into your 
certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [GB]:US
State or Province Name (full name) [Berkshire]:Alabama
Locality Name (eg, city) [Newbury]:Somewhere
Organization Name (eg, company) [My Company Ltd]:PlaineJoe Dot Org
Organizational Unit Name (eg, section) [  ]:IT
Common Name (eg, your name or your server's hostname) [  ]:pogo.plainjoe.org
Email Address [  ]:jerry@plainjoe.org
Certificate (and private key) is in newreq.pem

This command creates a file named
newreq.pem that contains a password-protected private
key and a self-signed certificate. Here are the contents of
newreq.pem:

-----BEGIN RSA PRIVATE KEY-----
Proc-Type: 4,ENCRYPTED
DEK-Info: DES-EDE3-CBC,D8851189E7EA85CE
ImZpOfzqhNhNa6MRQBtYxjPbWmHw+3XxVAowO1FJyFQRQhuRDqrUia1IW7Tikb4d
rvjbv8T1+SN9vRGWBpz3nAERnS6uEnzPu201b9X413uXaF80TYYId7OUalG5mjqr
GG0oHaYwbmvAIRyhq3zhqCnBgscZ0l5DCXGTw0T1TeqaTfD8BpRE4ES+F0dlKjRf
yXuXmLrTg0C9ITokzRj4Xtu0nJfQ5LKouooeI43FHqFBFV4Jw5IIKOuAg/tkinez
VqVesaV707PLqdlYNAVx26z/nPwbbAT2JY4fqemBzjBJPDN6Tr/QncYgbMcG+H5/
7z7mBmOWq7nCpgFSwV1KgvtDIOjqZmGSpTLbZ/pY+JUT3iPsRAaL5XHDZDM6pF0l
R70ePd3Z5sUcg1TJlnuPYejyTi1OM/hoKrNnjM+4bTY8St14zAaMV15G/3GGJue0
jeJkBZba8UpQ539yPfuPINueJFG+QipDUnHWVHSWIGhqiKVZxPTZWCZrgHx7UbYw
fQVORGQ6ddu6vYNiODYXUnN3YtvD02OkbiGVl53OXlYv5hOydqdWRhA1hfR8SKAG
fnt1OV9yjC/0K2mj+nMNOu5kHMfA+Q6hw7mvWAsR/2ldX+/QTA8n1oRi7U4zySUL
iaAycSQl/yFHeHBhjOqFzKhvJU9Ux1A/lDzmFZ/vPGsSCvyv3GD1IzK1wvbUgxKE
3DzA1OuuUCl36HYTEgeFG2DqHPxzjhtqPyGgTG4xmB3dOndMys4VxeWB3Y+3vy3I
B6faH3/UKv1S6Fhj6xzxODjlLLt2zV0obi3F67QBXEvD08FCYtLIww=  =
-----END RSA PRIVATE KEY-----
-----BEGIN CERTIFICATE-----
MIIDsDCCAxmgAwIBAgIBADANBgkqhkiG9w0BAQQFADCBnTELMAkGA1UEBhMCVVMx
EDAOBgNVBAgTB0FsYWJhbWExEjAQBgNVBAcTCVNvbWV3aGVyZTEaMBgGA1UEChMR
UGxhaW5lSm9lIERvdCBPcmcxCzAJBgNVBAsTAklUMRwwGgYDVQQDExNnYXJpb24u
cGxhaW5qb2Uub3JnMSEwHwYJKoZIhvcNAQkBFhJqZXJyeUBwbGFpbmpvZS5vcmcw
HhcNMDIxMTE2MjI0MzA5WhcNMDMxMTE2MjI0MzA5WjCBnTELMAkGA1UEBhMCVVMx
EDAOBgNVBAgTB0FsYWJhbWExEjAQBgNVBAcTCVNvbWV3aGVyZTEaMBgGA1UEChMR
UGxhaW5lSm9lIERvdCBPcmcxCzAJBgNVBAsTAklUMRwwGgYDVQQDExNnYXJpb24u
cGxhaW5qb2Uub3JnMSEwHwYJKoZIhvcNAQkBFhJqZXJyeUBwbGFpbmpvZS5vcmcw
gZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALV0pZLKCwqioakJtgKr0+DScZ9h
C/nLcOxw9t6RUHlWSD9aGC9rMaMGrxG5YqI+dEuhbGWhnVo37IsMlHC+oJsXwY/2
r/RQT5dk1jyC4qt+2r4mGGC/QbCX0GRjT0gn3obB570XZ19qBCfYwIXOtYncIX0P
0fUwFVRG5frBL5QDAgMBAAGjgf0wgfowHQYDVR0OBBYEFPVRTbSjVJ4v4pOb0N0k
oJk8YZIGMIHKBgNVHSMEgcIwgb+AFPVRTbSjVJ4v4pOb0N0koJk8YZIGoYGjpIGg
MIGdMQswCQYDVQQGEwJVUzEQMA4GA1UECBMHQWxhYmFtYTESMBAGA1UEBxMJU29t
ZXdoZXJlMRowGAYDVQQKExFQbGFpbmVKb2UgRG90IE9yZzELMAkGA1UECxMCSVQx
HDAaBgNVBAMTE2dhcmlvbi5wbGFpbmpvZS5vcmcxITAfBgkqhkiG9w0BCQEWEmpl
cnJ5QHBsYWluam9lLm9yZ4IBADAMBgNVHRMEBTADAQH/MA0GCSqGSIb3DQEBBAUA
A4GBAIM+ySiITRXb/d1qcO/XUQSKdU3IXqPgS8jY3U12Bll/kCZFcZxjksg6xBib
91Y/bonSEisJG74zn/0ts3sjsr3QKZp5xFcYCyK3IYjaqnFeAOh+eUp54vLpmQZX
e4QaeTkg/8MnS3vFvWoxfo4Z1Zu/wWhp9WMRRwIVAR99Ppps
-----END CERTIFICATE-----

Notice that the CA.pl script places a private
key in the same file as the public certificate. You must remove the
password for the private key unless you always want to start the
OpenLDAP server manually. It is extremely important to protect this
key carefully. Public key cryptography is no good if the private key
is readily available to anyone.

Because this private key is password protected, it will require some
modification before integrating it into the server's
setup. The following command removes the password from the private
key and places the modified version of the key in a separate file:

$ openssl rsa -in newreq.pem -out newkey.pem
read RSA key
Enter PEM pass phrase:test
writing RSA key

The newkey.pem file can be renamed to a filename
of your choosing. Something like slapd-key.pem
would be appropriate. Make sure that the new file is safely secured
using the appropriate filesystem permissions (i.e.,
rw-------).

Finally, using your favorite text editor, remove the original private
key from newreq.pem. I'll
rename the certificate file to slapd-cert.pem
for the remaining examples in this chapter. At this point, we have
the following files:

slapd-key.pem

LDAP server's private key

slapd-cert.pem

LDAP server's public certificate

Here are the TLS configuration parameters in the context of
slapd.conf:

# /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
## TLS options for slapd 
TLSCipherSuite          HIGH
TLSCertificateFile      /etc/local/slapd-cert.pem
TLSCertificateKeyFile   /etc/local/slapd-key.pem
#######################################################
## Database sections omitted

3.5.5 More Security-Related Parameters

There are also five other security-related global options to be
covered prior to continuing on to the database section. These are:

security
require
allow
disallow
password-hash

The security parameter allows us to specify
general security strength factors. Table 3-5 lists
the options and values for the security parameter. All of these
options take an integer value specifying the strength factor; the
integer must be one of the values used for the
minssf and maxssf parameters
described in Table 3-3.

For example, we can require very strong authentication and transport
layer security when performing updates by adding the following line
to the global section of slapd.conf:

## Require strong authentication and transport layer security for update operations.
## NOTE: This is just an example and will not be added to our final slapd.conf. 
security     update_sasl=128,update_tls=128

To take full advantage of the security parameter,
you must disable simple binds and use only SASL mechanisms for
authentication. See the disallow parameter in this
section for details of how this can be done.

The require parameter differs from the
security parameter by allowing an administrator to
define general conditions that must be met to provide access to the
directory. This setting may be done globally or on a per-database
basis. The require parameter accepts a
comma-separated list of the strings described in Table 3-6.

The effect of some of the require settings can be
obtained by other means as well. For example, if anonymous users
should have no access to directory information, OpenLDAP provides
access control lists within a database that can restrict access in a
much more flexible way.

The allow (and complementary
disallow) parameters provide another means of
enabling and disabling certain features. Currently, the
allow parameter supports only two options:

none

This is the default setting.

tls_2_anon

Allows TLS to force the current session to anonymous status.

The disallow parameter, however, offers many more
options. These include:

bind_v2

Disables LDAPv2 bind requests

bind_anon

Disables anonymous binds

bind_anon_cred

Disables anonymous credentials when the DN is empty

bind_anon_dn

Disables anonymous binds when the DN is nonempty

bind_simple

Disables simple binds

bind_krbv4

Disables Kerberos 4 bind requests

tls_authc

Disables StartTLS if the client is authenticated

Finally, the
password-hash parameter defines the
default password encryption scheme used to store values in the
userPassword attribute. This setting can be
overridden on an individual attribute basis by prefixing the password
with the appropriate directive. The default encryption scheme is
{SSHA}. Other possibilities include:

{SHA}
{SMD5}
{MD5}
{CRYPT}
{CLEARTEXT}

The security parameters and examples presented here are enough for
our needs. Refer to the
openssl(1) manpage for more information on OpenSSL
tools and configuration.

After covering these final parameters, you can complete the global
section of your slapd.conf:

# /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
## TLS options for slapd 
TLSCipherSuite          HIGH
TLSCertificateFile      /etc/local/slapd-cert.pem
TLSCertificateKeyFile   /etc/local/slapd-key.pem
## Misc security settings
password-hash     {SSHA}
#######################################################
## Database sections omitted

3.5.6 Serving Up Data

Following the global section of
slapd.conf will be one or more database sections, each
defining a directory partition. A database section begins with the
database directive and continues until the next
occurrence of the database directive or the end of
the file. This parameter has several possible values:

bdb

This backend has been specifically written to take advantage of the
Berkley DB 4 database manager. This backend makes extensive use of
indexing and caching to speed up performance; it is the recommended
backend used on an OpenLDAP server.

ldbm

An ldbm database is implemented via either the GNU
Database Manager or the Sleepycat Berkeley DB software package. This
backend is the older implementation of the bdb
backend. The details of this backend are described in the
slapd-ldbm(5) manpage.

passwd

The passwd backend is a quick and dirty means of
providing a directory interface to the system
passwd(5) file. It has only one configuration
parameter: the file directive, which defines the location of the
password file (if different from /etc/passwd)
used to respond to directory queries. The details of this backend are
described in the slapd-passwd(5) manpage.

shell

The shell backend directive allows the use of
alternative (and external) databases. This directive lets you specify
external programs that are called for each of the LDAPv3 core
operations. The details of this backend are described in the
slapd-shell(5) manpage.

The first step in writing a database section is defining the type of
backend. The examples in the remainder of this book almost
exclusively use the bdb database value.

## Begin a new database section.
database     bdb

The next item is to define the directory partition's
naming context. The naming context allows slapd
to serve multiple, potentially disconnected partitions from a single
server. Each partition has a unique naming context that identifies
the root entry in the tree. The following example defines the naming
context of the database to correspond with the local domain name, a
practice recommended by RFC 2247 ("Using Domains in
LDAP/X.500 Distinguished Names"):

## Define the beginning of example database.
database     bdb
## Define the root suffix you serve.
suffix          "dc=plainjoe,dc=org"

Each LDAP directory can have a root DN (rootdn),
which is similar to the superuser account on Unix systems. When
authenticated, this DN is authorized to do whatever the user desires;
access control restrictions do not apply. For this reason, some
administrators prefer not to configure a root DN at all, or at least
remove it once the directory has been sufficiently populated to hand
over control to existing user accounts.

The naming of the root DN is arbitrary, although the
cn values of
"admin" and
"Manager" have become common
choices. The root DN also requires a corresponding
root
password (rootpw), which can be stored in clear
text or encrypted form using one of the prefixes accepted by the
password-hash parameter. OpenLDAP 2 provides the
slappasswd(8c) utility for generating
{CRYPT}, {MD5},
{SMD5}, {SSHA}, and
{SHA} passwords. Do not place the root password in
plain text regardless of what the permissions on
slapd.conf are. Even if the password is
encrypted, it is extremely important not to allow unauthorized users
to view slapd.conf.

## Define a root DN for superuser privileges.
rootdn      "cn=Manager,dc=plainjoe,dc=org"
## Define the password used with rootdn. This is a salted secure hash of the phrase 
## "secret."
rootpw          {SSHA}2aksIaicAvwc+DhCrXUFlhgWsbBJPLxy

You aren't required to define a root password. If no
rootpw directive is present, the
rootdn is authenticated using the
server's default authentication method (e.g., SASL).
OpenLDAP 2.1 uses a DN representation of an SASL identify. The
general syntax is:

uid=name,[cn=realm],cn=SASL Mechanism,cn=auth

The cn=realm portion on
the DN is omitted if the mechanism does not support the concept of
realms or if the one specified is the default realm for the server.
If your OpenLDAP server existed within the PLAINJOE.ORG realm and you
chose to use a Kerberos 5 principal named
ldapadmin@PLAINJOE.ORG as the
rootdn, it would appear as:

rootdn "uid=ldapadmin,cn=gssapi,cn=auth"

The next two parameters should be left to their default values:

lastmod

This parameter determines whether slapd will
maintain the operational attributes modifiersName,
modifyTimestamp, creatorsName,
and createTimestamp for all entries defined in
core.schema. The default behavior is to maintain
the information for all entries. The option accepts a value of
off or on. Disabling this
parameter means that client-side caching of information is not
possible because no marker exists to test whether an entry has been
updated.

readonly

The readonly parameter allows a server to disable
all update access, including update access by the
rootdn. Directory data is writable by default,
assuming that there are no access control lists in place. Under some
circumstances, such as backing up the data, you may want to prevent
the directory from accepting modifications. Like the
lastmod parameter, the readonly
options also accept the values off or
on.

3.5.6.1 bdb backend-specific parameters

The
database parameters discussed up to this point are applicable to
OpenLDAP's various database backends in general.
This section examines several parameters that are used only by the
bdb database.

The directory and
mode parameters define the physical location and
filesystem permissions of the created database files. These
parameters are necessary because, when using an
ldbm backend, slapd manages
the data store itself. In the following configuration file, the
directory and mode parameters
tell slapd and the other LDAP tools how to
locate and store the database files for this partition. The files are
stored in the directory /var/ldap/plainjoe.org/
and created with read/write permission (0600) for the owner only (the
account under which the slapd daemon runs).

## Define the beginning of example database.
database        bdb
## Define the root suffix you serve.
suffix          "dc=plainjoe,dc=org"
## Define a root DN for superuser privileges.
rootdn          "cn=Manager,dc=plainjoe,dc=org"
## Define the password used with rootdn. This is the Base64-encoded MD5 hash of
## "secret."
rootpw          {SSHA}2aksIaicAvwc+DhCrXUFlhgWsbBJPLxy
## Directory containing the database files
directory       /var/ldap/plainjoe.org
## Files should be created rw for the owner **only**.
mode            0600

It's a good idea to maintain tight security on the physical database files even if the directory server is a closed box (i.e., no users can log into the server and run a shell). It is easier to manage the server when the only way to access the backend storage is via slapd itself.

The index parameter specifies the
attributes on which
slapd should maintain indexes. These
indexes are used to optimize searches, similar to the indexes used by
a relational database management system. slapd
supports four types of indexes. However, not all attributes support
all four index types. Each index type corresponds to one of the
matching rules defined in the directory schema.

approx (approximate)

Indexes the information for an approximate, or phonetic, match of an
attribute's value.

eq (equality)

Indexes the information necessary to perform an exact match of an
attribute value. The match may be case-sensitive or
whitespace-sensitive, depending on the matching rules defined in the
attribute's syntax.

pres (presence)

Indexes the information necessary to determine if an attribute has
any value at all. If an attribute does not possess a value, then the
attribute is not present in the directory entry.

sub (substring)

Indexes the information necessary to perform a simple substring match
on attribute values.

There can be multiple index definitions for the same
databaseand even multiple attributes or index typeson
the same line. Each attribute or index type should be separated by a
comma; use whitespace to separate the attribute list from the list of
index types. Here's how to define an equality and
presence index on the cn attribute:

## Maintain presence and equality searches on the cn and uid attributes.
index          cn          pres,eq

Which indexes should be maintained depends on the client applications
that the server will support and the types of searches that those
applications will perform. The best way to determine which indexes to
maintain is to include the search processing debug output
(loglevel 32) in the server's
log file.

OpenLDAP 2 requires an equality index on the objectClass attribute for performance reasons. ## Must be maintained for performance reasons index objectClass eq

I cannot stress the use of proper indexes enough.
Misconfigured indexes are probably the
number one reason administrators experience
performance problems
with OpenLDAP servers. Many of the applications and scenarios
presented later in the book focus on functionality and not
necessarily performance. This should not be construed as lessening
the importance of properly indexing the attributes used freqently in
searches. It simply means that I assume you have learned your lesson
about indexes here and can fill in the blanks later.

While an indexed database offers many performance benefits over flat
text files, these benefits can be increased by caching entries and
indexes in memory to prevent disk I/O in response to common searches.
The cachesize parameter allows
you to tune caching according to the needs of the directory.

The cachesize parameter defines the number of
entries that should be cached in memory. The default is to cache
1,000 entries. If your total directory size is less than 1,000
entries, there is no need to modify this setting. If, however, your
directory contains 1,000,000 entries, a cache size of 100,000 would
not be unusual.

When setting parameters to integer values in slapd.conf, make sure to remove commas from the number. For example, 100,000 should be entered as 100000.

Here is what the database
section looks like so far:

## Define the beginning of example database.
database        bdb
## Define the root suffix you serve.
suffix          "dc=plainjoe,dc=org"
## Define a root DN for superuser privileges. This is the Base64-encoded MD5 hash of
## "secret."
rootdn          "cn=Manager,dc=plainjoe,dc=org"
## Define the password used with rootdn.
rootpw          {SSHA}2aksIaicAvwc+DhCrXUFlhgWsbBJPLxy
## Directory containing the database files
directory       /var/ldap/plainjoe.org
## Files should be created rw for the owner **only**.
mode            0600
## Indexes to maintain
index           objectClass     eq
index           cn              pres,eq
## db tuning parameters; cache 2,000 entries in memory
cachesize       2000