[openldap] / doc / guide / admin / slapdconfig.sdf

# $OpenLDAP$
# Copyright 1999-2017 The OpenLDAP Foundation, All Rights Reserved.
# COPYING RESTRICTIONS APPLY, see COPYRIGHT.

H1: 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
{{EX:/usr/local/etc/openldap}} directory.  An alternate configuration
file location can be specified via a command-line option to {{slapd}}(8).


H2: 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 '{{EX:#}}' 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 {{EX:"like this"}}. If
an argument contains a double quote or a backslash character `{{EX:\}}',
the character should be preceded by a backslash character `{{EX:\}}'.

The distribution contains an example configuration file that will
be installed in the {{F: /usr/local/etc/openldap}} directory.
A number of files containing schema definitions (attribute types
and object classes) are also provided in the
{{F: /usr/local/etc/openldap/schema}} directory.


H2: 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.



H3: 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 {{EX:<>}}.


H4: 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 {{SECT:Access Control}} section of 
this guide for basic usage.

!if 0
More details discussion of this directive can be found in the
{{SECT:Advanced Access Control}} chapter.
!endif

Note: If no {{EX:access}} directives are specified, the default
access control policy, {{EX:access to * by * read}}, allows all
both authenticated and anonymous users read access.


H4: attributetype <{{REF:RFC4512}} Attribute Type Description>

This directive defines an attribute type.
Please see the {{SECT:Schema Specification}} chapter
for information regarding how to use this directive.

H4: 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.


H4: 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.

H4: loglevel <level>

