1SLAPD.CONF(5) File Formats Manual SLAPD.CONF(5)
2
6 slapd.conf - configuration file for slapd, the stand-alone LDAP daemon
7
9 /etc/openldap/slapd.conf
10
12 The file /etc/openldap/slapd.conf contains configuration information
13 for the slapd(8) daemon. This configuration file is also used by the
14 SLAPD tools slapacl(8), slapadd(8), slapauth(8), slapcat(8), slapdn(8),
15 slapindex(8), and slaptest(8).
16 The slapd.conf file consists of a series of global configuration
18 options that apply to slapd as a whole (including all backends), fol‐
19 lowed by zero or more database backend definitions that contain infor‐
20 mation specific to a backend instance. The configuration options are
21 case-insensitive; their value, on a case by case basis, may be case-
22 sensitive.
23 The general format of slapd.conf is as follows:
25 # comment - these options apply to every database
27 <global configuration options>
28 # first database definition & configuration options
29 database <backend 1 type>
30 <configuration options specific to backend 1>
31 # subsequent database definitions & configuration options
32 ...
33 As many backend-specific sections as desired may be included. Global
35 options can be overridden in a backend (for options that appear more
36 than once, the last appearance in the slapd.conf file is used).
37 If a line begins with white space, it is considered a continuation of
39 the previous line. No physical line should be over 2000 bytes long.
40 Blank lines and comment lines beginning with a `#' character are
42 ignored. Note: continuation lines are unwrapped before comment pro‐
43 cessing is applied.
44 Arguments on configuration lines are separated by white space. If an
46 argument contains white space, the argument should be enclosed in dou‐
47 ble quotes. If an argument contains a double quote (`"') or a back‐
48 slash character (`\'), the character should be preceded by a backslash
49 character.
50 The specific configuration options available are discussed below in the
52 Global Configuration Options, General Backend Options, and General
53 Database Options. Backend-specific options are discussed in the
54 slapd-<backend>(5) manual pages. Refer to the "OpenLDAP Administra‐
55 tor's Guide" for more details on the slapd configuration file.
56
58 Options described in this section apply to all backends, unless specif‐
59 ically overridden in a backend definition. Arguments that should be
60 replaced by actual text are shown in brackets <>.
61 access to <what> [ by <who> <access> <control> ]+
63 Grant access (specified by <access>) to a set of entries and/or
64 attributes (specified by <what>) by one or more requestors
65 (specified by <who>). If no access controls are present, the
66 default policy allows anyone and everyone to read anything but
67 restricts updates to rootdn. (e.g., "access to * by * read").
68 The rootdn can always read and write EVERYTHING! See
69 slapd.access(5) and the "OpenLDAP's Administrator's Guide" for
70 details.
71 allow <features>
73 Specify a set of features (separated by white space) to allow
74 (default none). bind_v2 allows acceptance of LDAPv2 bind
75 requests. Note that slapd(8) does not truly implement LDAPv2
76 (RFC 1777), now Historic (RFC 3494). bind_anon_cred allows
77 anonymous bind when credentials are not empty (e.g. when DN is
78 empty). bind_anon_dn allows unauthenticated (anonymous) bind
79 when DN is not empty. update_anon allows unauthenticated
80 (anonymous) update operations to be processed (subject to access
81 controls and other administrative limits). proxy_authz_anon
82 allows unauthenticated (anonymous) proxy authorization control
83 to be processed (subject to access controls, authorization and
84 other administrative limits).
85 argsfile <filename>
87 The (absolute) name of a file that will hold the slapd server's
88 command line (program name and options).
89 attributeoptions [option-name]...
91 Define tagging attribute options or option tag/range prefixes.
92 Options must not end with `-', prefixes must end with `-'. The
93 `lang-' prefix is predefined. If you use the attributeoptions
94 directive, `lang-' will no longer be defined and you must spec‐
95 ify it explicitly if you want it defined.
96 An attribute description with a tagging option is a subtype of
98 that attribute description without the option. Except for that,
99 options defined this way have no special semantics. Prefixes
100 defined this way work like the `lang-' options: They define a
101 prefix for tagging options starting with the prefix. That is,
102 if you define the prefix `x-foo-', you can use the option
103 `x-foo-bar'. Furthermore, in a search or compare, a prefix or
104 range name (with a trailing `-') matches all options starting
105 with that name, as well as the option with the range name sans
106 the trailing `-'. That is, `x-foo-bar-' matches `x-foo-bar' and
107 `x-foo-bar-baz'.
108 RFC 4520 reserves options beginning with `x-' for private exper‐
110 iments. Other options should be registered with IANA, see RFC
111 4520 section 3.5. OpenLDAP also has the `binary' option built
112 in, but this is a transfer option, not a tagging option.
113 attributetype ( <oid> [NAME <name>] [DESC <description>] [OBSOLETE]
115 [SUP <oid>] [EQUALITY <oid>] [ORDERING <oid>] [SUBSTR <oid>]
116 [SYNTAX <oidlen>] [SINGLE-VALUE] [COLLECTIVE]
117 [NO-USER-MODIFICATION] [USAGE <attributeUsage>] )
118 Specify an attribute type using the LDAPv3 syntax defined in RFC
119 4512. The slapd parser extends the RFC 4512 definition by
120 allowing string forms as well as numeric OIDs to be used for the
121 attribute OID and attribute syntax OID. (See the
122 objectidentifier description.)
123 authid-rewrite<cmd> <args>
125 Used by the authentication framework to convert simple user
126 names to an LDAP DN used for authorization purposes. Its
127 purpose is analogous to that of authz-regexp (see below). The
128 prefix authid- is followed by a set of rules analogous to those
129 described in slapo-rwm(5) for data rewriting (replace the rwm-
130 prefix with authid-). authid-rewrite<cmd> and authz-regexp
131 rules should not be intermixed.
132 authz-policy <policy>
134 Used to specify which rules to use for Proxy Authorization.
135 Proxy authorization allows a client to authenticate to the
136 server using one user's credentials, but specify a different
137 identity to use for authorization and access control purposes.
138 It essentially allows user A to login as user B, using user A's
139 password. The none flag disables proxy authorization. This is
140 the default setting. The from flag will use rules in the
141 authzFrom attribute of the authorization DN. The to flag will
142 use rules in the authzTo attribute of the authentication DN.
143 The any flag, an alias for the deprecated value of both, will
144 allow any of the above, whatever succeeds first (checked in to,
145 from sequence. The all flag requires both authorizations to
146 succeed.
147 The rules are mechanisms to specify which identities are allowed
149 to perform proxy authorization. The authzFrom attribute in an
150 entry specifies which other users are allowed to proxy login to
151 this entry. The authzTo attribute in an entry specifies which
152 other users this user can authorize as. Use of authzTo rules
153 can be easily abused if users are allowed to write arbitrary
154 values to this attribute. In general the authzTo attribute must
155 be protected with ACLs such that only privileged users can
156 modify it. The value of authzFrom and authzTo describes an
157 identity or a set of identities; it can take five forms:
158 ldap:///<base>??[<scope>]?<filter>
160 dn[.<dnstyle>]:<pattern>
161 u[.<mech>[/<realm>]]:<pattern>
162 group[/objectClass[/attributeType]]:<pattern>
163 <pattern>
164 <dnstyle>:={exact|onelevel|children|subtree|regex}
166 The first form is a valid LDAP URI where the <host>:<port>, the
168 <attrs> and the <extensions> portions must be absent, so that
169 the search occurs locally on either authzFrom or authzTo. The
170 second form is a DN, with the optional style modifiers exact,
171 onelevel, children, and subtree for exact, onelevel, children
172 and subtree matches, which cause <pattern> to be normalized
173 according to the DN normalization rules, or the special regex
174 style, which causes the <pattern> to be treated as a POSIX
175 (''extended'') regular expression, as discussed in regex(7)
176 and/or re_format(7). A pattern of * means any non-anonymous DN.
177 The third form is a SASL id, with the optional fields <mech> and
178 <realm> that allow to specify a SASL mechanism, and eventually a
179 SASL realm, for those mechanisms that support one. The need to
180 allow the specification of a mechanism is still debated, and
181 users are strongly discouraged to rely on this possibility. The
182 fourth form is a group specification, consisting of the keyword
183 group, optionally followed by the specification of the group
184 objectClass and member attributeType. The group with DN
185 <pattern> is searched with base scope, and in case of match, the
186 values of the member attributeType are searched for the asserted
187 DN. For backwards compatibility, if no identity type is
188 provided, i.e. only <pattern> is present, an exact DN is
189 assumed; as a consequence, <pattern> is subjected to DN
190 normalization. Since the interpretation of authzFrom and
191 authzTo can impact security, users are strongly encouraged to
192 explicitly set the type of identity specification that is being
193 used. A subset of these rules can be used as third arg in the
194 authz-regexp statement (see below); significantly, the URI,
195 provided it results in exactly one entry, and the dn.exact:<dn>
196 forms.
197 authz-regexp <match> <replace>
199 Used by the authentication framework to convert simple user
200 names, such as provided by SASL subsystem, or extracted from
201 certificates in case of cert-based SASL EXTERNAL, or provided
202 within the RFC 4370 "proxied authorization" control, to an LDAP
203 DN used for authorization purposes. Note that the resulting DN
204 need not refer to an existing entry to be considered valid.
205 When an authorization request is received from the SASL
206 subsystem, the SASL USERNAME, REALM, and MECHANISM are taken,
207 when available, and combined into a name of the form
208 UID=<username>[[,CN=<realm>],CN=<mechanism>],CN=auth
210 This name is then compared against the match POSIX
212 (''extended'') regular expression, and if the match is
213 successful, the name is replaced with the replace string. If
214 there are wildcard strings in the match regular expression that
215 are enclosed in parenthesis, e.g.
216 UID=([^,]*),CN=.*
218 then the portion of the name that matched the wildcard will be
220 stored in the numbered placeholder variable $1. If there are
221 other wildcard strings in parenthesis, the matching strings will
222 be in $2, $3, etc. up to $9. The placeholders can then be used
223 in the replace string, e.g.
224 UID=$1,OU=Accounts,DC=example,DC=com
226 The replaced name can be either a DN, i.e. a string prefixed by
228 "dn:", or an LDAP URI. If the latter, the server will use the
229 URI to search its own database(s) and, if the search returns
230 exactly one entry, the name is replaced by the DN of that entry.
231 The LDAP URI must have no hostport, attrs, or extensions
232 components, but the filter is mandatory, e.g.
233 ldap:///OU=Accounts,DC=example,DC=com??one?(UID=$1)
235 The protocol portion of the URI must be strictly ldap. Note
237 that this search is subject to access controls. Specifically,
238 the authentication identity must have "auth" access in the
239 subject.
240 Multiple authz-regexp options can be given in the configuration
242 file to allow for multiple matching and replacement patterns.
243 The matching patterns are checked in the order they appear in
244 the file, stopping at the first successful match.
245 concurrency <integer>
248 Specify a desired level of concurrency. Provided to the
249 underlying thread system as a hint. The default is not to
250 provide any hint.
251 conn_max_pending <integer>
253 Specify the maximum number of pending requests for an anonymous
254 session. If requests are submitted faster than the server can
255 process them, they will be queued up to this limit. If the limit
256 is exceeded, the session is closed. The default is 100.
257 conn_max_pending_auth <integer>
259 Specify the maximum number of pending requests for an
260 authenticated session. The default is 1000.
261 defaultsearchbase <dn>
263 Specify a default search base to use when client submits a non-
264 base search request with an empty base DN. Base scoped search
265 requests with an empty base DN are not affected.
266 disallow <features>
268 Specify a set of features (separated by white space) to disallow
269 (default none). bind_anon disables acceptance of anonymous bind
270 requests. Note that this setting does not prohibit anonymous
271 directory access (See "require authc"). bind_simple disables
272 simple (bind) authentication. tls_2_anon disables forcing
273 session to anonymous status (see also tls_authc) upon StartTLS
274 operation receipt. tls_authc disallows the StartTLS operation
275 if authenticated (see also tls_2_anon).
276 proxy_authz_non_critical disables acceptance of the proxied
277 authorization control (RFC4370) when criticality is FALSE.
278 dontusecopy_non_critical disables acceptance of the dontUseCopy
279 control (a work in progress) when criticality is FALSE.
280 ditcontentrule ( <oid> [NAME <name>] [DESC <description>] [OBSOLETE]
282 [AUX <oids>] [MUST <oids>] [MAY <oids>] [NOT <oids>] )
283 Specify an DIT Content Rule using the LDAPv3 syntax defined in
284 RFC 4512. The slapd parser extends the RFC 4512 definition by
285 allowing string forms as well as numeric OIDs to be used for the
286 attribute OID and attribute syntax OID. (See the
287 objectidentifier description.)
288 gentlehup { on | off }
290 A SIGHUP signal will only cause a 'gentle' shutdown-attempt:
291 Slapd will stop listening for new connections, but will not
292 close the connections to the current clients. Future write
293 operations return unwilling-to-perform, though. Slapd
294 terminates when all clients have closed their connections (if
295 they ever do), or - as before - if it receives a SIGTERM signal.
296 This can be useful if you wish to terminate the server and start
297 a new slapd server with another database, without disrupting the
298 currently active clients. The default is off. You may wish to
299 use idletimeout along with this option.
300 idletimeout <integer>
302 Specify the number of seconds to wait before forcibly closing an
303 idle client connection. A idletimeout of 0 disables this
304 feature. The default is 0. You may also want to set the
305 writetimeout option.
306 include <filename>
308 Read additional configuration information from the given file
309 before continuing with the next line of the current file.
310 index_intlen <integer>
312 Specify the key length for ordered integer indices. The most
313 significant bytes of the binary integer will be used for index
314 keys. The default value is 4, which provides exact indexing for
315 31 bit values. A floating point representation is used to index
316 too large values.
317 index_substr_if_minlen <integer>
319 Specify the minimum length for subinitial and subfinal indices.
320 An attribute value must have at least this many characters in
321 order to be processed by the indexing functions. The default is
322 2.
323 index_substr_if_maxlen <integer>
325 Specify the maximum length for subinitial and subfinal indices.
326 Only this many characters of an attribute value will be
327 processed by the indexing functions; any excess characters are
328 ignored. The default is 4.
329 index_substr_any_len <integer>
331 Specify the length used for subany indices. An attribute value
332 must have at least this many characters in order to be
333 processed. Attribute values longer than this length will be
334 processed in segments of this length. The default is 4. The
335 subany index will also be used in subinitial and subfinal index
336 lookups when the filter string is longer than the
337 index_substr_if_maxlen value.
338 index_substr_any_step <integer>
340 Specify the steps used in subany index lookups. This value sets
341 the offset for the segments of a filter string that are
342 processed for a subany index lookup. The default is 2. For
343 example, with the default values, a search using this filter
344 "cn=*abcdefgh*" would generate index lookups for "abcd", "cdef",
345 and "efgh".
346 Note: Indexing support depends on the particular backend in use. Also,
349 changing these settings will generally require deleting any indices
350 that depend on these parameters and recreating them with slapindex(8).
351 ldapsyntax ( <oid> [DESC <description>] [X-SUBST <substitute-syntax>] )
354 Specify an LDAP syntax using the LDAPv3 syntax defined in RFC
356 4512. The slapd parser extends the RFC 4512 definition by
357 allowing string forms as well as numeric OIDs to be used for the
358 syntax OID. (See the objectidentifier description.) The slapd
359 parser also honors the X-SUBST extension (an OpenLDAP-specific
360 extension), which allows to use the ldapsyntax statement to
361 define a non-implemented syntax along with another syntax, the
362 extension value substitute-syntax, as its temporary replacement.
363 The substitute-syntax must be defined. This allows to define
364 attribute types that make use of non-implemented syntaxes using
365 the correct syntax OID. Unless X-SUBST is used, this
366 configuration statement would result in an error, since no
367 handlers would be associated to the resulting syntax structure.
368 localSSF <SSF>
371 Specifies the Security Strength Factor (SSF) to be given local
372 LDAP sessions, such as those to the ldapi:// listener. For a
373 description of SSF values, see sasl-secprops's minssf option
374 description. The default is 71.
375 logfile <filename>
377 Specify a file for recording debug log messages. By default
378 these messages only go to stderr and are not recorded anywhere
379 else. Specifying a logfile copies messages to both stderr and
380 the logfile.
381 loglevel <integer> [...]
383 Specify the level at which debugging statements and operation
384 statistics should be syslogged (currently logged to the
385 syslogd(8) LOG_LOCAL4 facility). They must be considered
386 subsystems rather than increasingly verbose log levels. Some
387 messages with higher priority are logged regardless of the
388 configured loglevel as soon as any logging is configured. Log
389 levels are additive, and available levels are:
390 1 (0x1 trace) trace function calls
391 2 (0x2 packets) debug packet handling
392 4 (0x4 args) heavy trace debugging (function args)
393 8 (0x8 conns) connection management
394 16 (0x10 BER) print out packets sent and received
395 32 (0x20 filter) search filter processing
396 64 (0x40 config) configuration file processing
397 128 (0x80 ACL) access control list processing
398 256 (0x100 stats) connections, LDAP operations,
399 results (recommended)
400 512 (0x200 stats2) stats log entries sent
401 1024 (0x400 shell) print communication with shell
402 backends
403 2048 (0x800 parse) entry parsing
404 16384 (0x4000 sync) LDAPSync replication
413 32768 (0x8000 none) only messages that get logged
414 whatever log level is set
415 The desired log level can be input as a single integer that
416 combines the (ORed) desired levels, both in decimal or in
417 hexadecimal notation, as a list of integers (that are ORed
418 internally), or as a list of the names that are shown between
419 brackets, such that
420 loglevel 129
422 loglevel 0x81
423 loglevel 128 1
424 loglevel 0x80 0x1
425 loglevel acl trace
426 are equivalent. The keyword any can be used as a shortcut to
428 enable logging at all levels (equivalent to -1). The keyword
429 none, or the equivalent integer representation, causes those
430 messages that are logged regardless of the configured loglevel
431 to be logged. In fact, if loglevel is set to 0, no logging
432 occurs, so at least the none level is required to have high
433 priority messages logged.
434 The loglevel defaults to stats. This level should usually also
436 be included when using other loglevels, to help analyze the
437 logs.
438 moduleload <filename>
440 Specify the name of a dynamically loadable module to load. The
441 filename may be an absolute path name or a simple filename. Non-
442 absolute names are searched for in the directories specified by
443 the modulepath option. This option and the modulepath option are
444 only usable if slapd was compiled with --enable-modules.
445 modulepath <pathspec>
447 Specify a list of directories to search for loadable modules.
448 Typically the path is colon-separated but this depends on the
449 operating system. The default is /usr/lib64/openldap, which is
450 where the standard OpenLDAP install will place its modules.
451 objectclass ( <oid> [NAME <name>] [DESC <description>] [OBSOLETE]
453 [SUP <oids>] [{ ABSTRACT | STRUCTURAL | AUXILIARY }]
454 [MUST <oids>] [MAY <oids>] )
455 Specify an objectclass using the LDAPv3 syntax defined in RFC
456 4512. The slapd parser extends the RFC 4512 definition by
457 allowing string forms as well as numeric OIDs to be used for the
458 object class OID. (See the objectidentifier description.)
459 Object classes are "STRUCTURAL" by default.
460 objectidentifier <name> { <oid> | <name>[:<suffix>] }
462 Define a string name that equates to the given OID. The string
463 can be used in place of the numeric OID in objectclass and
464 attribute definitions. The name can also be used with a suffix
465 of the form ":xx" in which case the value "oid.xx" will be used.
466 password-hash <hash> [<hash>...]
468 This option configures one or more hashes to be used in
469 generation of user passwords stored in the userPassword
470 attribute during processing of LDAP Password Modify Extended
471 Operations (RFC 3062). The <hash> must be one of {SSHA}, {SHA},
472 {SMD5}, {MD5}, {CRYPT}, and {CLEARTEXT}. The default is {SSHA}.
473 {SHA} and {SSHA} use the SHA-1 algorithm (FIPS 160-1), the
475 latter with a seed.
476 {MD5} and {SMD5} use the MD5 algorithm (RFC 1321), the latter
478 with a seed.
479 {CRYPT} uses the crypt(3).
481 {CLEARTEXT} indicates that the new password should be added to
483 userPassword as clear text.
484 Note that this option does not alter the normal user
486 applications handling of userPassword during LDAP Add, Modify,
487 or other LDAP operations.
488 password-crypt-salt-format <format>
490 Specify the format of the salt passed to crypt(3) when
491 generating {CRYPT} passwords (see password-hash) during
492 processing of LDAP Password Modify Extended Operations (RFC
493 3062).
494 This string needs to be in sprintf(3) format and may include one
496 (and only one) %s conversion. This conversion will be
497 substituted with a string of random characters from
498 [A-Za-z0-9./]. For example, "%.2s" provides a two character
499 salt and "$1$%.8s" tells some versions of crypt(3) to use an MD5
500 algorithm and provides 8 random characters of salt. The default
501 is "%s", which provides 31 characters of salt.
502 pidfile <filename>
504 The (absolute) name of a file that will hold the slapd server's
505 process ID (see getpid(2)).
506 referral <url>
508 Specify the referral to pass back when slapd(8) cannot find a
509 local database to handle a request. If specified multiple
510 times, each url is provided.
511 require <conditions>
513 Specify a set of conditions (separated by white space) to
514 require (default none). The directive may be specified globally
515 and/or per-database; databases inherit global conditions, so
516 per-database specifications are additive. bind requires bind
517 operation prior to directory operations. LDAPv3 requires
518 session to be using LDAP version 3. authc requires
519 authentication prior to directory operations. SASL requires
520 SASL authentication prior to directory operations. strong
521 requires strong authentication prior to directory operations.
522 The strong keyword allows protected "simple" authentication as
523 well as SASL authentication. none may be used to require no
524 conditions (useful to clear out globally set conditions within a
525 particular database); it must occur first in the list of
526 conditions.
527 reverse-lookup on | off
529 Enable/disable client name unverified reverse lookup (default is
530 off if compiled with --enable-rlookups).
531 rootDSE <file>
533 Specify the name of an LDIF(5) file containing user defined
534 attributes for the root DSE. These attributes are returned in
535 addition to the attributes normally produced by slapd.
536 The root DSE is an entry with information about the server and
538 its capabilities, in operational attributes. It has the empty
539 DN, and can be read with e.g.:
540 ldapsearch -x -b "" -s base "+"
541 See RFC 4512 section 5.1 for details.
542 sasl-auxprops <plugin> [...]
544 Specify which auxprop plugins to use for authentication lookups.
545 The default is empty, which just uses slapd's internal support.
546 Usually no other auxprop plugins are needed.
547 sasl-host <fqdn>
549 Used to specify the fully qualified domain name used for SASL
550 processing.
551 sasl-realm <realm>
553 Specify SASL realm. Default is empty.
554 sasl-secprops <properties>
556 Used to specify Cyrus SASL security properties. The none flag
557 (without any other properties) causes the flag properties
558 default, "noanonymous,noplain", to be cleared. The noplain flag
559 disables mechanisms susceptible to simple passive attacks. The
560 noactive flag disables mechanisms susceptible to active attacks.
561 The nodict flag disables mechanisms susceptible to passive
562 dictionary attacks. The noanonymous flag disables mechanisms
563 which support anonymous login. The forwardsec flag require
564 forward secrecy between sessions. The passcred require
565 mechanisms which pass client credentials (and allow mechanisms
566 which can pass credentials to do so). The minssf=<factor>
567 property specifies the minimum acceptable security strength
568 factor as an integer approximate to effective key length used
569 for encryption. 0 (zero) implies no protection, 1 implies
570 integrity protection only, 56 allows DES or other weak ciphers,
571 112 allows triple DES and other strong ciphers, 128 allows RC4,
572 Blowfish and other modern strong ciphers. The default is 0.
573 The maxssf=<factor> property specifies the maximum acceptable
574 security strength factor as an integer (see minssf description).
575 The default is INT_MAX. The maxbufsize=<size> property
576 specifies the maximum security layer receive buffer size
577 allowed. 0 disables security layers. The default is 65536.
578 schemadn <dn>
580 Specify the distinguished name for the subschema subentry that
581 controls the entries on this server. The default is
582 "cn=Subschema".
583 security <factors>
585 Specify a set of security strength factors (separated by white
586 space) to require (see sasl-secprops's minssf option for a
587 description of security strength factors). The directive may be
588 specified globally and/or per-database. ssf=<n> specifies the
589 overall security strength factor. transport=<n> specifies the
590 transport security strength factor. tls=<n> specifies the TLS
591 security strength factor. sasl=<n> specifies the SASL security
592 strength factor. update_ssf=<n> specifies the overall security
593 strength factor to require for directory updates.
594 update_transport=<n> specifies the transport security strength
595 factor to require for directory updates. update_tls=<n>
596 specifies the TLS security strength factor to require for
597 directory updates. update_sasl=<n> specifies the SASL security
598 strength factor to require for directory updates.
599 simple_bind=<n> specifies the security strength factor required
600 for simple username/password authentication. Note that the
601 transport factor is measure of security provided by the
602 underlying transport, e.g. ldapi:// (and eventually IPSEC). It
603 is not normally used.
604 serverID <integer> [<URL>]
606 Specify an integer ID from 0 to 4095 for this server (limited to
607 3 hexadecimal digits). The ID may also be specified as a
608 hexadecimal ID by prefixing the value with "0x". These IDs are
609 required when using multimaster replication and each master must
610 have a unique ID. Note that this requirement also applies to
611 separate masters contributing to a glued set of databases. If
612 the URL is provided, this directive may be specified multiple
613 times, providing a complete list of participating servers and
614 their IDs. The fully qualified hostname of each server should be
615 used in the supplied URLs. The IDs are used in the "replica id"
616 field of all CSNs generated by the specified server. The default
617 value is zero. Example:
618 serverID 1
620 sizelimit {<integer>|unlimited}
622 sizelimit size[.{soft|hard|unchecked}]=<integer> [...]
624 Specify the maximum number of entries to return from a search
625 operation. The default size limit is 500. Use unlimited to
626 specify no limits. The second format allows a fine grain
627 setting of the size limits. Extra args can be added on the same
628 line. See limits for an explanation of the different flags.
629 sockbuf_max_incoming <integer>
631 Specify the maximum incoming LDAP PDU size for anonymous
632 sessions. The default is 262143.
633 sockbuf_max_incoming_auth <integer>
635 Specify the maximum incoming LDAP PDU size for authenticated
636 sessions. The default is 4194303.
637 sortvals <attr> [...]
639 Specify a list of multi-valued attributes whose values will
640 always be maintained in sorted order. Using this option will
641 allow Modify, Compare, and filter evaluations on these
642 attributes to be performed more efficiently. The resulting sort
643 order depends on the attributes' syntax and matching rules and
644 may not correspond to lexical order or any other recognizable
645 order.
646 tcp-buffer [listener=<URL>] [{read|write}=]<size>
648 Specify the size of the TCP buffer. A global value for both
649 read and write TCP buffers related to any listener is defined,
650 unless the listener is explicitly specified, or either the read
651 or write qualifiers are used. See tcp(7) for details. Note
652 that some OS-es implement automatic TCP buffer tuning.
653 threads <integer>
655 Specify the maximum size of the primary thread pool. The
656 default is 16; the minimum value is 2.
657 timelimit {<integer>|unlimited}
659 timelimit time[.{soft|hard}]=<integer> [...]
661 Specify the maximum number of seconds (in real time) slapd will
662 spend answering a search request. The default time limit is
663 3600. Use unlimited to specify no limits. The second format
664 allows a fine grain setting of the time limits. Extra args can
665 be added on the same line. See limits for an explanation of the
666 different flags.
667 tool-threads <integer>
669 Specify the maximum number of threads to use in tool mode. This
670 should not be greater than the number of CPUs in the system.
671 The default is 1.
672 writetimeout <integer>
674 Specify the number of seconds to wait before forcibly closing a
675 connection with an outstanding write. This allows recovery from
676 various network hang conditions. A writetimeout of 0 disables
677 this feature. The default is 0.
678
680 If slapd is built with support for Transport Layer Security, there are
681 more options you can specify.
682 TLSCipherSuite <cipher-suite-spec>
684 Permits configuring what ciphers will be accepted and the
685 preference order. <cipher-suite-spec> should be a cipher
686 specification for OpenSSL. Example:
687 TLSCipherSuite HIGH:MEDIUM:+SSLv2
689 To check what ciphers a given spec selects, use:
691 openssl ciphers -v <cipher-suite-spec>
693 To obtain the list of ciphers in GNUtls use:
695 gnutls-cli -l
697 TLSCACertificateFile <filename>
700 Specifies the file that contains certificates for all of the
701 Certificate Authorities that slapd will recognize.
702 TLSCACertificatePath <path>
704 Specifies the path of a directory that contains Certificate
705 Authority certificates in separate individual files. Usually
706 only one of this or the TLSCACertificateFile is used. This
707 directive is not supported when using GNUtls.
708 TLSCertificateFile <filename>
710 Specifies the file that contains the slapd server certificate.
711 TLSCertificateKeyFile <filename>
713 Specifies the file that contains the slapd server private key
714 that matches the certificate stored in the TLSCertificateFile
715 file. Currently, the private key must not be protected with a
716 password, so it is of critical importance that it is protected
717 carefully.
718 TLSDHParamFile <filename>
720 This directive specifies the file that contains parameters for
721 Diffie-Hellman ephemeral key exchange. This is required in
722 order to use a DSA certificate on the server. If multiple sets
723 of parameters are present in the file, all of them will be
724 processed. Note that setting this option may also enable
725 Anonymous Diffie-Hellman key exchanges in certain non-default
726 cipher suites. You should append "!ADH" to your cipher suites
727 if you have changed them from the default, otherwise no
728 certificate exchanges or verification will be done. When using
729 GNUtls these parameters are always generated randomly so this
730 directive is ignored.
731 TLSRandFile <filename>
733 Specifies the file to obtain random bits from when
734 /dev/[u]random is not available. Generally set to the name of
735 the EGD/PRNGD socket. The environment variable RANDFILE can
736 also be used to specify the filename. This directive is ignored
737 with GNUtls.
738 TLSVerifyClient <level>
740 Specifies what checks to perform on client certificates in an
741 incoming TLS session, if any. The <level> can be specified as
742 one of the following keywords:
743 never This is the default. slapd will not ask the client for a
745 certificate.
746 allow The client certificate is requested. If no certificate
748 is provided, the session proceeds normally. If a bad
749 certificate is provided, it will be ignored and the
750 session proceeds normally.
751 try The client certificate is requested. If no certificate
753 is provided, the session proceeds normally. If a bad
754 certificate is provided, the session is immediately
755 terminated.
756 demand | hard | true
758 These keywords are all equivalent, for compatibility
759 reasons. The client certificate is requested. If no
760 certificate is provided, or a bad certificate is
761 provided, the session is immediately terminated.
762 Note that a valid client certificate is required in order
764 to use the SASL EXTERNAL authentication mechanism with a
765 TLS session. As such, a non-default TLSVerifyClient
766 setting must be chosen to enable SASL EXTERNAL
767 authentication.
768 TLSCRLCheck <level>
770 Specifies if the Certificate Revocation List (CRL) of the CA
771 should be used to verify if the client certificates have not
772 been revoked. This requires TLSCACertificatePath parameter to be
773 set. This directive is ignored with GNUtls. <level> can be
774 specified as one of the following keywords:
775 none No CRL checks are performed
777 peer Check the CRL of the peer certificate
779 all Check the CRL for a whole certificate chain
781 TLSCRLFile <filename>
783 Specifies a file containing a Certificate Revocation List to be
784 used for verifying that certificates have not been revoked. This
785 directive is only valid when using GNUtls.
786
788 Options in this section only apply to the configuration file section
789 for the specified backend. They are supported by every type of
790 backend.
791 backend <databasetype>
793 Mark the beginning of a backend definition. <databasetype>
794 should be one of bdb, config, dnssrv, hdb, ldap, ldif, meta,
795 monitor, null, passwd, perl, relay, shell, or sql, depending on
796 which backend will serve the database.
797
800 Options in this section only apply to the configuration file section
801 for the database in which they are defined. They are supported by
802 every type of backend. Note that the database and at least one suffix
803 option are mandatory for each database.
804 database <databasetype>
806 Mark the beginning of a new database instance definition.
807 <databasetype> should be one of bdb, config, dnssrv, hdb, ldap,
808 ldif, meta, monitor, null, passwd, perl, relay, shell, or sql,
809 depending on which backend will serve the database.
810 LDAP operations, even subtree searches, normally access only one
812 database. That can be changed by gluing databases together with
813 the subordinate keyword. Access controls and some overlays can
814 also involve multiple databases.
815 add_content_acl on | off
817 Controls whether Add operations will perform ACL checks on the
818 content of the entry being added. This check is off by default.
819 See the slapd.access(5) manual page for more details on ACL
820 requirements for Add operations.
821 hidden on | off
823 Controls whether the database will be used to answer queries. A
824 database that is hidden will never be selected to answer any
825 queries, and any suffix configured on the database will be
826 ignored in checks for conflicts with other databases. By
827 default, hidden is off.
828 lastmod on | off
830 Controls whether slapd will automatically maintain the
831 modifiersName, modifyTimestamp, creatorsName, and
832 createTimestamp attributes for entries. It also controls the
833 entryCSN and entryUUID attributes, which are needed by the
834 syncrepl provider. By default, lastmod is on.
835 limits <selector> <limit> [<limit> [...]]
837 Specify time and size limits based on the operation's initiator
838 or base DN. The argument <selector> can be any of
839 anonymous | users | [<dnspec>=]<pattern> |
841 group[/oc[/at]]=<pattern>
842 with
844 <dnspec> ::= dn[.<type>][.<style>]
846 <type> ::= self | this
848 <style> ::= exact | base | onelevel | subtree | children
850 | regex | anonymous
851 DN type self is the default and means the bound user, while this
853 means the base DN of the operation. The term anonymous matches
854 all unauthenticated clients. The term users matches all
855 authenticated clients; otherwise an exact dn pattern is assumed
856 unless otherwise specified by qualifying the (optional) key
857 string dn with exact or base (which are synonyms), to require an
858 exact match; with onelevel, to require exactly one level of
859 depth match; with subtree, to allow any level of depth match,
860 including the exact match; with children, to allow any level of
861 depth match, not including the exact match; regex explicitly
862 requires the (default) match based on POSIX (''extended'')
863 regular expression pattern. Finally, anonymous matches unbound
864 operations; the pattern field is ignored. The same behavior is
865 obtained by using the anonymous form of the <selector> clause.
866 The term group, with the optional objectClass oc and
867 attributeType at fields, followed by pattern, sets the limits
868 for any DN listed in the values of the at attribute (default
869 member) of the oc group objectClass (default groupOfNames) whose
870 DN exactly matches pattern.
871 The currently supported limits are size and time.
873 The syntax for time limits is time[.{soft|hard}]=<integer>,
875 where integer is the number of seconds slapd will spend
876 answering a search request. If no time limit is explicitly
877 requested by the client, the soft limit is used; if the
878 requested time limit exceeds the hard limit, the value of the
879 limit is used instead. If the hard limit is set to the keyword
880 soft, the soft limit is used in either case; if it is set to the
881 keyword unlimited, no hard limit is enforced. Explicit requests
882 for time limits smaller or equal to the hard limit are honored.
883 If no limit specifier is set, the value is assigned to the soft
884 limit, and the hard limit is set to soft, to preserve the
885 original behavior.
886 The syntax for size limits is
888 size[.{soft|hard|unchecked}]=<integer>, where integer is the
889 maximum number of entries slapd will return answering a search
890 request. If no size limit is explicitly requested by the
891 client, the soft limit is used; if the requested size limit
892 exceeds the hard limit, the value of the limit is used instead.
893 If the hard limit is set to the keyword soft, the soft limit is
894 used in either case; if it is set to the keyword unlimited, no
895 hard limit is enforced. Explicit requests for size limits
896 smaller or equal to the hard limit are honored. The unchecked
897 specifier sets a limit on the number of candidates a search
898 request is allowed to examine. The rationale behind it is that
899 searches for non-properly indexed attributes may result in large
900 sets of candidates, which must be examined by slapd(8) to
901 determine whether they match the search filter or not. The
902 unchecked limit provides a means to drop such operations before
903 they are even started. If the selected candidates exceed the
904 unchecked limit, the search will abort with Unwilling to
905 perform. If it is set to the keyword unlimited, no limit is
906 applied (the default). If it is set to disabled, the search is
907 not even performed; this can be used to disallow searches for a
908 specific set of users. If no limit specifier is set, the value
909 is assigned to the soft limit, and the hard limit is set to
910 soft, to preserve the original behavior.
911 In case of no match, the global limits are used. The default
913 values are the same as for sizelimit and timelimit; no limit is
914 set on unchecked.
915 If pagedResults control is requested, the hard size limit is
917 used by default, because the request of a specific page size is
918 considered an explicit request for a limitation on the number of
919 entries to be returned. However, the size limit applies to the
920 total count of entries returned within the search, and not to a
921 single page. Additional size limits may be enforced; the syntax
922 is size.pr={<integer>|noEstimate|unlimited}, where integer is
923 the max page size if no explicit limit is set; the keyword
924 noEstimate inhibits the server from returning an estimate of the
925 total number of entries that might be returned (note: the
926 current implementation does not return any estimate). The
927 keyword unlimited indicates that no limit is applied to the
928 pagedResults control page size. The syntax
929 size.prtotal={<integer>|unlimited|disabled} allows to set a
930 limit on the total number of entries that a pagedResults control
931 allows to return. By default it is set to the hard limit. When
932 set, integer is the max number of entries that the whole search
933 with pagedResults control can return. Use unlimited to allow
934 unlimited number of entries to be returned, e.g. to allow the
935 use of the pagedResults control as a means to circumvent size
936 limitations on regular searches; the keyword disabled disables
937 the control, i.e. no paged results can be returned. Note that
938 the total number of entries returned when the pagedResults
939 control is requested cannot exceed the hard size limit of
940 regular searches unless extended by the prtotal switch.
941 The limits statement is typically used to let an unlimited
943 number of entries be returned by searches performed with the
944 identity used by the consumer for synchronization purposes by
945 means of the RFC 4533 LDAP Content Synchronization protocol (see
946 syncrepl for details).
947 maxderefdepth <depth>
949 Specifies the maximum number of aliases to dereference when
950 trying to resolve an entry, used to avoid infinite alias loops.
951 The default is 15.
952 mirrormode on | off
954 This option puts a replica database into "mirror" mode. Update
955 operations will be accepted from any user, not just the
956 updatedn. The database must already be configured as a syncrepl
957 consumer before this keyword may be set. This mode also requires
958 a serverID (see above) to be configured. By default, mirrormode
959 is off.
960 monitoring on | off
962 This option enables database-specific monitoring in the entry
963 related to the current database in the "cn=Databases,cn=Monitor"
964 subtree of the monitor database, if the monitor database is
965 enabled. Currently, only the BDB and the HDB databases provide
966 database-specific monitoring. The default depends on the
967 backend type.
968 overlay <overlay-name>
970 Add the specified overlay to this database. An overlay is a
971 piece of code that intercepts database operations in order to
972 extend or change them. Overlays are pushed onto a stack over the
973 database, and so they will execute in the reverse of the order
974 in which they were configured and the database itself will
975 receive control last of all. See the slapd.overlays(5) manual
976 page for an overview of the available overlays. Note that all
977 of the database's regular settings should be configured before
978 any overlay settings.
979 readonly on | off
981 This option puts the database into "read-only" mode. Any
982 attempts to modify the database will return an "unwilling to
983 perform" error. By default, readonly is off.
984 restrict <oplist>
986 Specify a whitespace separated list of operations that are
987 restricted. If defined inside a database specification,
988 restrictions apply only to that database, otherwise they are
989 global. Operations can be any of add, bind, compare, delete,
990 extended[=<OID>], modify, rename, search, or the special pseudo-
991 operations read and write, which respectively summarize read and
992 write operations. The use of restrict write is equivalent to
993 readonly on (see above). The extended keyword allows to
994 indicate the OID of the specific operation to be restricted.
995 rootdn <dn>
997 Specify the distinguished name that is not subject to access
998 control or administrative limit restrictions for operations on
999 this database. This DN may or may not be associated with an
1000 entry. An empty root DN (the default) specifies no root access
1001 is to be granted. It is recommended that the rootdn only be
1002 specified when needed (such as when initially populating a
1003 database). If the rootdn is within a namingContext (suffix) of
1004 the database, a simple bind password may also be provided using
1005 the rootpw directive. Many optional features, including
1006 syncrepl, require the rootdn to be defined for the database.
1007 rootpw <password>
1009 Specify a password (or hash of the password) for the rootdn.
1010 The password can only be set if the rootdn is within the
1011 namingContext (suffix) of the database. This option accepts all
1012 RFC 2307 userPassword formats known to the server (see
1013 password-hash description) as well as cleartext. slappasswd(8)
1014 may be used to generate a hash of a password. Cleartext and
1015 {CRYPT} passwords are not recommended. If empty (the default),
1016 authentication of the root DN is by other means (e.g. SASL).
1017 Use of SASL is encouraged.
1018 suffix <dn suffix>
1020 Specify the DN suffix of queries that will be passed to this
1021 backend database. Multiple suffix lines can be given and at
1022 least one is required for each database definition.
1023 If the suffix of one database is "inside" that of another, the
1025 database with the inner suffix must come first in the
1026 configuration file. You may also want to glue such databases
1027 together with the subordinate keyword.
1028 subordinate [advertise]
1030 Specify that the current backend database is a subordinate of
1031 another backend database. A subordinate database may have only
1032 one suffix. This option may be used to glue multiple databases
1033 into a single namingContext. If the suffix of the current
1034 database is within the namingContext of a superior database,
1035 searches against the superior database will be propagated to the
1036 subordinate as well. All of the databases associated with a
1037 single namingContext should have identical rootdns. Behavior of
1038 other LDAP operations is unaffected by this setting. In
1039 particular, it is not possible to use moddn to move an entry
1040 from one subordinate to another subordinate within the
1041 namingContext.
1042 If the optional advertise flag is supplied, the naming context
1044 of this database is advertised in the root DSE. The default is
1045 to hide this database context, so that only the superior context
1046 is visible.
1047 If the slap tools slapcat(8), slapadd(8), or slapindex(8) are
1049 used on the superior database, any glued subordinates that
1050 support these tools are opened as well.
1051 Databases that are glued together should usually be configured
1053 with the same indices (assuming they support indexing), even for
1054 attributes that only exist in some of these databases. In
1055 general, all of the glued databases should be configured as
1056 similarly as possible, since the intent is to provide the
1057 appearance of a single directory.
1058 Note that the subordinate functionality is implemented
1060 internally by the glue overlay and as such its behavior will
1061 interact with other overlays in use. By default, the glue
1062 overlay is automatically configured as the last overlay on the
1063 superior backend. Its position on the backend can be explicitly
1064 configured by setting an overlay glue directive at the desired
1065 position. This explicit configuration is necessary e.g. when
1066 using the syncprov overlay, which needs to follow glue in order
1067 to work over all of the glued databases. E.g.
1068 database bdb
1069 suffix dc=example,dc=com
1070 ...
1071 overlay glue
1072 overlay syncprov
1073 sync_use_subentry
1075 Store the syncrepl contextCSN in a subentry instead of the
1076 context entry of the database. The subentry's RDN will be
1077 "cn=ldapsync". By default the contextCSN is stored in the
1078 context entry.
1079 syncrepl rid=<replica ID> provider=ldap[s]://<hostname>[:port]
1081 searchbase=<base DN> [type=refreshOnly|refreshAndPersist]
1082 [interval=dd:hh:mm:ss] [retry=[<retry interval> <# of
1083 retries>]+] [filter=<filter str>] [scope=sub|one|base|subord]
1084 [attrs=<attr list>] [attrsonly] [sizelimit=<limit>]
1085 [timelimit=<limit>] [schemachecking=on|off]
1086 [network-timeout=<seconds>] [timeout=<seconds>]
1087 [bindmethod=simple|sasl] [binddn=<dn>] [saslmech=<mech>]
1088 [authcid=<identity>] [authzid=<identity>] [credentials=<passwd>]
1089 [realm=<realm>] [secprops=<properties>]
1090 [keepalive=<idle>:<probes>:<interval>] [starttls=yes|critical]
1091 [tls_cert=<file>] [tls_key=<file>] [tls_cacert=<file>]
1092 [tls_cacertdir=<path>] [tls_reqcert=never|allow|try|demand]
1093 [tls_ciphersuite=<ciphers>] [tls_crlcheck=none|peer|all]
1094 [logbase=<base DN>] [logfilter=<filter str>]
1095 [syncdata=default|accesslog|changelog]
1096 Specify the current database as a replica which is kept up-to-
1097 date with the master content by establishing the current
1098 slapd(8) as a replication consumer site running a syncrepl
1099 replication engine. The replica content is kept synchronized to
1100 the master content using the LDAP Content Synchronization
1101 protocol. Refer to the "OpenLDAP Administrator's Guide" for
1102 detailed information on setting up a replicated slapd directory
1103 service using the syncrepl replication engine.
1104 rid identifies the current syncrepl directive within the
1106 replication consumer site. It is a non-negative integer not
1107 greater than 999 (limited to three decimal digits).
1108 provider specifies the replication provider site containing the
1110 master content as an LDAP URI. If <port> is not given, the
1111 standard LDAP port number (389 or 636) is used.
1112 The content of the syncrepl replica is defined using a search
1114 specification as its result set. The consumer slapd will send
1115 search requests to the provider slapd according to the search
1116 specification. The search specification includes searchbase,
1117 scope, filter, attrs, attrsonly, sizelimit, and timelimit
1118 parameters as in the normal search specification. The scope
1119 defaults to sub, the filter defaults to (objectclass=*), while
1120 there is no default searchbase. The attrs list defaults to "*,+"
1121 to return all user and operational attributes, and attrsonly is
1122 unset by default. The sizelimit and timelimit only accept
1123 "unlimited" and positive integers, and both default to
1124 "unlimited". The sizelimit and timelimit parameters define a
1125 consumer requested limitation on the number of entries that can
1126 be returned by the LDAP Content Synchronization operation; as
1127 such, it is intended to implement partial replication based on
1128 the size of the replicated database and on the time required by
1129 the synchronization. Note, however, that any provider-side
1130 limits for the replication identity will be enforced by the
1131 provider regardless of the limits requested by the LDAP Content
1132 Synchronization operation, much like for any other search
1133 operation.
1134 The LDAP Content Synchronization protocol has two operation
1136 types. In the refreshOnly operation, the next synchronization
1137 search operation is periodically rescheduled at an interval time
1138 (specified by interval parameter; 1 day by default) after each
1139 synchronization operation finishes. In the refreshAndPersist
1140 operation, a synchronization search remains persistent in the
1141 provider slapd. Further updates to the master replica will
1142 generate searchResultEntry to the consumer slapd as the search
1143 responses to the persistent synchronization search.
1144 If an error occurs during replication, the consumer will attempt
1146 to reconnect according to the retry parameter which is a list of
1147 the <retry interval> and <# of retries> pairs. For example,
1148 retry="60 10 300 3" lets the consumer retry every 60 seconds for
1149 the first 10 times and then retry every 300 seconds for the next
1150 3 times before stop retrying. The `+' in <# of retries> means
1151 indefinite number of retries until success. If no retry was
1152 specified, by default syncrepl retries every hour forever.
1153 The schema checking can be enforced at the LDAP Sync consumer
1155 site by turning on the schemachecking parameter. The default is
1156 off. Schema checking on means that replicated entries must have
1157 a structural objectClass, must obey to objectClass requirements
1158 in terms of required/allowed attributes, and that naming
1159 attributes and distinguished values must be present. As a
1160 consequence, schema checking should be off when partial
1161 replication is used.
1162 The network-timeout parameter sets how long the consumer will
1164 wait to establish a network connection to the provider. Once a
1165 connection is established, the timeout parameter determines how
1166 long the consumer will wait for the initial Bind request to
1167 complete. The defaults for these parameters come from
1168 ldap.conf(5).
1169 A bindmethod of simple requires the options binddn and
1171 credentials and should only be used when adequate security
1172 services (e.g. TLS or IPSEC) are in place. REMEMBER: simple
1173 bind credentials must be in cleartext! A bindmethod of sasl
1174 requires the option saslmech. Depending on the mechanism, an
1175 authentication identity and/or credentials can be specified
1176 using authcid and credentials. The authzid parameter may be
1177 used to specify an authorization identity. Specific security
1178 properties (as with the sasl-secprops keyword above) for a SASL
1179 bind can be set with the secprops option. A non default SASL
1180 realm can be set with the realm option. The identity used for
1181 synchronization by the consumer should be allowed to receive an
1182 unlimited number of entries in response to a search request.
1183 The provider, other than allow authentication of the syncrepl
1184 identity, should grant that identity appropriate access
1185 privileges to the data that is being replicated (access
1186 directive), and appropriate time and size limits. This can be
1187 accomplished by either allowing unlimited sizelimit and
1188 timelimit, or by setting an appropriate limits statement in the
1189 consumer's configuration (see sizelimit and limits for details).
1190 The keepalive parameter sets the values of idle, probes, and
1192 interval used to check whether a socket is alive; idle is the
1193 number of seconds a connection needs to remain idle before TCP
1194 starts sending keepalive probes; probes is the maximum number of
1195 keepalive probes TCP should send before dropping the connection;
1196 interval is interval in seconds between individual keepalive
1197 probes. Only some systems support the customization of these
1198 values; the keepalive parameter is ignored otherwise, and
1199 system-wide settings are used.
1200 The starttls parameter specifies use of the StartTLS extended
1202 operation to establish a TLS session before Binding to the
1203 provider. If the critical argument is supplied, the session will
1204 be aborted if the StartTLS request fails. Otherwise the syncrepl
1205 session continues without TLS. The tls_reqcert setting defaults
1206 to "demand" and the other TLS settings default to the same as
1207 the main slapd TLS settings.
1208 Rather than replicating whole entries, the consumer can query
1210 logs of data modifications. This mode of operation is referred
1211 to as delta syncrepl. In addition to the above parameters, the
1212 logbase and logfilter parameters must be set appropriately for
1213 the log that will be used. The syncdata parameter must be set to
1214 either "accesslog" if the log conforms to the slapo-accesslog(5)
1215 log format, or "changelog" if the log conforms to the obsolete
1216 changelog format. If the syncdata parameter is omitted or set to
1217 "default" then the log parameters are ignored.
1218 updatedn <dn>
1220 This option is only applicable in a slave database. It
1221 specifies the DN permitted to update (subject to access
1222 controls) the replica. It is only needed in certain push-mode
1223 replication scenarios. Generally, this DN should not be the
1224 same as the rootdn used at the master.
1225 updateref <url>
1227 Specify the referral to pass back when slapd(8) is asked to
1228 modify a replicated local database. If specified multiple
1229 times, each url is provided.
1230
1233 Each database may allow specific configuration options; they are
1234 documented separately in the backends' manual pages. See the
1235 slapd.backends(5) manual page for an overview of available backends.
1236
1238 Here is a short example of a configuration file:
1239 include /etc/openldap/schema/core.schema
1241 pidfile /var/run/slapd.pid
1242 # Subtypes of "name" (e.g. "cn" and "ou") with the
1244 # option ";x-hidden" can be searched for/compared,
1245 # but are not shown. See slapd.access(5).
1246 attributeoptions x-hidden lang-
1247 access to attrs=name;x-hidden by * =cs
1248 # Protect passwords. See slapd.access(5).
1250 access to attrs=userPassword by * auth
1251 # Read access to other attributes and entries.
1252 access to * by * read
1253 database bdb
1255 suffix "dc=our-domain,dc=com"
1256 # The database directory MUST exist prior to
1257 # running slapd AND should only be accessible
1258 # by the slapd/tools. Mode 0700 recommended.
1259 directory /var/openldap-data
1260 # Indices to maintain
1261 index objectClass eq
1262 index cn,sn,mail pres,eq,approx,sub
1263 # We serve small clients that do not handle referrals,
1265 # so handle remote lookups on their behalf.
1266 database ldap
1267 suffix ""
1268 uri ldap://ldap.some-server.com/
1269 lastmod off
1270 "OpenLDAP Administrator's Guide" contains a longer annotated example of
1272 a configuration file. The original /etc/openldap/slapd.conf is another
1273 example.
1274
1276 /etc/openldap/slapd.conf
1277 default slapd configuration file
1278
1280 ldap(3), slapd-config(5), slapd.access(5), slapd.backends(5),
1281 slapd.overlays(5), slapd.plugin(5), slapd(8), slapacl(8), slapadd(8),
1282 slapauth(8), slapcat(8), slapdn(8), slapindex(8), slappasswd(8),
1283 slaptest(8).
1284 "OpenLDAP Administrator's Guide" (http://www.OpenLDAP.org/doc/admin/)
1286
1288 OpenLDAP Software is developed and maintained by The OpenLDAP Project
1289 <http://www.openldap.org/>. OpenLDAP Software is derived from
1290 University of Michigan LDAP 3.3 Release.
1291OpenLDAP 2.4.23 2010/06/30 SLAPD.CONF(5)