The slapd.conf file consists of a series of global configuration options that apply to slapd as a whole (including all backends), followed by zero or more database backend definitions that contain information specific to a backend instance. The configuration options are case-insensitive; their value, on a case by case basis, may be case-sensitive.
The general format of slapd.conf is as follows:
# comment - these options apply to every database
<global configuration options>
# first database definition & configuration options
database <backend 1 type>
<configuration options specific to backend 1>
# subsequent database definitions & configuration options
...
As many backend-specific sections as desired may be included. Global options can be overridden in a backend (for options that appear more than once, the last appearance in the slapd.conf file is used).
If a line begins with white space, it is considered a continuation of the previous line. No physical line should be over 2000 bytes long.
Blank lines and comment lines beginning with a `#' character are ignored. Note: continuation lines are unwrapped before comment processing is applied.
Arguments on configuration lines are separated by white space. If an argument contains white space, the argument should be enclosed in double quotes. If an argument contains a double quote (`"') or a backslash character (`\'), the character should be preceded by a backslash character.
The specific configuration options available are discussed below in the Global Configuration Options, General Backend Options, and General Database Options. Backend-specific options are discussed in the slapd-<backend>(5) manual pages. Refer to the "OpenLDAP Administrator's Guide" for more details on the slapd configuration file.
An attribute description with a tagging option is a subtype of that attribute description without the option. Except for that, options defined this way have no special semantics. Prefixes defined this way work like the `lang-' options: They define a prefix for tagging options starting with the prefix. That is, if you define the prefix `x-foo-', you can use the option `x-foo-bar'. Furthermore, in a search or compare, a prefix or range name (with a trailing `-') matches all options starting with that name, as well as the option with the range name sans the trailing `-'. That is, `x-foo-bar-' matches `x-foo-bar' and `x-foo-bar-baz'.
RFC 4520 reserves options beginning with `x-' for private experiments. Other options should be registered with IANA, see RFC 4520 section 3.5. OpenLDAP also has the `binary' option built in, but this is a transfer option, not a tagging option.
<dnstyle>:={exact|onelevel|children|subtree|regex}
Multiple authz-regexp options can be given in the configuration file to allow for multiple matching and replacement patterns. The matching patterns are checked in the order they appear in the file, stopping at the first successful match.
Note: Indexing support depends on the particular backend in use. Also, changing these settings will generally require deleting any indices that depend on these parameters and recreating them with slapindex(8).
loglevel 129
loglevel 0x81
loglevel 128 1
loglevel 0x80 0x1
loglevel acl trace
are equivalent. The keyword any can be used as a shortcut to enable logging at all levels (equivalent to -1). The keyword none, or the equivalent integer representation, causes those messages that are logged regardless of the configured loglevel to be logged. In fact, if loglevel is set to 0, no logging occurs, so at least the none level is required to have high priority messages logged.
The loglevel defaults to stats. This level should usually also be included when using other loglevels, to help analyze the logs.
{SHA} and {SSHA} use the SHA-1 algorithm (FIPS 160-1), the latter with a seed.
{MD5} and {SMD5} use the MD5 algorithm (RFC 1321), the latter with a seed.
{CRYPT} uses the crypt(3).
{CLEARTEXT} indicates that the new password should be added to userPassword as clear text.
Note that this option does not alter the normal user applications handling of userPassword during LDAP Add, Modify, or other LDAP operations.
This string needs to be in sprintf(3) format and may include one (and only one) %s conversion. This conversion will be substituted with a string of random characters from [A-Za-z0-9./]. For example, "%.2s" provides a two character salt and "$1$%.8s" tells some versions of crypt(3) to use an MD5 algorithm and provides 8 random characters of salt. The default is "%s", which provides 31 characters of salt.
The root DSE is an entry with information about the server and its
capabilities, in operational attributes.
It has the empty DN, and can be read with e.g.:
ldapsearch -x -b "" -s base "+"
See RFC 4512 section 5.1 for details.
serverID 1
To check what ciphers a given spec selects in OpenSSL, use:
openssl ciphers -v <cipher-suite-spec>
With GNUtls the available specs can be found in the manual page of gnutls-cli(1) (see the description of the option --priority).
In older versions of GNUtls, where gnutls-cli does not support the option --priority, you can obtain the --- more limited --- list of ciphers by calling:
gnutls-cli -l
Note that a valid client certificate is required in order to use the SASL EXTERNAL authentication mechanism with a TLS session. As such, a non-default TLSVerifyClient setting must be chosen to enable SASL EXTERNAL authentication.
LDAP operations, even subtree searches, normally access only one database. That can be changed by gluing databases together with the subordinate keyword. Access controls and some overlays can also involve multiple databases.
The currently supported limits are size and time.
The syntax for time limits is time[.{soft|hard}]=<integer>, where integer is the number of seconds slapd will spend answering a search request. If no time limit is explicitly requested by the client, the soft limit is used; if the requested time limit exceeds the hard limit, the value of the limit is used instead. If the hard limit is set to the keyword soft, the soft limit is used in either case; if it is set to the keyword unlimited, no hard limit is enforced. Explicit requests for time limits smaller or equal to the hard limit are honored. If no limit specifier is set, the value is assigned to the soft limit, and the hard limit is set to soft, to preserve the original behavior.
The syntax for size limits is size[.{soft|hard|unchecked}]=<integer>, where integer is the maximum number of entries slapd will return answering a search request. If no size limit is explicitly requested by the client, the soft limit is used; if the requested size limit exceeds the hard limit, the value of the limit is used instead. If the hard limit is set to the keyword soft, the soft limit is used in either case; if it is set to the keyword unlimited, no hard limit is enforced. Explicit requests for size limits smaller or equal to the hard limit are honored. The unchecked specifier sets a limit on the number of candidates a search request is allowed to examine. The rationale behind it is that searches for non-properly indexed attributes may result in large sets of candidates, which must be examined by slapd(8) to determine whether they match the search filter or not. The unchecked limit provides a means to drop such operations before they are even started. If the selected candidates exceed the unchecked limit, the search will abort with Unwilling to perform. If it is set to the keyword unlimited, no limit is applied (the default). If it is set to disabled, the search is not even performed; this can be used to disallow searches for a specific set of users. If no limit specifier is set, the value is assigned to the soft limit, and the hard limit is set to soft, to preserve the original behavior.
In case of no match, the global limits are used. The default values are the same as for sizelimit and timelimit; no limit is set on unchecked.
If pagedResults control is requested, the hard size limit is used by default, because the request of a specific page size is considered an explicit request for a limitation on the number of entries to be returned. However, the size limit applies to the total count of entries returned within the search, and not to a single page. Additional size limits may be enforced; the syntax is size.pr={<integer>|noEstimate|unlimited}, where integer is the max page size if no explicit limit is set; the keyword noEstimate inhibits the server from returning an estimate of the total number of entries that might be returned (note: the current implementation does not return any estimate). The keyword unlimited indicates that no limit is applied to the pagedResults control page size. The syntax size.prtotal={<integer>|unlimited|disabled} allows to set a limit on the total number of entries that a pagedResults control allows to return. By default it is set to the hard limit. When set, integer is the max number of entries that the whole search with pagedResults control can return. Use unlimited to allow unlimited number of entries to be returned, e.g. to allow the use of the pagedResults control as a means to circumvent size limitations on regular searches; the keyword disabled disables the control, i.e. no paged results can be returned. Note that the total number of entries returned when the pagedResults control is requested cannot exceed the hard size limit of regular searches unless extended by the prtotal switch.
The limits statement is typically used to let an unlimited number of entries be returned by searches performed with the identity used by the consumer for synchronization purposes by means of the RFC 4533 LDAP Content Synchronization protocol (see syncrepl for details).
If the suffix of one database is "inside" that of another, the database with the inner suffix must come first in the configuration file. You may also want to glue such databases together with the subordinate keyword.
If the optional advertise flag is supplied, the naming context of this database is advertised in the root DSE. The default is to hide this database context, so that only the superior context is visible.
If the slap tools slapcat(8), slapadd(8), or slapindex(8) are used on the superior database, any glued subordinates that support these tools are opened as well.
Databases that are glued together should usually be configured with the same indices (assuming they support indexing), even for attributes that only exist in some of these databases. In general, all of the glued databases should be configured as similarly as possible, since the intent is to provide the appearance of a single directory.
Note that the subordinate functionality is implemented internally by the glue overlay and as such its behavior will interact with other overlays in use. By default, the glue overlay is automatically configured as the last overlay on the superior backend. Its position on the backend can be explicitly configured by setting an overlay glue directive at the desired position. This explicit configuration is necessary e.g. when using the syncprov overlay, which needs to follow glue in order to work over all of the glued databases. E.g.
database bdb
suffix dc=example,dc=com
...
overlay glue
overlay syncprov
rid identifies the current syncrepl directive within the replication consumer site. It is a non-negative integer not greater than 999 (limited to three decimal digits).
provider specifies the replication provider site containing the master content as an LDAP URI. If <port> is not given, the standard LDAP port number (389 or 636) is used.
The content of the syncrepl replica 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, attrsonly, sizelimit, and timelimit parameters as in the normal search specification. The scope defaults to sub, the filter defaults to (objectclass=*), while there is no default searchbase. The attrs list defaults to "*,+" to return all user and operational attributes, and attrsonly is unset by default. The sizelimit and timelimit only accept "unlimited" and positive integers, and both default to "unlimited". The sizelimit and timelimit parameters define a consumer requested limitation on the number of entries that can be returned by the LDAP Content Synchronization operation; as such, it is intended to implement partial replication based on the size of the replicated database and on the time required by the synchronization. Note, however, that any provider-side limits for the replication identity will be enforced by the provider regardless of the limits requested by the LDAP Content Synchronization operation, much like for any other search operation.
The LDAP Content Synchronization protocol has two operation types. In the refreshOnly operation, the next synchronization search operation is periodically rescheduled at an interval time (specified by interval parameter; 1 day by default) after each synchronization operation finishes. In the refreshAndPersist operation, a synchronization search remains persistent in the provider slapd. Further updates to the master replica will generate searchResultEntry to the consumer slapd as the search responses to the persistent synchronization search.
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 3 times before stop retrying. The `+' in <# of retries> means indefinite number of retries until success. If no retry was specified, by default syncrepl retries every hour forever.
The schema checking can be enforced at the LDAP Sync consumer site by turning on the schemachecking parameter. The default is off. Schema checking on means that replicated entries must have a structural objectClass, must obey to objectClass requirements in terms of required/allowed attributes, and that naming attributes and distinguished values must be present. As a consequence, schema checking should be off when partial replication is used.
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).
A bindmethod of simple requires the options binddn and credentials and should only be used when adequate security services (e.g. TLS or IPSEC) are in place. REMEMBER: simple bind credentials must be in cleartext! A bindmethod of sasl requires the option saslmech. Depending on the mechanism, an authentication identity and/or credentials can be specified using authcid and credentials. The authzid parameter may be used to specify an authorization identity. Specific security properties (as with the sasl-secprops keyword above) for a SASL bind can be set with the secprops option. A non default SASL realm can be set with the realm option. The identity used for synchronization by the consumer should be allowed to receive an unlimited number of entries in response to a search request. The provider, other than allow authentication of the syncrepl identity, should grant that identity appropriate access privileges to the data that is being replicated (access directive), and appropriate time and size limits. This can be accomplished by either allowing unlimited sizelimit and timelimit, or by setting an appropriate limits statement in the consumer's configuration (see sizelimit and limits for details).
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.
The starttls parameter specifies use of the StartTLS extended operation to establish a TLS session before Binding 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.
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.
Here is a short example of a configuration file:
include /etc/ldap/schema/core.schema pidfile /var/run/slapd.pid # Subtypes of "name" (e.g. "cn" and "ou") with the # option ";x-hidden" can be searched for/compared, # but are not shown. See slapd.access(5). attributeoptions x-hidden lang- access to attrs=name;x-hidden by * =cs # Protect passwords. See slapd.access(5). access to attrs=userPassword by * auth # Read access to other attributes and entries. access to * by * read database bdb suffix "dc=our-domain,dc=com" # The database directory MUST exist prior to # running slapd AND should only be accessible # by the slapd/tools. Mode 0700 recommended. directory /var/lib/ldap # Indices to maintain index objectClass eq index cn,sn,mail pres,eq,approx,sub # We serve small clients that do not handle referrals, # so handle remote lookups on their behalf. database ldap suffix "" uri ldap://ldap.some-server.com/ lastmod off
"OpenLDAP Administrator's Guide" contains a longer annotated example of a configuration file. The original /etc/ldap/slapd.conf is another example.
"OpenLDAP Administrator's Guide" (http://www.OpenLDAP.org/doc/admin/)