1SLAPD-CONFIG(5) File Formats Manual SLAPD-CONFIG(5)
2
6 slapd-config - configuration backend to slapd
7
9 /etc/openldap/slapd.d
10
12 The config backend manages all of the configuration information for the
13 slapd(8) daemon. This configuration information is also used by the
14 SLAPD tools slapacl(8), slapadd(8), slapauth(8), slapcat(8), slapdn(8),
15 slapindex(8), slapmodify(8), and slaptest(8).
16 The config backend is backward compatible with the older slapd.conf(5)
18 file but provides the ability to change the configuration dynamically
19 at runtime. If slapd is run with only a slapd.conf file dynamic changes
20 will be allowed but they will not persist across a server restart. Dy‐
21 namic changes are only saved when slapd is running from a slapd.d con‐
22 figuration directory.
23 Unlike other backends, there can only be one instance of the config
25 backend, and most of its structure is predefined. The root of the data‐
26 base is hardcoded to cn=config and this root entry contains global set‐
27 tings for slapd. Multiple child entries underneath the root entry are
28 used to carry various other settings:
29 cn=Module
31 dynamically loaded modules
32 cn=Schema
34 schema definitions
35 olcBackend=xxx
37 backend-specific settings
38 olcDatabase=xxx
40 database-specific settings
41 The cn=Module entries will only appear in configurations where slapd
43 was built with support for dynamically loaded modules. There can be
44 multiple entries, one for each configured module path. Within each en‐
45 try there will be values recorded for each module loaded on a given
46 path. These entries have no children.
47 The cn=Schema entry contains all of the hardcoded schema elements. The
49 children of this entry contain all user-defined schema elements. In
50 schema that were loaded from include files, the child entry will be
51 named after the include file from which the schema was loaded. Typi‐
52 cally the first child in this subtree will be cn=core,cn=schema,cn=con‐
53 fig.
54 olcBackend entries are for storing settings specific to a single back‐
56 end type (and thus global to all database instances of that type). At
57 present, only back-mdb implements any options of this type, so this
58 setting is not needed for any other backends.
59 olcDatabase entries store settings specific to a single database in‐
61 stance. These entries may have olcOverlay child entries corresponding
62 to any overlays configured on the database. The olcDatabase and olcOv‐
63 erlay entries may also have miscellaneous child entries for other set‐
64 tings as needed. There are two special database entries that are prede‐
65 fined - one is an entry for the config database itself, and the other
66 is for the "frontend" database. Settings in the frontend database are
67 inherited by the other databases, unless they are explicitly overridden
68 in a specific database.
69 The specific configuration options available are discussed below in the
71 Global Configuration Options, General Backend Options, and General
72 Database Options. Options are set by defining LDAP attributes with spe‐
73 cific values. In general the names of the LDAP attributes are the same
74 as the corresponding slapd.conf keyword, with an "olc" prefix added on.
75 The parser for many of these attributes is the same as used for parsing
77 the slapd.conf keywords. As such, slapd.conf keywords that allow multi‐
78 ple items to be specified on one line, separated by whitespace, will
79 allow multiple items to be specified in one attribute value. However,
80 when reading the attribute via LDAP, the items will be returned as in‐
81 dividual attribute values.
82 Backend-specific options are discussed in the slapd-<backend>(5) manual
84 pages. Refer to the "OpenLDAP Administrator's Guide" for more details
85 on configuring slapd.
86
88 Options described in this section apply to the server as a whole. Ar‐
89 guments that should be replaced by actual text are shown in brackets
90 <>.
91 These options may only be specified in the cn=config entry. This entry
93 must have an objectClass of olcGlobal.
94 olcAllows: <features>
97 Specify a set of features to allow (default none). bind_v2 al‐
98 lows acceptance of LDAPv2 bind requests. Note that slapd(8)
99 does not truly implement LDAPv2 (RFC 1777), now Historic (RFC
100 3494). bind_anon_cred allows anonymous bind when credentials
101 are not empty (e.g. when DN is empty). bind_anon_dn allows
102 unauthenticated (anonymous) bind when DN is not empty. up‐
103 date_anon allows unauthenticated (anonymous) update operations
104 to be processed (subject to access controls and other adminis‐
105 trative limits). proxy_authz_anon allows unauthenticated
106 (anonymous) proxy authorization control to be processed (subject
107 to access controls, authorization and other administrative lim‐
108 its).
109 olcArgsFile: <filename>
111 The (absolute) name of a file that will hold the slapd server's
112 command line (program name and options).
113 olcAttributeOptions: <option-name>...
115 Define tagging attribute options or option tag/range prefixes.
116 Options must not end with `-', prefixes must end with `-'. The
117 `lang-' prefix is predefined. If you use the olcAttributeOp‐
118 tions directive, `lang-' will no longer be defined and you must
119 specify it explicitly if you want it defined.
120 An attribute description with a tagging option is a subtype of
122 that attribute description without the option. Except for that,
123 options defined this way have no special semantics. Prefixes
124 defined this way work like the `lang-' options: They define a
125 prefix for tagging options starting with the prefix. That is,
126 if you define the prefix `x-foo-', you can use the option
127 `x-foo-bar'. Furthermore, in a search or compare, a prefix or
128 range name (with a trailing `-') matches all options starting
129 with that name, as well as the option with the range name sans
130 the trailing `-'. That is, `x-foo-bar-' matches `x-foo-bar' and
131 `x-foo-bar-baz'.
132 RFC 4520 reserves options beginning with `x-' for private exper‐
134 iments. Other options should be registered with IANA, see RFC
135 4520 section 3.5. OpenLDAP also has the `binary' option built
136 in, but this is a transfer option, not a tagging option.
137 olcAuthIDRewrite: <rewrite-rule>
139 Used by the authentication framework to convert simple user
140 names to an LDAP DN used for authorization purposes. Its pur‐
141 pose is analogous to that of olcAuthzRegexp (see below). The
142 rewrite-rule is a set of rules analogous to those described in
143 slapo-rwm(5) for data rewriting (after stripping the rwm- pre‐
144 fix). olcAuthIDRewrite and olcAuthzRegexp should not be inter‐
145 mixed.
146 olcAuthzPolicy: <policy>
148 Used to specify which rules to use for Proxy Authorization.
149 Proxy authorization allows a client to authenticate to the
150 server using one user's credentials, but specify a different
151 identity to use for authorization and access control purposes.
152 It essentially allows user A to login as user B, using user A's
153 password. The none flag disables proxy authorization. This is
154 the default setting. The from flag will use rules in the au‐
155 thzFrom attribute of the authorization DN. The to flag will use
156 rules in the authzTo attribute of the authentication DN. The
157 any flag, an alias for the deprecated value of both, will allow
158 any of the above, whatever succeeds first (checked in to, from
159 sequence. The all flag requires both authorizations to succeed.
160 The rules are mechanisms to specify which identities are allowed
162 to perform proxy authorization. The authzFrom attribute in an
163 entry specifies which other users are allowed to proxy login to
164 this entry. The authzTo attribute in an entry specifies which
165 other users this user can authorize as. Use of authzTo rules
166 can be easily abused if users are allowed to write arbitrary
167 values to this attribute. In general the authzTo attribute must
168 be protected with ACLs such that only privileged users can mod‐
169 ify it. The value of authzFrom and authzTo describes an iden‐
170 tity or a set of identities; it can take five forms:
171 ldap:///<base>??[<scope>]?<filter>
173 dn[.<dnstyle>]:<pattern>
174 u[.<mech>[<realm>]]:<pattern>
175 group[/objectClass[/attributeType]]:<pattern>
176 <pattern>
177 <dnstyle>:={exact|onelevel|children|subtree|regex}
179 The first form is a valid LDAP URI where the <host>:<port>, the
181 <attrs> and the <extensions> portions must be absent, so that
182 the search occurs locally on either authzFrom or authzTo.
183 The second form is a DN, with the optional style modifiers ex‐
186 act, onelevel, children, and subtree for exact, onelevel, chil‐
187 dren and subtree matches, which cause <pattern> to be normalized
188 according to the DN normalization rules, or the special regex
189 style, which causes the <pattern> to be treated as a POSIX
190 (''extended'') regular expression, as discussed in regex(7)
191 and/or re_format(7). A pattern of * means any non-anonymous DN.
192 The third form is a SASL id, with the optional fields <mech> and
195 <realm> that allow to specify a SASL mechanism, and eventually a
196 SASL realm, for those mechanisms that support one. The need to
197 allow the specification of a mechanism is still debated, and
198 users are strongly discouraged to rely on this possibility.
199 The fourth form is a group specification. It consists of the
202 keyword group, optionally followed by the specification of the
203 group objectClass and attributeType. The objectClass defaults
204 to groupOfNames. The attributeType defaults to member. The
205 group with DN <pattern> is searched with base scope, filtered on
206 the specified objectClass. The values of the resulting at‐
207 tributeType are searched for the asserted DN.
208 The fifth form is provided for backwards compatibility. If no
211 identity type is provided, i.e. only <pattern> is present, an
212 exact DN is assumed; as a consequence, <pattern> is subjected to
213 DN normalization.
214 Since the interpretation of authzFrom and authzTo can impact se‐
217 curity, users are strongly encouraged to explicitly set the type
218 of identity specification that is being used. A subset of these
219 rules can be used as third arg in the olcAuthzRegexp statement
220 (see below); significantly, the URI, provided it results in ex‐
221 actly one entry, and the dn.exact:<dn> forms.
222 olcAuthzRegexp: <match> <replace>
224 Used by the authentication framework to convert simple user
225 names, such as provided by SASL subsystem, or extracted from
226 certificates in case of cert-based SASL EXTERNAL, or provided
227 within the RFC 4370 "proxied authorization" control, to an LDAP
228 DN used for authorization purposes. Note that the resulting DN
229 need not refer to an existing entry to be considered valid.
230 When an authorization request is received from the SASL subsys‐
231 tem, the SASL USERNAME, REALM, and MECHANISM are taken, when
232 available, and combined into a name of the form
233 UID=<username>[[,CN=<realm>],CN=<mechanism>],CN=auth
235 This name is then compared against the match POSIX (''ex‐
237 tended'') regular expression, and if the match is successful,
238 the name is replaced with the replace string. If there are
239 wildcard strings in the match regular expression that are en‐
240 closed in parenthesis, e.g.
241 UID=([^,]*),CN=.*
243 then the portion of the name that matched the wildcard will be
245 stored in the numbered placeholder variable $1. If there are
246 other wildcard strings in parenthesis, the matching strings will
247 be in $2, $3, etc. up to $9. The placeholders can then be used
248 in the replace string, e.g.
249 UID=$1,OU=Accounts,DC=example,DC=com
251 The replaced name can be either a DN, i.e. a string prefixed by
253 "dn:", or an LDAP URI. If the latter, the server will use the
254 URI to search its own database(s) and, if the search returns ex‐
255 actly one entry, the name is replaced by the DN of that entry.
256 The LDAP URI must have no hostport, attrs, or extensions compo‐
257 nents, but the filter is mandatory, e.g.
258 ldap:///OU=Accounts,DC=example,DC=com??one?(UID=$1)
260 The protocol portion of the URI must be strictly ldap. Note
262 that this search is subject to access controls. Specifically,
263 the authentication identity must have "auth" access in the sub‐
264 ject.
265 Multiple olcAuthzRegexp values can be specified to allow for
267 multiple matching and replacement patterns. The matching pat‐
268 terns are checked in the order they appear in the attribute,
269 stopping at the first successful match.
270 olcConcurrency: <integer>
273 Specify a desired level of concurrency. Provided to the under‐
274 lying thread system as a hint. The default is not to provide
275 any hint. This setting is only meaningful on some platforms
276 where there is not a one to one correspondence between user
277 threads and kernel threads.
278 olcConnMaxPending: <integer>
280 Specify the maximum number of pending requests for an anonymous
281 session. If requests are submitted faster than the server can
282 process them, they will be queued up to this limit. If the limit
283 is exceeded, the session is closed. The default is 100.
284 olcConnMaxPendingAuth: <integer>
286 Specify the maximum number of pending requests for an authenti‐
287 cated session. The default is 1000.
288 olcDisallows: <features>
290 Specify a set of features to disallow (default none). bind_anon
291 disables acceptance of anonymous bind requests. Note that this
292 setting does not prohibit anonymous directory access (See "re‐
293 quire authc"). bind_simple disables simple (bind) authentica‐
294 tion. tls_2_anon disables forcing session to anonymous status
295 (see also tls_authc) upon StartTLS operation receipt. tls_authc
296 disallows the StartTLS operation if authenticated (see also
297 tls_2_anon). proxy_authz_non_critical disables acceptance of
298 the proxied authorization control (RFC4370) with criticality set
299 to FALSE. dontusecopy_non_critical disables acceptance of the
300 dontUseCopy control (a work in progress) with criticality set to
301 FALSE.
302 olcGentleHUP: { TRUE | FALSE }
304 A SIGHUP signal will only cause a 'gentle' shutdown-attempt:
305 Slapd will stop listening for new connections, but will not
306 close the connections to the current clients. Future write op‐
307 erations return unwilling-to-perform, though. Slapd terminates
308 when all clients have closed their connections (if they ever
309 do), or - as before - if it receives a SIGTERM signal. This can
310 be useful if you wish to terminate the server and start a new
311 slapd server with another database, without disrupting the cur‐
312 rently active clients. The default is FALSE. You may wish to
313 use olcIdleTimeout along with this option.
314 olcIdleTimeout: <integer>
316 Specify the number of seconds to wait before forcibly closing an
317 idle client connection. A setting of 0 disables this feature.
318 The default is 0. You may also want to set the olcWriteTimeout
319 option.
320 olcIndexHash64: { on | off }
322 Use a 64 bit hash for indexing. The default is to use 32 bit
323 hashes. These hashes are used for equality and substring index‐
324 ing. The 64 bit version may be needed to avoid index collisions
325 when the number of indexed values exceeds ~64 million. (Note
326 that substring indexing generates multiple index values per ac‐
327 tual attribute value.) Indices generated with 32 bit hashes are
328 incompatible with the 64 bit version, and vice versa. Any exist‐
329 ing databases must be fully reloaded when changing this setting.
330 This directive is only supported on 64 bit CPUs.
331 olcIndexIntLen: <integer>
333 Specify the key length for ordered integer indices. The most
334 significant bytes of the binary integer will be used for index
335 keys. The default value is 4, which provides exact indexing for
336 31 bit values. A floating point representation is used to index
337 too large values.
338 olcIndexSubstrIfMaxlen: <integer>
340 Specify the maximum length for subinitial and subfinal indices.
341 Only this many characters of an attribute value will be pro‐
342 cessed by the indexing functions; any excess characters are ig‐
343 nored. The default is 4.
344 olcIndexSubstrIfMinlen: <integer>
346 Specify the minimum length for subinitial and subfinal indices.
347 An attribute value must have at least this many characters in
348 order to be processed by the indexing functions. The default is
349 2.
350 olcIndexSubstrAnyLen: <integer>
352 Specify the length used for subany indices. An attribute value
353 must have at least this many characters in order to be pro‐
354 cessed. Attribute values longer than this length will be pro‐
355 cessed in segments of this length. The default is 4. The subany
356 index will also be used in subinitial and subfinal index lookups
357 when the filter string is longer than the olcIndexSubstrIfMaxlen
358 value.
359 olcIndexSubstrAnyStep: <integer>
361 Specify the steps used in subany index lookups. This value sets
362 the offset for the segments of a filter string that are pro‐
363 cessed for a subany index lookup. The default is 2. For example,
364 with the default values, a search using this filter "cn=*abcde‐
365 fgh*" would generate index lookups for "abcd", "cdef", and
366 "efgh".
367 Note: Indexing support depends on the particular backend in use. Also,
370 changing these settings will generally require deleting any indices
371 that depend on these parameters and recreating them with slapindex(8).
372 olcListenerThreads: <integer>
375 Specify the number of threads to use for the connection manager.
376 The default is 1 and this is typically adequate for up to 16 CPU
377 cores. The value should be set to a power of 2.
378 olcLocalSSF: <SSF>
380 Specifies the Security Strength Factor (SSF) to be given local
381 LDAP sessions, such as those to the ldapi:// listener. For a
382 description of SSF values, see olcSaslSecProps's minssf option
383 description. The default is 71.
384 olcLogFile: <filename>
386 Specify a file for recording slapd debug messages. By default
387 these messages only go to stderr, are not recorded anywhere
388 else, and are unrelated to messages exposed by the olcLogLevel
389 configuration parameter. Specifying a logfile copies messages to
390 both stderr and the logfile.
391 olcLogFileFormat: debug | syslog-utc | syslog-localtime
393 Specify the prefix format for messages written to the logfile.
394 The debug format is the normal format used for slapd debug mes‐
395 sages, with a timestamp in hexadecimal, followed by a thread ID.
396 The other options are to use syslog(3) style prefixes, with
397 timestamps either in UTC or in the local timezone. The default
398 is debug format.
399 olcLogFileOnly: TRUE | FALSE
401 Specify that debug messages should only go to the configured
402 logfile, and not to stderr.
403 olcLogFileRotate: <max> <Mbytes> <hours>
405 Specify automatic rotation for the configured logfile as the
406 maximum number of old logfiles to retain, a maximum size in
407 megabytes to allow a logfile to grow before rotation, and a max‐
408 imum age in hours for a logfile to be used before rotation. The
409 maximum number must be in the range 1-99. Setting Mbytes or
410 hours to zero disables the size or age check, respectively. At
411 least one of Mbytes or hours must be non-zero. By default no au‐
412 tomatic rotation will be performed.
413 olcLogLevel: <integer> [...]
415 Specify the level at which debugging statements and operation
416 statistics should be syslogged (currently logged to the sys‐
417 logd(8) LOG_LOCAL4 facility). They must be considered subsys‐
418 tems rather than increasingly verbose log levels. Some messages
419 with higher priority are logged regardless of the configured
420 loglevel as soon as any logging is configured. Log levels are
421 additive, and available levels are:
422 1 (0x1 trace) trace function calls
423 2 (0x2 packets) debug packet handling
424 4 (0x4 args) heavy trace debugging (function args)
425 8 (0x8 conns) connection management
426 16 (0x10 BER) print out packets sent and received
427 32 (0x20 filter) search filter processing
428 64 (0x40 config) configuration file processing
429 128 (0x80 ACL) access control list processing
430 256 (0x100 stats) connections, LDAP operations, re‐
431 sults (recommended)
432 512 (0x200 stats2) stats2 log entries sent
433 1024 (0x400 shell) print communication with shell back‐
434 ends
435 2048 (0x800 parse) entry parsing
436 16384 (0x4000 sync) LDAPSync replication
445 32768 (0x8000 none) only messages that get logged what‐
446 ever log level is set
447 The desired log level can be input as a single integer that com‐
448 bines the (ORed) desired levels, both in decimal or in hexadeci‐
449 mal notation, as a list of integers (that are ORed internally),
450 or as a list of the names that are shown between parenthesis,
451 such that
452 olcLogLevel: 129
454 olcLogLevel: 0x81
455 olcLogLevel: 128 1
456 olcLogLevel: 0x80 0x1
457 olcLogLevel: acl trace
458 are equivalent. The keyword any can be used as a shortcut to
460 enable logging at all levels (equivalent to -1). The keyword
461 none, or the equivalent integer representation, causes those
462 messages that are logged regardless of the configured ol‐
463 cLogLevel to be logged. In fact, if no olcLogLevel (or a 0
464 level) is defined, no logging occurs, so at least the none level
465 is required to have high priority messages logged.
466 Note that the packets, BER, and parse levels are only available
468 as debug output on stderr, and are not sent to syslog.
469 This setting defaults to stats. This level should usually also
471 be included when using other loglevels, to help analyze the
472 logs.
473 olcMaxFilterDepth: <integer>
475 Specify the maximum depth of nested filters in search requests.
476 The default is 1000.
477 olcPasswordCryptSaltFormat: <format>
479 Specify the format of the salt passed to crypt(3) when generat‐
480 ing {CRYPT} passwords (see olcPasswordHash) during processing of
481 LDAP Password Modify Extended Operations (RFC 3062).
482 This string needs to be in sprintf(3) format and may include one
484 (and only one) %s conversion. This conversion will be substi‐
485 tuted with a string of random characters from [A-Za-z0-9./].
486 For example, "%.2s" provides a two character salt and "$1$%.8s"
487 tells some versions of crypt(3) to use an MD5 algorithm and pro‐
488 vides 8 random characters of salt. The default is "%s", which
489 provides 31 characters of salt.
490 olcPidFile: <filename>
492 The (absolute) name of a file that will hold the slapd server's
493 process ID (see getpid(2)).
494 olcPluginLogFile: <filename>
496 The ( absolute ) name of a file that will contain log messages
497 from SLAPI plugins. See slapd.plugin(5) for details.
498 olcReferral: <url>
500 Specify the referral to pass back when slapd(8) cannot find a
501 local database to handle a request. If multiple values are
502 specified, each url is provided.
503 olcReverseLookup: TRUE | FALSE
505 Enable/disable client name unverified reverse lookup (default is
506 FALSE if compiled with --enable-rlookups).
507 olcRootDSE: <file>
509 Specify the name of an LDIF(5) file containing user defined at‐
510 tributes for the root DSE. These attributes are returned in ad‐
511 dition to the attributes normally produced by slapd.
512 The root DSE is an entry with information about the server and
514 its capabilities, in operational attributes. It has the empty
515 DN, and can be read with e.g.:
516 ldapsearch -x -b "" -s base "+"
517 See RFC 4512 section 5.1 for details.
518 olcSaslAuxprops: <plugin> [...]
520 Specify which auxprop plugins to use for authentication lookups.
521 The default is empty, which just uses slapd's internal support.
522 Usually no other auxprop plugins are needed.
523 olcSaslAuxpropsDontUseCopy: <attr> [...]
525 Specify which attribute(s) should be subject to the don't use
526 copy control. This is necessary for some SASL mechanisms such as
527 OTP to work in a replicated environment. The attribute
528 "cmusaslsecretOTP" is the default value.
529 olcSaslAuxpropsDontUseCopyIgnore TRUE | FALSE
531 Used to disable replication of the attribute(s) defined by olc‐
532 SaslAuxpropsDontUseCopy and instead use a local value for the
533 attribute. This allows the SASL mechanism to continue to work if
534 the provider is offline. This can cause replication inconsis‐
535 tency. Defaults to FALSE.
536 olcSaslHost: <fqdn>
538 Used to specify the fully qualified domain name used for SASL
539 processing.
540 olcSaslRealm: <realm>
542 Specify SASL realm. Default is empty.
543 olcSaslCbinding: none | tls-unique | tls-endpoint
545 Specify the channel-binding type, see also
546 LDAP_OPT_X_SASL_CBINDING. Default is none.
547 olcSaslSecProps: <properties>
549 Used to specify Cyrus SASL security properties. The none flag
550 (without any other properties) causes the flag properties de‐
551 fault, "noanonymous,noplain", to be cleared. The noplain flag
552 disables mechanisms susceptible to simple passive attacks. The
553 noactive flag disables mechanisms susceptible to active attacks.
554 The nodict flag disables mechanisms susceptible to passive dic‐
555 tionary attacks. The noanonymous flag disables mechanisms which
556 support anonymous login. The forwardsec flag require forward
557 secrecy between sessions. The passcred require mechanisms which
558 pass client credentials (and allow mechanisms which can pass
559 credentials to do so). The minssf=<factor> property specifies
560 the minimum acceptable security strength factor as an integer
561 approximate to effective key length used for encryption. 0
562 (zero) implies no protection, 1 implies integrity protection
563 only, 128 allows RC4, Blowfish and other similar ciphers, 256
564 will require modern ciphers. The default is 0. The
565 maxssf=<factor> property specifies the maximum acceptable secu‐
566 rity strength factor as an integer (see minssf description).
567 The default is INT_MAX. The maxbufsize=<size> property speci‐
568 fies the maximum security layer receive buffer size allowed. 0
569 disables security layers. The default is 65536.
570 olcServerID: <integer> [<URL>]
572 Specify an integer ID from 0 to 4095 for this server. The ID may
573 also be specified as a hexadecimal ID by prefixing the value
574 with "0x". Non-zero IDs are required when using multi-provider
575 replication and each provider must have a unique non-zero ID.
576 Note that this requirement also applies to separate providers
577 contributing to a glued set of databases. If the URL is pro‐
578 vided, this directive may be specified multiple times, providing
579 a complete list of participating servers and their IDs. The
580 fully qualified hostname of each server should be used in the
581 supplied URLs. The IDs are used in the "replica id" field of all
582 CSNs generated by the specified server. The default value is
583 zero, which is only valid for single provider replication. Ex‐
584 ample:
585 olcServerID: 1 ldap://ldap1.example.com
587 olcServerID: 2 ldap://ldap2.example.com
588 olcSockbufMaxIncoming: <integer>
590 Specify the maximum incoming LDAP PDU size for anonymous ses‐
591 sions. The default is 262143.
592 olcSockbufMaxIncomingAuth: <integer>
594 Specify the maximum incoming LDAP PDU size for authenticated
595 sessions. The default is 4194303.
596 olcTCPBuffer [listener=<URL>] [{read|write}=]<size>
598 Specify the size of the TCP buffer. A global value for both
599 read and write TCP buffers related to any listener is defined,
600 unless the listener is explicitly specified, or either the read
601 or write qualifiers are used. See tcp(7) for details. Note
602 that some OS-es implement automatic TCP buffer tuning.
603 olcThreads: <integer>
605 Specify the maximum size of the primary thread pool. The de‐
606 fault is 16; the minimum value is 2.
607 olcThreadQueues: <integer>
609 Specify the number of work queues to use for the primary thread
610 pool. The default is 1 and this is typically adequate for up to
611 8 CPU cores. The value should not exceed the number of CPUs in
612 the system.
613 olcToolThreads: <integer>
615 Specify the maximum number of threads to use in tool mode. This
616 should not be greater than the number of CPUs in the system.
617 The default is 1.
618 olcWriteTimeout: <integer>
620 Specify the number of seconds to wait before forcibly closing a
621 connection with an outstanding write. This allows recovery from
622 various network hang conditions. A setting of 0 disables this
623 feature. The default is 0.
624
626 If slapd is built with support for Transport Layer Security, there are
627 more options you can specify.
628 When using OpenSSL, if neither olcTLSCACertificateFile nor olcTLSCAC‐
630 ertificatePath is set, the system-wide default set of CA certificates
631 is used.
632 olcTLSCipherSuite: <cipher-suite-spec>
634 Permits configuring what ciphers will be accepted and the pref‐
635 erence order. <cipher-suite-spec> should be a cipher specifica‐
636 tion for the TLS library in use (OpenSSL or GnuTLS). Example:
637 OpenSSL:
639 olcTLSCipherSuite: HIGH:MEDIUM:+SSLv2
640 GnuTLS:
642 olcTLSCiphersuite: SECURE256:!AES-128-CBC
643 To check what ciphers a given spec selects in OpenSSL, use:
645 openssl ciphers -v <cipher-suite-spec>
647 With GnuTLS the available specs can be found in the manual page
649 of gnutls-cli(1) (see the description of the option --priority).
650 In older versions of GnuTLS, where gnutls-cli does not support
652 the option --priority, you can obtain the — more limited — list
653 of ciphers by calling:
654 gnutls-cli -l
656 olcTLSCACertificateFile: <filename>
658 Specifies the file that contains certificates for all of the
659 Certificate Authorities that slapd will recognize. The certifi‐
660 cate for the CA that signed the server certificate must be in‐
661 cluded among these certificates. If the signing CA was not a
662 top-level (root) CA, certificates for the entire sequence of
663 CA's from the signing CA to the top-level CA should be present.
664 Multiple certificates are simply appended to the file; the order
665 is not significant.
666 olcTLSCACertificatePath: <path>
668 Specifies the path of directories that contain Certificate Au‐
669 thority certificates in separate individual files. Usually only
670 one of this or the olcTLSCACertificateFile is defined. If both
671 are specified, both locations will be used. Multiple directories
672 may be specified, separated by a semi-colon.
673 olcTLSCertificateFile: <filename>
675 Specifies the file that contains the slapd server certificate.
676 When using OpenSSL that file may also contain any number of in‐
678 termediate certificates after the server certificate.
679 olcTLSCertificateKeyFile: <filename>
681 Specifies the file that contains the slapd server private key
682 that matches the certificate stored in the olcTLSCertificateFile
683 file. If the private key is protected with a password, the pass‐
684 word must be manually typed in when slapd starts. Usually the
685 private key is not protected with a password, to allow slapd to
686 start without manual intervention, so it is of critical impor‐
687 tance that the file is protected carefully.
688 olcTLSDHParamFile: <filename>
690 This directive specifies the file that contains parameters for
691 Diffie-Hellman ephemeral key exchange. This is required in or‐
692 der to use a DSA certificate on the server, or an RSA certifi‐
693 cate missing the "key encipherment" key usage. Note that set‐
694 ting this option may also enable Anonymous Diffie-Hellman key
695 exchanges in certain non-default cipher suites. Anonymous key
696 exchanges should generally be avoided since they provide no ac‐
697 tual client or server authentication and provide no protection
698 against man-in-the-middle attacks. You should append "!ADH" to
699 your cipher suites to ensure that these suites are not used.
700 olcTLSECName: <name>
702 Specify the name of the curve(s) to use for Elliptic curve
703 Diffie-Hellman ephemeral key exchange. This option is only used
704 for OpenSSL. This option is not used with GnuTLS; the curves
705 may be chosen in the GnuTLS ciphersuite specification.
706 olcTLSProtocolMin: <major>[.<minor>]
708 Specifies minimum SSL/TLS protocol version that will be negoti‐
709 ated. If the server doesn't support at least that version, the
710 SSL handshake will fail. To require TLS 1.x or higher, set this
711 option to 3.(x+1), e.g.,
712 olcTLSProtocolMin: 3.2
714 would require TLS 1.1. Specifying a minimum that is higher than
716 that supported by the OpenLDAP implementation will result in it
717 requiring the highest level that it does support. This direc‐
718 tive is ignored with GnuTLS.
719 olcTLSRandFile: <filename>
721 Specifies the file to obtain random bits from when /dev/[u]ran‐
722 dom is not available. Generally set to the name of the
723 EGD/PRNGD socket. The environment variable RANDFILE can also be
724 used to specify the filename. This directive is ignored with
725 GnuTLS.
726 olcTLSVerifyClient: <level>
728 Specifies what checks to perform on client certificates in an
729 incoming TLS session, if any. The <level> can be specified as
730 one of the following keywords:
731 never This is the default. slapd will not ask the client for a
733 certificate.
734 allow The client certificate is requested. If no certificate
736 is provided, the session proceeds normally. If a bad
737 certificate is provided, it will be ignored and the ses‐
738 sion proceeds normally.
739 try The client certificate is requested. If no certificate
741 is provided, the session proceeds normally. If a bad
742 certificate is provided, the session is immediately ter‐
743 minated.
744 demand | hard | true
746 These keywords are all equivalent, for compatibility rea‐
747 sons. The client certificate is requested. If no cer‐
748 tificate is provided, or a bad certificate is provided,
749 the session is immediately terminated.
750 Note that a valid client certificate is required in order
752 to use the SASL EXTERNAL authentication mechanism with a
753 TLS session. As such, a non-default olcTLSVerifyClient
754 setting must be chosen to enable SASL EXTERNAL authenti‐
755 cation.
756 olcTLSCRLCheck: <level>
758 Specifies if the Certificate Revocation List (CRL) of the CA
759 should be used to verify if the client certificates have not
760 been revoked. This requires olcTLSCACertificatePath parameter to
761 be set. This parameter is ignored with GnuTLS. <level> can be
762 specified as one of the following keywords:
763 none No CRL checks are performed
765 peer Check the CRL of the peer certificate
767 all Check the CRL for a whole certificate chain
769 olcTLSCRLFile: <filename>
771 Specifies a file containing a Certificate Revocation List to be
772 used for verifying that certificates have not been revoked. This
773 parameter is only valid when using GnuTLS.
774
776 If slapd is compiled with --enable-modules then the module-related en‐
777 tries will be available. These entries are named cn=module{x},cn=config
778 and must have the olcModuleList objectClass. One entry should be cre‐
779 ated per olcModulePath. Normally the config engine generates the "{x}"
780 index in the RDN automatically, so it can be omitted when initially
781 loading these entries.
782 olcModuleLoad: <filename> [<arguments>...]
784 Specify the name of a dynamically loadable module to load and
785 any additional arguments if supported by the module. The file‐
786 name may be an absolute path name or a simple filename. Non-ab‐
787 solute names are searched for in the directories specified by
788 the olcModulePath option.
789 olcModulePath: <pathspec>
791 Specify a list of directories to search for loadable modules.
792 Typically the path is colon-separated but this depends on the
793 operating system. The default is /usr/lib64/openldap, which is
794 where the standard OpenLDAP install will place its modules.
795
797 Schema definitions are created as entries in the cn=schema,cn=config
798 subtree. These entries must have the olcSchemaConfig objectClass. As
799 noted above, the actual cn=schema,cn=config entry is predefined and any
800 values specified for it are ignored.
801 olcAttributetypes: ( <oid> [NAME <name>] [DESC <description>]
804 [OBSOLETE] [SUP <oid>] [EQUALITY <oid>] [ORDERING <oid>]
805 [SUBSTR <oid>] [SYNTAX <oidlen>] [SINGLE-VALUE] [COLLECTIVE]
806 [NO-USER-MODIFICATION] [USAGE <attributeUsage>] )
807 Specify an attribute type using the LDAPv3 syntax defined in RFC
808 4512. The slapd parser extends the RFC 4512 definition by
809 allowing string forms as well as numeric OIDs to be used for the
810 attribute OID and attribute syntax OID. (See the
811 olcObjectIdentifier description.)
812 olcDitContentRules: ( <oid> [NAME <name>] [DESC <description>]
815 [OBSOLETE] [AUX <oids>] [MUST <oids>] [MAY <oids>]
816 [NOT <oids>] )
817 Specify an DIT Content Rule using the LDAPv3 syntax defined in
818 RFC 4512. The slapd parser extends the RFC 4512 definition by
819 allowing string forms as well as numeric OIDs to be used for the
820 attribute OID and attribute syntax OID. (See the
821 olcObjectIdentifier description.)
822 olcLdapSyntaxes ( <oid> [DESC <description>] [X-SUBST <substitute-
825 syntax>] )
826 Specify an LDAP syntax using the LDAPv3 syntax defined in RFC
827 4512. The slapd parser extends the RFC 4512 definition by
828 allowing string forms as well as numeric OIDs to be used for the
829 syntax OID. (See the objectidentifier description.) The slapd
830 parser also honors the X-SUBST extension (an OpenLDAP-specific
831 extension), which allows one to use the olcLdapSyntaxes
832 attribute to define a non-implemented syntax along with another
833 syntax, the extension value substitute-syntax, as its temporary
834 replacement. The substitute-syntax must be defined. This
835 allows one to define attribute types that make use of non-
836 implemented syntaxes using the correct syntax OID. Unless
837 X-SUBST is used, this configuration statement would result in an
838 error, since no handlers would be associated to the resulting
839 syntax structure.
840 olcObjectClasses: ( <oid> [NAME <name>] [DESC <description>] [OBSOLETE]
843 [SUP <oids>] [{ ABSTRACT | STRUCTURAL | AUXILIARY }]
844 [MUST <oids>] [MAY <oids>] )
845 Specify an objectclass using the LDAPv3 syntax defined in RFC
846 4512. The slapd parser extends the RFC 4512 definition by
847 allowing string forms as well as numeric OIDs to be used for the
848 object class OID. (See the olcObjectIdentifier description.)
849 Object classes are "STRUCTURAL" by default.
850 olcObjectIdentifier: <name> { <oid> | <name>[:<suffix>] }
852 Define a string name that equates to the given OID. The string
853 can be used in place of the numeric OID in objectclass and
854 attribute definitions. The name can also be used with a suffix
855 of the form ":xx" in which case the value "oid.xx" will be used.
856
859 Options in these entries only apply to the configuration of a single
860 type of backend. All backends may support this class of options, but
861 currently only back-mdb does. The entry must be named
862 olcBackend=<databasetype>,cn=config and must have the olcBackendConfig
863 objectClass. <databasetype> should be one of asyncmeta, config,
864 dnssrv, ldap, ldif, mdb, meta, monitor, null, passwd, perl, relay,
865 sock, sql, or wt. At present, only back-mdb implements any options of
866 this type, so this entry should not be used for any other backends.
867
870 Database options are set in entries named
871 olcDatabase={x}<databasetype>,cn=config and must have the
872 olcDatabaseConfig objectClass. Normally the config engine generates the
873 "{x}" index in the RDN automatically, so it can be omitted when
874 initially loading these entries.
875 The special frontend database is always numbered "{-1}" and the config
877 database is always numbered "{0}".
878
881 Options in this section may be set in the special "frontend" database
882 and inherited in all the other databases. These options may be altered
883 by further settings in each specific database. The frontend entry must
884 be named olcDatabase=frontend,cn=config and must have the
885 olcFrontendConfig objectClass.
886 olcAccess: to <what> [ by <who> <access> <control> ]+
888 Grant access (specified by <access>) to a set of entries and/or
889 attributes (specified by <what>) by one or more requestors
890 (specified by <who>). If no access controls are present, the
891 default policy allows anyone and everyone to read anything but
892 restricts updates to rootdn. (e.g., "olcAccess: to * by *
893 read"). See slapd.access(5) and the "OpenLDAP Administrator's
894 Guide" for details.
895 Access controls set in the frontend are appended to any access
897 controls set on the specific databases. The rootdn of a
898 database can always read and write EVERYTHING in that database.
899 Extra special care must be taken with the access controls on the
901 config database. Unlike other databases, the default policy for
902 the config database is to only allow access to the rootdn.
903 Regular users should not have read access, and write access
904 should be granted very carefully to privileged administrators.
905 olcDefaultSearchBase: <dn>
908 Specify a default search base to use when client submits a non-
909 base search request with an empty base DN. Base scoped search
910 requests with an empty base DN are not affected. This setting
911 is only allowed in the frontend entry.
912 olcExtraAttrs: <attr>
914 Lists what attributes need to be added to search requests.
915 Local storage backends return the entire entry to the frontend.
916 The frontend takes care of only returning the requested
917 attributes that are allowed by ACLs. However, features like
918 access checking and so may need specific attributes that are not
919 automatically returned by remote storage backends, like proxy
920 backends and so on. <attr> is an attribute that is needed for
921 internal purposes and thus always needs to be collected, even
922 when not explicitly requested by clients. This attribute is
923 multi-valued.
924 olcPasswordHash: <hash> [<hash>...]
926 This option configures one or more hashes to be used in
927 generation of user passwords stored in the userPassword
928 attribute during processing of LDAP Password Modify Extended
929 Operations (RFC 3062). The <hash> must be one of {SSHA}, {SHA},
930 {SMD5}, {MD5}, {CRYPT}, and {CLEARTEXT}. The default is {SSHA}.
931 {SHA} and {SSHA} use the SHA-1 algorithm (FIPS 160-1), the
933 latter with a seed.
934 {MD5} and {SMD5} use the MD5 algorithm (RFC 1321), the latter
936 with a seed.
937 {CRYPT} uses the crypt(3).
939 {CLEARTEXT} indicates that the new password should be added to
941 userPassword as clear text.
942 Note that this option does not alter the normal user
944 applications handling of userPassword during LDAP Add, Modify,
945 or other LDAP operations. This setting is only allowed in the
946 frontend entry.
947 olcReadOnly: TRUE | FALSE
949 This option puts the database into "read-only" mode. Any
950 attempts to modify the database will return an "unwilling to
951 perform" error. By default, olcReadOnly is FALSE. Note that
952 when this option is set TRUE on the frontend, it cannot be reset
953 without restarting the server, since further writes to the
954 config database will be rejected.
955 olcRequires: <conditions>
957 Specify a set of conditions to require (default none). The
958 directive may be specified globally and/or per-database;
959 databases inherit global conditions, so per-database
960 specifications are additive. bind requires bind operation prior
961 to directory operations. LDAPv3 requires session to be using
962 LDAP version 3. authc requires authentication prior to
963 directory operations. SASL requires SASL authentication prior
964 to directory operations. strong requires strong authentication
965 prior to directory operations. The strong keyword allows
966 protected "simple" authentication as well as SASL
967 authentication. none may be used to require no conditions
968 (useful to clear out globally set conditions within a particular
969 database); it must occur first in the list of conditions.
970 olcRestrict: <oplist>
972 Specify a list of operations that are restricted. Restrictions
973 on a specific database override any frontend setting.
974 Operations can be any of add, bind, compare, delete,
975 extended[=<OID>], modify, rename, search, or the special pseudo-
976 operations read and write, which respectively summarize read and
977 write operations. The use of restrict write is equivalent to
978 olcReadOnly: TRUE (see above). The extended keyword allows one
979 to indicate the OID of the specific operation to be restricted.
980 olcSchemaDN: <dn>
982 Specify the distinguished name for the subschema subentry that
983 controls the entries on this server. The default is
984 "cn=Subschema".
985 olcSecurity: <factors>
987 Specify a set of security strength factors (separated by white
988 space) to require (see olcSaslSecprops's minssf option for a
989 description of security strength factors). The directive may be
990 specified globally and/or per-database. ssf=<n> specifies the
991 overall security strength factor. transport=<n> specifies the
992 transport security strength factor. tls=<n> specifies the TLS
993 security strength factor. sasl=<n> specifies the SASL security
994 strength factor. update_ssf=<n> specifies the overall security
995 strength factor to require for directory updates.
996 update_transport=<n> specifies the transport security strength
997 factor to require for directory updates. update_tls=<n>
998 specifies the TLS security strength factor to require for
999 directory updates. update_sasl=<n> specifies the SASL security
1000 strength factor to require for directory updates.
1001 simple_bind=<n> specifies the security strength factor required
1002 for simple username/password authentication. Note that the
1003 transport factor is measure of security provided by the
1004 underlying transport, e.g. ldapi:// (and eventually IPSEC). It
1005 is not normally used.
1006 olcSizeLimit: {<integer>|unlimited}
1008 olcSizeLimit: size[.{soft|hard}]=<integer> [...]
1010 Specify the maximum number of entries to return from a search
1011 operation. The default size limit is 500. Use unlimited to
1012 specify no limits. The second format allows a fine grain
1013 setting of the size limits. If no special qualifiers are
1014 specified, both soft and hard limits are set. Extra args can be
1015 added in the same value. Additional qualifiers are available;
1016 see olcLimits for an explanation of all of the different flags.
1017 olcSortVals: <attr> [...]
1019 Specify a list of multi-valued attributes whose values will
1020 always be maintained in sorted order. Using this option will
1021 allow Modify, Compare, and filter evaluations on these
1022 attributes to be performed more efficiently. The resulting sort
1023 order depends on the attributes' syntax and matching rules and
1024 may not correspond to lexical order or any other recognizable
1025 order. This setting is only allowed in the frontend entry.
1026 olcTimeLimit: {<integer>|unlimited}
1028 olcTimeLimit: time[.{soft|hard}]=<integer> [...]
1030 Specify the maximum number of seconds (in real time) slapd will
1031 spend answering a search request. The default time limit is
1032 3600. Use unlimited to specify no limits. The second format
1033 allows a fine grain setting of the time limits. Extra args can
1034 be added in the same value. See olcLimits for an explanation of
1035 the different flags.
1036
1039 Options in this section only apply to the specific database for which
1040 they are defined. They are supported by every type of backend. All of
1041 the Global Database Options may also be used here.
1042 olcAddContentAcl: TRUE | FALSE
1044 Controls whether Add operations will perform ACL checks on the
1045 content of the entry being added. This check is off by default.
1046 See the slapd.access(5) manual page for more details on ACL
1047 requirements for Add operations.
1048 olcHidden: TRUE | FALSE
1050 Controls whether the database will be used to answer queries. A
1051 database that is hidden will never be selected to answer any
1052 queries, and any suffix configured on the database will be
1053 ignored in checks for conflicts with other databases. By
1054 default, olcHidden is FALSE.
1055 olcLastMod: TRUE | FALSE
1057 Controls whether slapd will automatically maintain the
1058 modifiersName, modifyTimestamp, creatorsName, and
1059 createTimestamp attributes for entries. It also controls the
1060 entryCSN and entryUUID attributes, which are needed by the
1061 syncrepl provider. By default, olcLastMod is TRUE.
1062 olcLastBind: TRUE | FALSE
1064 Controls whether slapd will automatically maintain the
1065 pwdLastSuccess attribute for entries. By default, olcLastBind is
1066 FALSE.
1067 olcLastBindPrecision: <integer>
1069 If olcLastBind is enabled, specifies how frequently
1070 pwdLastSuccess will be updated. More than integer seconds must
1071 have passed since the last successful bind. In a replicated
1072 environment with frequent bind activity it may be useful to set
1073 this to a large value.
1074 olcLimits: <selector> <limit> [<limit> [...]]
1076 Specify time and size limits based on the operation's initiator
1077 or base DN. The argument <selector> can be any of
1078 anonymous | users | [<dnspec>=]<pattern> |
1080 group[/oc[/at]]=<pattern>
1081 with
1083 <dnspec> ::= dn[.<type>][.<style>]
1085 <type> ::= self | this
1087 <style> ::= exact | base | onelevel | subtree | children
1089 | regex | anonymous
1090 DN type self is the default and means the bound user, while this
1092 means the base DN of the operation. The term anonymous matches
1093 all unauthenticated clients. The term users matches all
1094 authenticated clients; otherwise an exact dn pattern is assumed
1095 unless otherwise specified by qualifying the (optional) key
1096 string dn with exact or base (which are synonyms), to require an
1097 exact match; with onelevel, to require exactly one level of
1098 depth match; with subtree, to allow any level of depth match,
1099 including the exact match; with children, to allow any level of
1100 depth match, not including the exact match; regex explicitly
1101 requires the (default) match based on POSIX (''extended'')
1102 regular expression pattern. Finally, anonymous matches unbound
1103 operations; the pattern field is ignored. The same behavior is
1104 obtained by using the anonymous form of the <selector> clause.
1105 The term group, with the optional objectClass oc and
1106 attributeType at fields, followed by pattern, sets the limits
1107 for any DN listed in the values of the at attribute (default
1108 member) of the oc group objectClass (default groupOfNames) whose
1109 DN exactly matches pattern.
1110 The currently supported limits are size and time.
1112 The syntax for time limits is time[.{soft|hard}]=<integer>,
1114 where integer is the number of seconds slapd will spend
1115 answering a search request. If no time limit is explicitly
1116 requested by the client, the soft limit is used; if the
1117 requested time limit exceeds the hard limit, the value of the
1118 limit is used instead. If the hard limit is set to the keyword
1119 soft, the soft limit is used in either case; if it is set to the
1120 keyword unlimited, no hard limit is enforced. Explicit requests
1121 for time limits smaller or equal to the hard limit are honored.
1122 If no limit specifier is set, the value is assigned to the soft
1123 limit, and the hard limit is set to soft, to preserve the
1124 original behavior.
1125 The syntax for size limits is
1127 size[.{soft|hard|unchecked}]=<integer>, where integer is the
1128 maximum number of entries slapd will return answering a search
1129 request. If no size limit is explicitly requested by the
1130 client, the soft limit is used; if the requested size limit
1131 exceeds the hard limit, the value of the limit is used instead.
1132 If the hard limit is set to the keyword soft, the soft limit is
1133 used in either case; if it is set to the keyword unlimited, no
1134 hard limit is enforced. Explicit requests for size limits
1135 smaller or equal to the hard limit are honored. The unchecked
1136 specifier sets a limit on the number of candidates a search
1137 request is allowed to examine. The rationale behind it is that
1138 searches for non-properly indexed attributes may result in large
1139 sets of candidates, which must be examined by slapd(8) to
1140 determine whether they match the search filter or not. The
1141 unchecked limit provides a means to drop such operations before
1142 they are even started. If the selected candidates exceed the
1143 unchecked limit, the search will abort with Unwilling to
1144 perform. If it is set to the keyword unlimited, no limit is
1145 applied (the default). If it is set to disabled, the search is
1146 not even performed; this can be used to disallow searches for a
1147 specific set of users. If no limit specifier is set, the value
1148 is assigned to the soft limit, and the hard limit is set to
1149 soft, to preserve the original behavior.
1150 In case of no match, the global limits are used. The default
1152 values are the same as for olcSizeLimit and olcTimeLimit; no
1153 limit is set on unchecked.
1154 If pagedResults control is requested, the hard size limit is
1156 used by default, because the request of a specific page size is
1157 considered an explicit request for a limitation on the number of
1158 entries to be returned. However, the size limit applies to the
1159 total count of entries returned within the search, and not to a
1160 single page. Additional size limits may be enforced; the syntax
1161 is size.pr={<integer>|noEstimate|unlimited}, where integer is
1162 the max page size if no explicit limit is set; the keyword
1163 noEstimate inhibits the server from returning an estimate of the
1164 total number of entries that might be returned (note: the
1165 current implementation does not return any estimate). The
1166 keyword unlimited indicates that no limit is applied to the
1167 pagedResults control page size. The syntax
1168 size.prtotal={<integer>|hard|unlimited|disabled} allows one to
1169 set a limit on the total number of entries that the pagedResults
1170 control will return. By default it is set to the hard limit
1171 which will use the size.hard value. When set, integer is the
1172 max number of entries that the whole search with pagedResults
1173 control can return. Use unlimited to allow unlimited number of
1174 entries to be returned, e.g. to allow the use of the
1175 pagedResults control as a means to circumvent size limitations
1176 on regular searches; the keyword disabled disables the control,
1177 i.e. no paged results can be returned. Note that the total
1178 number of entries returned when the pagedResults control is
1179 requested cannot exceed the hard size limit of regular searches
1180 unless extended by the prtotal switch.
1181 The olcLimits statement is typically used to let an unlimited
1183 number of entries be returned by searches performed with the
1184 identity used by the consumer for synchronization purposes by
1185 means of the RFC 4533 LDAP Content Synchronization protocol (see
1186 olcSyncrepl for details).
1187 When using subordinate databases, it is necessary for any limits
1189 that are to be applied across the parent and its subordinates to
1190 be defined in both the parent and its subordinates. Otherwise
1191 the settings on the subordinate databases are not honored.
1192 olcMaxDerefDepth: <depth>
1194 Specifies the maximum number of aliases to dereference when
1195 trying to resolve an entry, used to avoid infinite alias loops.
1196 The default is 15.
1197 olcMultiProvider: TRUE | FALSE
1199 This option puts a consumer database into Multi-Provider mode.
1200 Update operations will be accepted from any user, not just the
1201 updatedn. The database must already be configured as a syncrepl
1202 consumer before this keyword may be set. This mode also requires
1203 a olcServerID (see above) to be configured. By default, this
1204 setting is FALSE.
1205 olcMonitoring: TRUE | FALSE
1207 This option enables database-specific monitoring in the entry
1208 related to the current database in the "cn=Databases,cn=Monitor"
1209 subtree of the monitor database, if the monitor database is
1210 enabled. Currently, only the MDB database provides database-
1211 specific monitoring. If monitoring is supported by the backend
1212 it defaults to TRUE, otherwise FALSE.
1213 olcPlugin: <plugin_type> <lib_path> <init_function> [<arguments>]
1215 Configure a SLAPI plugin. See the slapd.plugin(5) manpage for
1216 more details.
1217 olcRootDN: <dn>
1219 Specify the distinguished name that is not subject to access
1220 control or administrative limit restrictions for operations on
1221 this database. This DN may or may not be associated with an
1222 entry. An empty root DN (the default) specifies no root access
1223 is to be granted. It is recommended that the rootdn only be
1224 specified when needed (such as when initially populating a
1225 database). If the rootdn is within a namingContext (suffix) of
1226 the database, a simple bind password may also be provided using
1227 the olcRootPW directive. Many optional features, including
1228 syncrepl, require the rootdn to be defined for the database.
1229 The olcRootDN of the cn=config database defaults to cn=config
1230 itself.
1231 olcRootPW: <password>
1233 Specify a password (or hash of the password) for the rootdn.
1234 The password can only be set if the rootdn is within the
1235 namingContext (suffix) of the database. This option accepts all
1236 RFC 2307 userPassword formats known to the server (see
1237 olcPasswordHash description) as well as cleartext.
1238 slappasswd(8) may be used to generate a hash of a password.
1239 Cleartext and {CRYPT} passwords are not recommended. If empty
1240 (the default), authentication of the root DN is by other means
1241 (e.g. SASL). Use of SASL is encouraged.
1242 olcSubordinate: [TRUE | FALSE | advertise]
1244 Specify that the current backend database is a subordinate of
1245 another backend database. A subordinate database may have only
1246 one suffix. This option may be used to glue multiple databases
1247 into a single namingContext. If the suffix of the current
1248 database is within the namingContext of a superior database,
1249 searches against the superior database will be propagated to the
1250 subordinate as well. All of the databases associated with a
1251 single namingContext should have identical rootdns. Behavior of
1252 other LDAP operations is unaffected by this setting. In
1253 particular, it is not possible to use moddn to move an entry
1254 from one subordinate to another subordinate within the
1255 namingContext.
1256 If the optional advertise flag is supplied, the naming context
1258 of this database is advertised in the root DSE. The default is
1259 to hide this database context, so that only the superior context
1260 is visible.
1261 If the slap tools slapcat(8), slapadd(8), slapmodify(8), or
1263 slapindex(8) are used on the superior database, any glued
1264 subordinates that support these tools are opened as well.
1265 Databases that are glued together should usually be configured
1267 with the same indices (assuming they support indexing), even for
1268 attributes that only exist in some of these databases. In
1269 general, all of the glued databases should be configured as
1270 similarly as possible, since the intent is to provide the
1271 appearance of a single directory.
1272 Note that the subordinate functionality is implemented
1274 internally by the glue overlay and as such its behavior will
1275 interact with other overlays in use. By default, the glue
1276 overlay is automatically configured as the last overlay on the
1277 superior database. Its position on the database can be
1278 explicitly configured by setting an overlay glue directive at
1279 the desired position. This explicit configuration is necessary
1280 e.g. when using the syncprov overlay, which needs to follow
1281 glue in order to work over all of the glued databases. E.g.
1282 dn: olcDatabase={1}mdb,cn=config
1283 olcSuffix: dc=example,dc=com
1284 ...
1285 dn: olcOverlay={0}glue,olcDatabase={1}mdb,cn=config
1287 ...
1288 dn: olcOverlay={1}syncprov,olcDatabase={1}mdb,cn=config
1290 ...
1291 See the Overlays section below for more details.
1292 olcSuffix: <dn suffix>
1294 Specify the DN suffix of queries that will be passed to this
1295 backend database. Multiple suffix lines can be given and at
1296 least one is required for each database definition.
1297 If the suffix of one database is "inside" that of another, the
1299 database with the inner suffix must come first in the
1300 configuration file. You may also want to glue such databases
1301 together with the olcSubordinate attribute.
1302 olcSyncUseSubentry: TRUE | FALSE
1304 Store the syncrepl contextCSN in a subentry instead of the
1305 context entry of the database. The subentry's RDN will be
1306 "cn=ldapsync". The default is FALSE, meaning the contextCSN is
1307 stored in the context entry.
1308 olcSyncrepl: rid=<replica ID> provider=ldap[s]://<hostname>[:port]
1310 searchbase=<base DN> [type=refreshOnly|refreshAndPersist]
1311 [interval=dd:hh:mm:ss] [retry=[<retry interval> <# of
1312 retries>]+] [filter=<filter str>] [scope=sub|one|base|subord]
1313 [attrs=<attr list>] [exattrs=<attr list>] [attrsonly]
1314 [sizelimit=<limit>] [timelimit=<limit>] [schemachecking=on|off]
1315 [network-timeout=<seconds>] [timeout=<seconds>]
1316 [tcp-user-timeout=<milliseconds>] [bindmethod=simple|sasl]
1317 [binddn=<dn>] [saslmech=<mech>] [authcid=<identity>]
1318 [authzid=<identity>] [credentials=<passwd>] [realm=<realm>]
1319 [secprops=<properties>] [keepalive=<idle>:<probes>:<interval>]
1320 [starttls=yes|critical] [tls_cert=<file>] [tls_key=<file>]
1321 [tls_cacert=<file>] [tls_cacertdir=<path>]
1322 [tls_reqcert=never|allow|try|demand]
1323 [tls_reqsan=never|allow|try|demand] [tls_cipher_suite=<ciphers>]
1324 [tls_ecname=<names>] [tls_crlcheck=none|peer|all]
1325 [tls_protocol_min=<major>[.<minor>]] [suffixmassage=<real DN>]
1326 [logbase=<base DN>] [logfilter=<filter str>]
1327 [syncdata=default|accesslog|changelog] [lazycommit]
1328 Specify the current database as a consumer which is kept up-to-
1329 date with the provider content by establishing the current
1330 slapd(8) as a replication consumer site running a syncrepl
1331 replication engine. The consumer content is kept synchronized
1332 to the provider content using the LDAP Content Synchronization
1333 protocol. Refer to the "OpenLDAP Administrator's Guide" for
1334 detailed information on setting up a replicated slapd directory
1335 service using the syncrepl replication engine.
1336 rid identifies the current syncrepl directive within the
1338 replication consumer site. It is a non-negative integer not
1339 greater than 999 (limited to three decimal digits).
1340 provider specifies the replication provider site containing the
1342 provider content as an LDAP URI. If <port> is not given, the
1343 standard LDAP port number (389 or 636) is used.
1344 The content of the syncrepl consumer is defined using a search
1346 specification as its result set. The consumer slapd will send
1347 search requests to the provider slapd according to the search
1348 specification. The search specification includes searchbase,
1349 scope, filter, attrs, attrsonly, sizelimit, and timelimit
1350 parameters as in the normal search specification. The exattrs
1351 option may also be used to specify attributes that should be
1352 omitted from incoming entries. The scope defaults to sub, the
1353 filter defaults to (objectclass=*), and there is no default
1354 searchbase. The attrs list defaults to "*,+" to return all user
1355 and operational attributes, and attrsonly and exattrs are unset
1356 by default. The sizelimit and timelimit only accept "unlimited"
1357 and positive integers, and both default to "unlimited". The
1358 sizelimit and timelimit parameters define a consumer requested
1359 limitation on the number of entries that can be returned by the
1360 LDAP Content Synchronization operation; these should be left
1361 unchanged from the default otherwise replication may never
1362 succeed. Note, however, that any provider-side limits for the
1363 replication identity will be enforced by the provider regardless
1364 of the limits requested by the LDAP Content Synchronization
1365 operation, much like for any other search operation.
1366 The LDAP Content Synchronization protocol has two operation
1368 types. In the refreshOnly operation, the next synchronization
1369 search operation is periodically rescheduled at an interval time
1370 (specified by interval parameter; 1 day by default) after each
1371 synchronization operation finishes. In the refreshAndPersist
1372 operation, a synchronization search remains persistent in the
1373 provider slapd. Further updates to the provider will generate
1374 searchResultEntry to the consumer slapd as the search responses
1375 to the persistent synchronization search. If the initial search
1376 fails due to an error, the next synchronization search operation
1377 is periodically rescheduled at an interval time (specified by
1378 interval parameter; 1 day by default)
1379 If an error occurs during replication, the consumer will attempt
1381 to reconnect according to the retry parameter which is a list of
1382 the <retry interval> and <# of retries> pairs. For example,
1383 retry="60 10 300 3" lets the consumer retry every 60 seconds for
1384 the first 10 times and then retry every 300 seconds for the next
1385 3 times before stop retrying. The `+' in <# of retries> means
1386 indefinite number of retries until success. If no retry is
1387 specified, by default syncrepl retries every hour forever.
1388 The schema checking can be enforced at the LDAP Sync consumer
1390 site by turning on the schemachecking parameter. The default is
1391 off. Schema checking on means that replicated entries must have
1392 a structural objectClass, must obey to objectClass requirements
1393 in terms of required/allowed attributes, and that naming
1394 attributes and distinguished values must be present. As a
1395 consequence, schema checking should be off when partial
1396 replication is used.
1397 The network-timeout parameter sets how long the consumer will
1399 wait to establish a network connection to the provider. Once a
1400 connection is established, the timeout parameter determines how
1401 long the consumer will wait for the initial Bind request to
1402 complete. The defaults for these parameters come from
1403 ldap.conf(5). The tcp-user-timeout parameter, if non-zero,
1404 corresponds to the TCP_USER_TIMEOUT set on the target
1405 connections, overriding the operating system setting. Only some
1406 systems support the customization of this parameter, it is
1407 ignored otherwise and system-wide settings are used.
1408 A bindmethod of simple requires the options binddn and
1410 credentials and should only be used when adequate security
1411 services (e.g. TLS or IPSEC) are in place. REMEMBER: simple
1412 bind credentials must be in cleartext! A bindmethod of sasl
1413 requires the option saslmech. Depending on the mechanism, an
1414 authentication identity and/or credentials can be specified
1415 using authcid and credentials. The authzid parameter may be
1416 used to specify an authorization identity. Specific security
1417 properties (as with the sasl-secprops keyword above) for a SASL
1418 bind can be set with the secprops option. A non default SASL
1419 realm can be set with the realm option. The identity used for
1420 synchronization by the consumer should be allowed to receive an
1421 unlimited number of entries in response to a search request.
1422 The provider, other than allowing authentication of the syncrepl
1423 identity, should grant that identity appropriate access
1424 privileges to the data that is being replicated (access
1425 directive), and appropriate time and size limits. This can be
1426 accomplished by either allowing unlimited sizelimit and
1427 timelimit, or by setting an appropriate limits statement in the
1428 consumer's configuration (see sizelimit and limits for details).
1429 The keepalive parameter sets the values of idle, probes, and
1431 interval used to check whether a socket is alive; idle is the
1432 number of seconds a connection needs to remain idle before TCP
1433 starts sending keepalive probes; probes is the maximum number of
1434 keepalive probes TCP should send before dropping the connection;
1435 interval is interval in seconds between individual keepalive
1436 probes. Only some systems support the customization of these
1437 values; the keepalive parameter is ignored otherwise, and
1438 system-wide settings are used.
1439 The starttls parameter specifies use of the StartTLS extended
1441 operation to establish a TLS session before Binding to the
1442 provider. If the critical argument is supplied, the session will
1443 be aborted if the StartTLS request fails. Otherwise the syncrepl
1444 session continues without TLS. The tls_reqcert setting defaults
1445 to "demand", the tls_reqsan setting defaults to "allow", and the
1446 other TLS settings default to the same as the main slapd TLS
1447 settings.
1448 The suffixmassage parameter allows the consumer to pull entries
1450 from a remote directory whose DN suffix differs from the local
1451 directory. The portion of the remote entries' DNs that matches
1452 the searchbase will be replaced with the suffixmassage DN.
1453 Rather than replicating whole entries, the consumer can query
1455 logs of data modifications. This mode of operation is referred
1456 to as delta syncrepl. In addition to the above parameters, the
1457 logbase and logfilter parameters must be set appropriately for
1458 the log that will be used. The syncdata parameter must be set to
1459 either "accesslog" if the log conforms to the slapo-accesslog(5)
1460 log format, or "changelog" if the log conforms to the obsolete
1461 changelog format. If the syncdata parameter is omitted or set to
1462 "default" then the log parameters are ignored.
1463 The lazycommit parameter tells the underlying database that it
1465 can store changes without performing a full flush after each
1466 change. This may improve performance for the consumer, while
1467 sacrificing safety or durability.
1468 olcUpdateDN: <dn>
1470 This option is only applicable in a replica database. It
1471 specifies the DN permitted to update (subject to access
1472 controls) the replica. It is only needed in certain push-mode
1473 replication scenarios. Generally, this DN should not be the
1474 same as the rootdn used at the provider.
1475 olcUpdateRef: <url>
1477 Specify the referral to pass back when slapd(8) is asked to
1478 modify a replicated local database. If multiple values are
1479 specified, each url is provided.
1480
1483 Each database may allow specific configuration options; they are
1484 documented separately in the backends' manual pages. See the
1485 slapd.backends(5) manual page for an overview of available backends.
1486
1488 An overlay is a piece of code that intercepts database operations in
1489 order to extend or change them. Overlays are pushed onto a stack over
1490 the database, and so they will execute in the reverse of the order in
1491 which they were configured and the database itself will receive control
1492 last of all.
1493 Overlays must be configured as child entries of a specific database.
1495 The entry's RDN must be of the form olcOverlay={x}<overlaytype> and the
1496 entry must have the olcOverlayConfig objectClass. Normally the config
1497 engine generates the "{x}" index in the RDN automatically, so it can be
1498 omitted when initially loading these entries.
1499 See the slapd.overlays(5) manual page for an overview of available
1501 overlays.
1502
1504 Here is a short example of a configuration in LDIF suitable for use
1505 with slapadd(8) :
1506 dn: cn=config
1508 objectClass: olcGlobal
1509 cn: config
1510 olcPidFile: /var/run/slapd.pid
1511 olcAttributeOptions: x-hidden lang-
1512 dn: cn=schema,cn=config
1514 objectClass: olcSchemaConfig
1515 cn: schema
1516 include: file:///etc/openldap/schema/core.ldif
1518 dn: olcDatabase=frontend,cn=config
1520 objectClass: olcDatabaseConfig
1521 objectClass: olcFrontendConfig
1522 olcDatabase: frontend
1523 # Subtypes of "name" (e.g. "cn" and "ou") with the
1524 # option ";x-hidden" can be searched for/compared,
1525 # but are not shown. See slapd.access(5).
1526 olcAccess: to attrs=name;x-hidden by * =cs
1527 # Protect passwords. See slapd.access(5).
1528 olcAccess: to attrs=userPassword by * auth
1529 # Read access to other attributes and entries.
1530 olcAccess: to * by * read
1531 # set a rootpw for the config database so we can bind.
1533 # deny access to everyone else.
1534 dn: olcDatabase=config,cn=config
1535 objectClass: olcDatabaseConfig
1536 olcDatabase: config
1537 olcRootPW: {SSHA}XKYnrjvGT3wZFQrDD5040US592LxsdLy
1538 olcAccess: to * by * none
1539 dn: olcDatabase=mdb,cn=config
1541 objectClass: olcDatabaseConfig
1542 objectClass: olcMdbConfig
1543 olcDatabase: mdb
1544 olcSuffix: "dc=our-domain,dc=com"
1545 # The database directory MUST exist prior to
1546 # running slapd AND should only be accessible
1547 # by the slapd/tools. Mode 0700 recommended.
1548 olcDbDirectory: /var/openldap-data
1549 # Indices to maintain
1550 olcDbIndex: objectClass eq
1551 olcDbIndex: cn,sn,mail pres,eq,approx,sub
1552 # We serve small clients that do not handle referrals,
1554 # so handle remote lookups on their behalf.
1555 dn: olcDatabase=ldap,cn=config
1556 objectClass: olcDatabaseConfig
1557 objectClass: olcLdapConfig
1558 olcDatabase: ldap
1559 olcSuffix: ""
1560 olcDbUri: ldap://ldap.some-server.com/
1561 Assuming the above data was saved in a file named "config.ldif" and the
1563 /etc/openldap/slapd.d directory has been created, this command will
1564 initialize the configuration:
1565 slapadd -F /etc/openldap/slapd.d -n 0 -l config.ldif
1566 "OpenLDAP Administrator's Guide" contains a longer annotated example of
1569 a slapd configuration.
1570 Alternatively, an existing slapd.conf file can be converted to the new
1572 format using slapd or any of the slap tools:
1573 slaptest -f /etc/openldap/slapd.conf -F /etc/openldap/slapd.d
1574
1577 /etc/openldap/slapd.conf
1578 default slapd configuration file
1579 /etc/openldap/slapd.d
1581 default slapd configuration directory
1582
1584 ldap(3), ldif(5), gnutls-cli(1), slapd.access(5), slapd.backends(5),
1585 slapd.conf(5), slapd.overlays(5), slapd.plugin(5), slapd(8),
1586 slapacl(8), slapadd(8), slapauth(8), slapcat(8), slapdn(8),
1587 slapindex(8), slapmodify(8), slappasswd(8), slaptest(8).
1588 "OpenLDAP Administrator's Guide" (http://www.OpenLDAP.org/doc/admin/)
1590
1592 OpenLDAP Software is developed and maintained by The OpenLDAP Project
1593 <http://www.openldap.org/>. OpenLDAP Software is derived from the
1594 University of Michigan LDAP 3.3 Release.
1595OpenLDAP 2.6.3 2022/07/14 SLAPD-CONFIG(5)