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.
|
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
|
There are several schema files included with a default OpenLDAP 2.1 installation:
A schema for storing Corba objects in an LDAP directory, as described in RFC 2714.
OpenLDAP's required core schema. This schema defines basic LDAPv3 attributes and objects described in RFCs 2251-2256.
A schema for supporting the COSINE and X.500 directory pilots. Based on RFC 1274.
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.
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.
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+.
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).
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.
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:
Connection management
Search filter processing
Statistics for connection, operations, and results
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.
|
The remaining two parameters introduced in this section can be summed up in a sentence or two:
This parameter specifies the absolute location of a file that will contain the process ID of the currently running master slapd process.
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.
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 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.
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.
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 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:
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.
Like the SASL parameters, slapd.conf offers several options for configuring settings related to SSL and TLS. These parameters include:
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:
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.
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.
Crypto 101In my own work configuring OpenSSL and the services that use these libraries, I have found the documentation a little sparse. If you are interested in learning more about SSL, cryptography, or digital certificates, the following sources are a good place to start:
|
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:
LDAP server's private key
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
There are also five other security-related global options to be covered prior to continuing on to the database section. These are:
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.
Value |
Description |
---|---|
sasl |
Defines the SASL security strength factor. |
ssf |
Defines the overall security strength factor. |
tls |
Defines the security strength factor to the SSL/TLS security layer. |
transport |
Defines the security strength provided by the underlying transport layer. Eventually, this option will be used to choose between multiple secure transport layer protocols, such as TLS and IPSEC. |
update_sasl update_ssf update_tls update_transport |
Define the security strength of the various layers when performing update operations on the directory. |
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.
Value |
Description |
---|---|
none |
Clears all requirements. |
authc |
Requires client authentication prior to directory access (i.e., no anonymous access). |
bind |
Requires the client to issue a bind request, possibly an anonymous bind, prior to directory operations. |
LDAPv3 |
Requires the client to use Version 3 of the LDAP protocol for directory access. By default, OpenLDAP supports both LDAPv2 and v3 clients. |
SASL strong |
Require the client to use strong (SASL) authentication in order to be granted access to the directory. Currently, these two options are identical. |
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:
This is the default setting.
Allows TLS to force the current session to anonymous status.
The disallow parameter, however, offers many more options. These include:
Disables LDAPv2 bind requests
Disables anonymous binds
Disables anonymous credentials when the DN is empty
Disables anonymous binds when the DN is nonempty
Disables simple binds
Disables Kerberos 4 bind requests
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:
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
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:
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.
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.
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.
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:
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.
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.
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
|
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.
Indexes the information for an approximate, or phonetic, match of an attribute's value.
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.
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.
Indexes the information necessary to perform a simple substring match on attribute values.
There can be multiple index definitions for the same database?and even multiple attributes or index types?on 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.
|
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.
|
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