This directive specifies the level at which debugging statements
and operation statistics should be syslogged (currently logged to
the {{syslogd}}(8) {{EX:LOG_LOCAL4}} facility). You must have
configured OpenLDAP {{EX:--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 {{EX:-d?}}
or consult the table below. The possible values for <integer> are:

!block table; colaligns="RL"; align=Center; \
        title="Table 6.1: Debugging Levels"
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
!endblock

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:

E: loglevel -1

This will cause lots and lots of debugging information to be
logged.

E: loglevel conns filter

Just log the connection and search filter processing.

E: 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
{{EX:None}} level is required to have high priority messages logged.

\Default:

E: loglevel stats

Basic stats logging is configured by default. However, if no loglevel is
defined, no logging occurs (equivalent to a 0 level).

H4: objectclass <{{REF:RFC4512}} Object Class Description>

This directive defines an object class.
Please see the {{SECT:Schema Specification}} chapter for
information regarding how to use this directive.


H4: 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.


H4: sizelimit <integer>

This directive specifies the maximum number of entries to return
from a search operation.

\Default:

>       sizelimit 500

See the {{SECT:Limits}} section of this guide and {{slapd.conf}}(5)
for more details.

H4: 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 {{SECT:Limits}} section of this guide and {{slapd.conf}}(5)
for more details.


H3: 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.

H4: backend <type>

This directive marks the beginning of a backend declaration.
{{EX:<type>}} should be one of the
supported backend types listed in Table 6.2.

!block table; align=Center; coltags="EX,N"; \
        title="Table 6.2: Database Backends"
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
!endblock

\Example:

>       backend bdb

This marks the beginning of a new {{TERM:BDB}} backend
definition.


H3: 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.

H4: database <type>

This directive marks the beginning of a database instance
declaration.
{{EX:<type>}} should be one of the
supported backend types listed in Table 6.2.

\Example:

>       database bdb

This marks the beginning of a new {{TERM:BDB}} database instance
declaration.


H4: limits <selector> <limit> [<limit> [...]]

Specify time and size limits based on the operation's initiator or base
DN.

See the {{SECT:Limits}} section of this guide and {{slapd.conf}}(5)
for more details.


H4: 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


H4: 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 {{SECT:SASL Authentication}} section for information on
SASL authentication identities.


H4: 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 {{REF:RFC2307}}
form.  {{slappasswd}}(8) may be used to generate the password hash.

\Example:

>       rootpw {SSHA}ZKKuqbEKJfKSXhUbHG3fG8MDn9j1v4QN

The hash was generated using the command {{EX:slappasswd -s secret}}.


H4: 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.


H4: 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 replica of the
master content by establishing the current {{slapd}}(8) as a
replication consumer site running a syncrepl replication engine.
The master database is located at the replication provider site
specified by the {{EX:provider}} parameter. The replica database is
kept up-to-date with the master content using the LDAP Content
Synchronization protocol. See {{REF:RFC4533}}
for more information on the protocol.

The {{EX:rid}} parameter is used for identification of the current
{{EX:syncrepl}} directive within the replication consumer server,
where {{EX:<replica ID>}} uniquely identifies the syncrepl specification
described by the current {{EX:syncrepl}} directive. {{EX:<replica ID>}}
is non-negative and is no more than three decimal digits in length.

The {{EX:provider}} parameter specifies the replication provider site
containing the master content as an LDAP URI. The {{EX: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
{{EX:ldap://provider.example.com:389}} or {{EX: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 at the consumer site, whereas the {{EX:replica}}
specification is located at the provider site. {{EX:syncrepl}} and
{{EX:replica}} directives define two independent replication
mechanisms. They do not represent the replication peers of each other.

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 {{EX:searchbase}},
{{EX:scope}}, {{EX:filter}}, {{EX:attrs}}, {{EX:exattrs}}, {{EX:attrsonly}},
{{EX:sizelimit}}, and {{EX:timelimit}} parameters as in the normal
search specification. The {{EX:searchbase}} parameter has no
default value and must always be specified. The {{EX:scope}} defaults
to {{EX:sub}}, the {{EX:filter}} defaults to {{EX:(objectclass=*)}},
{{EX:attrs}} defaults to {{EX:"*,+"}} to replicate all user and operational
attributes, and {{EX:attrsonly}} is unset by default. Both {{EX:sizelimit}}
and {{EX:timelimit}} default to "unlimited", and only positive integers
or "unlimited" may be specified. The {{EX:exattrs}} option may also be used
to specify attributes that should be omitted from incoming entries.

The {{TERM[expand]LDAP Sync}} protocol has two operation
types: {{EX:refreshOnly}} and {{EX:refreshAndPersist}}.
The operation type is specified by the {{EX:type}} parameter.
In the {{EX:refreshOnly}} operation, the next synchronization search operation
is periodically rescheduled at an interval time after each
synchronization operation finishes. The interval is specified
by the {{EX:interval}} parameter. It is set to one day by default.
In the {{EX:refreshAndPersist}} operation, a synchronization search
remains persistent in the provider {{slapd}} instance. Further updates to the
master replica will generate {{EX: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 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 {{EX:schemachecking}} parameter.
If it is turned on, every replicated entry will be checked for its
schema as the entry is stored into the replica content.
Every entry in the replica 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 {{EX:network-timeout}} parameter sets how long the consumer will
wait to establish a network connection to the provider.  Once a
connection is established, the {{EX: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 {{EX: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
master database. 

The {{EX:bindmethod}} is {{EX:simple}} or {{EX:sasl}},
depending on whether simple password-based authentication or
{{TERM:SASL}} authentication is to be used when connecting
to the provider {{slapd}} instance.

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 {{EX:binddn}}
and {{EX:credentials}} parameters.

SASL authentication is generally recommended.  SASL authentication
requires specification of a mechanism using the {{EX:saslmech}} parameter.
Depending on the mechanism, an authentication identity and/or
credentials can be specified using {{EX:authcid}} and {{EX:credentials}},
respectively.  The {{EX:authzid}} parameter may be used to specify
an authorization identity.

The {{EX:realm}} parameter specifies a realm which a certain
mechanisms authenticate the identity within. The {{EX:secprops}}
parameter specifies Cyrus SASL security properties.

The {{EX: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 {{EX:starttls}} parameter specifies use of the StartTLS extended
operation to establish a TLS session before authenticating to the provider.
If the {{EX: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 {{EX:"demand"}} and the
other TLS settings default to the same as the main slapd TLS settings.

The {{EX: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
{{EX:logbase}} and {{EX:logfilter}} parameters must be set appropriately
for the log that will be used. The {{EX:syncdata}} parameter must
be set to either {{EX:"accesslog"}} if the log conforms to the
{{slapo-accesslog}}(5) log format, or {{EX:"changelog"}} if the log
conforms to the obsolete {{changelog}} format. If the {{EX:syncdata}}
parameter is omitted or set to {{EX:"default"}} then the log
parameters are ignored.

The {{syncrepl}} replication mechanism is supported by the {{bdb}},
{{hdb}}, and {{mdb}} backends.

See the {{SECT:LDAP Sync Replication}} chapter of this guide for
more information on how to use this directive.


H4: updateref <URL>

This directive is only applicable in a {{slave}} (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 {{TERM:URL}} is provided.

\Example:

>       updateref       ldap://master.example.net


H3: BDB and HDB Database Directives

Directives in this category only apply to both the {{TERM:BDB}}
and the {{TERM:HDB}} database.
That is, they must follow a "database bdb" or "database hdb" line
and come before any
subsequent "backend" or "database" line.  For a complete reference
of BDB/HDB configuration directives, see {{slapd-bdb}}(5).


H4: 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


H2: Configuration File Example

The following is an example configuration file, interspersed
with explanatory text. It defines two databases to handle
different parts of the {{TERM:X.500}} tree; both are {{TERM:BDB}}
database instances. The line numbers shown are provided for
reference only and are not included in the actual file. First, the
global configuration section:

E:  1.    # example config file - global configuration section
E:  2.    include /usr/local/etc/schema/core.schema
E:  3.    referral ldap://root.openldap.org
E:  4.    access to * by * read
 
Line 1 is a comment. Line 2 includes another config file
which contains {{core}} schema definitions.
The {{EX: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 {{EX: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 slave slapds, one on
truelies, the other on judgmentday. Indices are to be
maintained for several attributes, and the {{EX:userPassword}}
attribute is to be protected from unauthorized access.

E:  5.    # BDB definition for the example.com
E:  6.    database bdb
E:  7.    suffix "dc=example,dc=com"
E:  8.    directory /usr/local/var/openldap-data
E:  9.    rootdn "cn=Manager,dc=example,dc=com"
E: 10.    rootpw secret
E: 11.    # indexed attribute definitions
E: 12.    index uid pres,eq
E: 13.    index cn,sn pres,eq,approx,sub
E: 14.    index objectClass eq
E: 15.    # database access control definitions
E: 16.    access to attrs=userPassword
E: 17.        by self write
E: 18.        by anonymous auth
E: 19.        by dn.base="cn=Admin,dc=example,dc=com" write
E: 20.        by * none
E: 21.    access to *
E: 22.        by self write
E: 23.        by dn.base="cn=Admin,dc=example,dc=com" write
E: 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 {{EX: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
{{EX: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.

E: 33.    # BDB definition for example.net
E: 34.    database bdb
E: 35.    suffix "dc=example,dc=net"
E: 36.    directory /usr/local/var/openldap-data-net
E: 37.    rootdn "cn=Manager,dc=example,dc=com"
E: 38.    index objectClass eq
E: 39.    access to * by users read