6. The slapd Configuration File
This chapter describes configuring slapd(8) via the slapd.conf(5) configuration file. slapd.conf(5) has been deprecated and should only be used if your site requires one of the backends that hasn't yet been updated to work with the newer slapd-config(5) system. Configuring slapd(8) via slapd-config(5) is described in the previous chapter.
The slapd.conf(5) file is normally installed in the /usr/local/etc/openldap directory. An alternate configuration file location can be specified via a command-line option to slapd(8).
6.1. Configuration File Format
The slapd.conf(5) file consists of three types of configuration information: global, backend specific, and database specific. Global information is specified first, followed by information associated with a particular backend type, which is then followed by information associated with a particular database instance. Global directives can be overridden in backend and/or database directives, and backend directives can be overridden by database directives.
Blank lines and comment lines beginning with a '#' character are ignored. If a line begins with whitespace, it is considered a continuation of the previous line (even if the previous line is a comment).
The general format of slapd.conf is as follows:
# global configuration directives
<global config directives>
# backend definition
backend <typeA>
<backend-specific directives>
# first database definition & config directives
database <typeA>
<database-specific directives>
# second database definition & config directives
database <typeB>
<database-specific directives>
# second database definition & config directives
database <typeA>
<database-specific directives>
# subsequent backend & database definitions & config directives
...
A configuration directive may take arguments. If so, they are separated by whitespace. If an argument contains whitespace, the argument should be enclosed in double quotes "like this". If an argument contains a double quote or a backslash character `\', the character should be preceded by a backslash character `\'.
The distribution contains an example configuration file that will be installed in the /usr/local/etc/openldap directory. A number of files containing schema definitions (attribute types and object classes) are also provided in the /usr/local/etc/openldap/schema directory.
6.2. Configuration File Directives
This section details commonly used configuration directives. For a complete list, see the slapd.conf(5) manual page. This section separates the configuration file directives into global, backend-specific and data-specific categories, describing each directive and its default value (if any), and giving an example of its use.
6.2.1. Global Directives
Directives described in this section apply to all backends and databases unless specifically overridden in a backend or database definition. Arguments that should be replaced by actual text are shown in brackets <>.
6.2.1.1. access to <what> [ by <who> [<accesslevel>] [<control>] ]+
This directive grants access (specified by <accesslevel>) to a set of entries and/or attributes (specified by <what>) by one or more requestors (specified by <who>). See the Access Control section of this guide for basic usage.
Note: If no access directives are specified, the default access control policy, access to * by * read, allows all both authenticated and anonymous users read access.
6.2.1.2. attributetype <RFC4512 Attribute Type Description>
This directive defines an attribute type. Please see the Schema Specification chapter for information regarding how to use this directive.
6.2.1.3. idletimeout <integer>
Specify the number of seconds to wait before forcibly closing an idle client connection. An idletimeout of 0, the default, disables this feature.
6.2.1.4. include <filename>
This directive specifies that slapd should read additional configuration information from the given file before continuing with the next line of the current file. The included file should follow the normal slapd config file format. The file is commonly used to include files containing schema specifications.
Note: You should be careful when using this directive - there is no small limit on the number of nested include directives, and no loop detection is done.
6.2.1.5. loglevel <level>
This directive specifies the level at which debugging statements and operation statistics should be syslogged (currently logged to the syslogd(8) LOG_LOCAL4 facility). You must have configured OpenLDAP --enable-debug (the default) for this to work (except for the two statistics levels, which are always enabled). Log levels may be specified as integers or by keyword. Multiple log levels may be used and the levels are additive. To display what numbers correspond to what kind of debugging, invoke slapd with -d? or consult the table below. The possible values for <integer> are:
| Level | Keyword | Description |
| -1 | any | enable all debugging |
| 0 | no debugging | |
| 1 | (0x1 trace) | trace function calls |
| 2 | (0x2 packets) | debug packet handling |
| 4 | (0x4 args) | heavy trace debugging |
| 8 | (0x8 conns) | connection management |
| 16 | (0x10 BER) | print out packets sent and received |
| 32 | (0x20 filter) | search filter processing |
| 64 | (0x40 config) | configuration processing |
| 128 | (0x80 ACL) | access control list processing |
| 256 | (0x100 stats) | stats log connections/operations/results |
| 512 | (0x200 stats2) | stats log entries sent |
| 1024 | (0x400 shell) | print communication with shell backends |
| 2048 | (0x800 parse) | print entry parsing debugging |
| 16384 | (0x4000 sync) | syncrepl consumer processing |
| 32768 | (0x8000 none) | only messages that get logged whatever log level is set |
The desired log level can be input as a single integer that combines the (ORed) desired levels, both in decimal or in hexadecimal notation, as a list of integers (that are ORed internally), or as a list of the names that are shown between brackets, such that
loglevel 129
loglevel 0x81
loglevel 128 1
loglevel 0x80 0x1
loglevel acl trace
are equivalent.
Examples:
loglevel -1
This will cause lots and lots of debugging information to be logged.
loglevel conns filter
Just log the connection and search filter processing.
loglevel none
Log those messages that are logged regardless of the configured loglevel. This differs from setting the log level to 0, when no logging occurs. At least the None level is required to have high priority messages logged.
Default:
loglevel stats
Basic stats logging is configured by default. However, if no loglevel is defined, no logging occurs (equivalent to a 0 level).
6.2.1.6. objectclass <RFC4512 Object Class Description>
This directive defines an object class. Please see the Schema Specification chapter for information regarding how to use this directive.
6.2.1.7. referral <URI>
This directive specifies the referral to pass back when slapd cannot find a local database to handle a request.
Example:
referral ldap://root.openldap.org
This will refer non-local queries to the global root LDAP server at the OpenLDAP Project. Smart LDAP clients can re-ask their query at that server, but note that most of these clients are only going to know how to handle simple LDAP URLs that contain a host part and optionally a distinguished name part.
6.2.1.8. sizelimit <integer>
This directive specifies the maximum number of entries to return from a search operation.
Default:
sizelimit 500
See the Limits section of this guide and slapd.conf(5) for more details.
6.2.1.9. timelimit <integer>
This directive specifies the maximum number of seconds (in real time) slapd will spend answering a search request. If a request is not finished in this time, a result indicating an exceeded timelimit will be returned.
Default:
timelimit 3600
See the Limits section of this guide and slapd.conf(5) for more details.
6.2.2. General Backend Directives
Directives in this section apply only to the backend in which they are defined. They are supported by every type of backend. Backend directives apply to all databases instances of the same type and, depending on the directive, may be overridden by database directives.
6.2.2.1. backend <type>
This directive marks the beginning of a backend declaration. <type> should be one of the supported backend types listed in Table 6.2.
| Types | Description |
| bdb | Berkeley DB transactional backend (deprecated) |
| dnssrv | DNS SRV backend |
| hdb | Hierarchical variant of bdb backend (deprecated) |
| ldap | Lightweight Directory Access Protocol (Proxy) backend |
| mdb | Memory-Mapped DB backend |
| meta | Meta Directory backend |
| monitor | Monitor backend |
| passwd | Provides read-only access to passwd(5) |
| perl | Perl Programmable backend |
| shell | Shell (extern program) backend |
| sql | SQL Programmable backend |
Example:
backend mdb
This marks the beginning of a new
6.2.3. General Database Directives
Directives in this section apply only to the database in which they are defined. They are supported by every type of database.
6.2.3.1. database <type>
This directive marks the beginning of a database instance declaration. <type> should be one of the supported backend types listed in Table 6.2.
Example:
database mdb
This marks the beginning of a new
6.2.3.2. limits <selector> <limit> [<limit> [...]]
Specify time and size limits based on the operation's initiator or base DN.
See the Limits section of this guide and slapd.conf(5) for more details.
6.2.3.3. readonly { on | off }
This directive puts the database into "read-only" mode. Any attempts to modify the database will return an "unwilling to perform" error. If set on a consumer, modifications sent by syncrepl will still occur.
Default:
readonly off
6.2.3.4. rootdn <DN>
This directive specifies the DN that is not subject to access control or administrative limit restrictions for operations on this database. The DN need not refer to an entry in this database or even in the directory. The DN may refer to a SASL identity.
Entry-based Example:
rootdn "cn=Manager,dc=example,dc=com"
SASL-based Example:
rootdn "uid=root,cn=example.com,cn=digest-md5,cn=auth"
See the SASL Authentication section for information on SASL authentication identities.
6.2.3.5. rootpw <password>
This directive can be used to specifies a password for the DN for the rootdn (when the rootdn is set to a DN within the database).
Example:
rootpw secret
It is also permissible to provide hash of the password in RFC2307 form. slappasswd(8) may be used to generate the password hash.
Example:
rootpw {SSHA}ZKKuqbEKJfKSXhUbHG3fG8MDn9j1v4QN
The hash was generated using the command slappasswd -s secret.
6.2.3.6. suffix <dn suffix>
This directive specifies the DN suffix of queries that will be passed to this backend database. Multiple suffix lines can be given, and at least one is required for each database definition.
Example:
suffix "dc=example,dc=com"
Queries with a DN ending in "dc=example,dc=com" will be passed to this backend.
Note: When the backend to pass a query to is selected, slapd looks at the suffix line(s) in each database definition in the order they appear in the file. Thus, if one database suffix is a prefix of another, it must appear after it in the config file.
6.2.3.7. syncrepl
syncrepl rid=<replica ID>
provider=ldap[s]://<hostname>[:port]
searchbase=<base DN>
[type=refreshOnly|refreshAndPersist]
[interval=dd:hh:mm:ss]
[retry=[<retry interval> <# of retries>]+]
[filter=<filter str>]
[scope=sub|one|base]
[attrs=<attr list>]
[exattrs=<attr list>]
[attrsonly]
[sizelimit=<limit>]
[timelimit=<limit>]
[schemachecking=on|off]
[network-timeout=<seconds>]
[timeout=<seconds>]
[bindmethod=simple|sasl]
[binddn=<DN>]
[saslmech=<mech>]
[authcid=<identity>]
[authzid=<identity>]
[credentials=<passwd>]
[realm=<realm>]
[secprops=<properties>]
[keepalive=<idle>:<probes>:<interval>]
[starttls=yes|critical]
[tls_cert=<file>]
[tls_key=<file>]
[tls_cacert=<file>]
[tls_cacertdir=<path>]
[tls_reqcert=never|allow|try|demand]
[tls_cipher_suite=<ciphers>]
[tls_crlcheck=none|peer|all]
[tls_protocol_min=<major>[.<minor>]]
[suffixmassage=<real DN>]
[logbase=<base DN>]
[logfilter=<filter str>]
[syncdata=default|accesslog|changelog]
This directive specifies the current database as a consumer of the provider content by establishing the current slapd(8) as a replication consumer site running a syncrepl replication engine. The provider database is located at the replication provider site specified by the provider parameter. The consumer database is kept up-to-date with the provider content using the LDAP Content Synchronization protocol. See RFC4533 for more information on the protocol.
The rid parameter is used for identification of the current syncrepl directive within the replication consumer server, where <replica ID> uniquely identifies the syncrepl specification described by the current syncrepl directive. <replica ID> is non-negative and is no more than three decimal digits in length.
The provider parameter specifies the replication provider site containing the provider content as an LDAP URI. The provider parameter specifies a scheme, a host and optionally a port where the provider slapd instance can be found. Either a domain name or IP address may be used for <hostname>. Examples are ldap://provider.example.com:389 or ldaps://192.168.1.1:636. If <port> is not given, the standard LDAP port number (389 or 636) is used. Note that the syncrepl uses a consumer-initiated protocol, and hence its specification is located on the consumer.
The content of the syncrepl consumer is defined using a search specification as its result set. The consumer slapd will send search requests to the provider slapd according to the search specification. The search specification includes searchbase, scope, filter, attrs, exattrs, attrsonly, sizelimit, and timelimit parameters as in the normal search specification. The searchbase parameter has no default value and must always be specified. The scope defaults to sub, the filter defaults to (objectclass=*), attrs defaults to "*,+" to replicate all user and operational attributes, and attrsonly is unset by default. Both sizelimit and timelimit default to "unlimited", and only positive integers or "unlimited" may be specified. The exattrs option may also be used to specify attributes that should be omitted from incoming entries.
The
If an error occurs during replication, the consumer will attempt to reconnect according to the retry parameter which is a list of the <retry interval> and <# of retries> pairs. For example, retry="60 10 300 3" lets the consumer retry every 60 seconds for the first 10 times and then retry every 300 seconds for the next three times before stop retrying. + in <# of retries> means indefinite number of retries until success.
The schema checking can be enforced at the LDAP Sync consumer site by turning on the schemachecking parameter. If it is turned on, every replicated entry will be checked for its schema as the entry is stored on the consumer. Every entry in the consumer should contain those attributes required by the schema definition. If it is turned off, entries will be stored without checking schema conformance. The default is off.
The network-timeout parameter sets how long the consumer will wait to establish a network connection to the provider. Once a connection is established, the timeout parameter determines how long the consumer will wait for the initial Bind request to complete. The defaults for these parameters come from ldap.conf(5).
The binddn parameter gives the DN to bind as for the syncrepl searches to the provider slapd. It should be a DN which has read access to the replication content in the provider database.
The bindmethod is simple or sasl, depending on whether simple password-based authentication or
Simple authentication should not be used unless adequate data integrity and confidentiality protections are in place (e.g. TLS or IPsec). Simple authentication requires specification of binddn and credentials parameters.
SASL authentication is generally recommended. SASL authentication requires specification of a mechanism using the saslmech parameter. Depending on the mechanism, an authentication identity and/or credentials can be specified using authcid and credentials, respectively. The authzid parameter may be used to specify an authorization identity.
The realm parameter specifies a realm which a certain mechanisms authenticate the identity within. The secprops parameter specifies Cyrus SASL security properties.
The keepalive parameter sets the values of idle, probes, and interval used to check whether a socket is alive; idle is the number of seconds a connection needs to remain idle before TCP starts sending keepalive probes; probes is the maximum number of keepalive probes TCP should send before dropping the connection; interval is interval in seconds between individual keepalive probes. Only some systems support the customization of these values; the keepalive parameter is ignored otherwise, and system-wide settings are used. For example, keepalive="240:10:30" will send a keepalive probe 10 times, every 30 seconds, after 240 seconds of idle activity. If no response to the probes is received, the connection will be dropped.
The starttls parameter specifies use of the StartTLS extended operation to establish a TLS session before authenticating to the provider. If the critical argument is supplied, the session will be aborted if the StartTLS request fails. Otherwise the syncrepl session continues without TLS. The tls_reqcert setting defaults to "demand" and the other TLS settings default to the same as the main slapd TLS settings.
The suffixmassage parameter allows the consumer to pull entries from a remote directory whose DN suffix differs from the local directory. The portion of the remote entries' DNs that matches the searchbase will be replaced with the suffixmassage DN.
Rather than replicating whole entries, the consumer can query logs of data modifications. This mode of operation is referred to as delta syncrepl. In addition to the above parameters, the logbase and logfilter parameters must be set appropriately for the log that will be used. The syncdata parameter must be set to either "accesslog" if the log conforms to the slapo-accesslog(5) log format, or "changelog" if the log conforms to the obsolete changelog format. If the syncdata parameter is omitted or set to "default" then the log parameters are ignored.
The syncrepl replication mechanism is supported by the bdb, hdb, and mdb backends.
See the LDAP Sync Replication chapter of this guide for more information on how to use this directive.
6.2.3.8. updateref <URL>
This directive is only applicable in a replica (or shadow) slapd(8) instance. It specifies the URL to return to clients which submit update requests upon the replica. If specified multiple times, each
Example:
updateref ldap://provider.example.net
6.2.4. BDB and HDB Database Directives
Directives in this category only apply to both the
6.2.4.1. directory <directory>
This directive specifies the directory where the BDB files containing the database and associated indices live.
Default:
directory /usr/local/var/openldap-data
6.3. Configuration File Example
The following is an example configuration file, interspersed with explanatory text. It defines two databases to handle different parts of the
1. # example config file - global configuration section 2. include /usr/local/etc/schema/core.schema 3. referral ldap://root.openldap.org 4. access to * by * read
Line 1 is a comment. Line 2 includes another config file which contains core schema definitions. The referral directive on line 3 means that queries not local to one of the databases defined below will be referred to the LDAP server running on the standard port (389) at the host root.openldap.org.
Line 4 is a global access control. It applies to all entries (after any applicable database-specific access controls).
The next section of the configuration file defines a BDB backend that will handle queries for things in the "dc=example,dc=com" portion of the tree. The database is to be replicated to two replica slapds, one on truelies, the other on judgmentday. Indices are to be maintained for several attributes, and the userPassword attribute is to be protected from unauthorized access.
5. # BDB definition for the example.com 6. database bdb 7. suffix "dc=example,dc=com" 8. directory /usr/local/var/openldap-data 9. rootdn "cn=Manager,dc=example,dc=com" 10. rootpw secret 11. # indexed attribute definitions 12. index uid pres,eq 13. index cn,sn pres,eq,approx,sub 14. index objectClass eq 15. # database access control definitions 16. access to attrs=userPassword 17. by self write 18. by anonymous auth 19. by dn.base="cn=Admin,dc=example,dc=com" write 20. by * none 21. access to * 22. by self write 23. by dn.base="cn=Admin,dc=example,dc=com" write 24. by * read
Line 5 is a comment. The start of the database definition is marked by the database keyword on line 6. Line 7 specifies the DN suffix for queries to pass to this database. Line 8 specifies the directory in which the database files will live.
Lines 9 and 10 identify the database super-user entry and associated password. This entry is not subject to access control or size or time limit restrictions.
Lines 12 through 14 indicate the indices to maintain for various attributes.
Lines 16 through 24 specify access control for entries in this database. For all applicable entries, the userPassword attribute is writable by the entry itself and by the "admin" entry. It may be used for authentication/authorization purposes, but is otherwise not readable. All other attributes are writable by the entry and the "admin" entry, but may be read by all users (authenticated or not).
The next section of the example configuration file defines another BDB database. This one handles queries involving the dc=example,dc=net subtree but is managed by the same entity as the first database. Note that without line 39, the read access would be allowed due to the global access rule at line 4.
33. # BDB definition for example.net 34. database bdb 35. suffix "dc=example,dc=net" 36. directory /usr/local/var/openldap-data-net 37. rootdn "cn=Manager,dc=example,dc=com" 38. index objectClass eq 39. access to * by users read