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