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), 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 there are no backends that implement settings of this nature,
58 so usually there will not be any olcBackend entries.
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. The
183 second form is a DN, with the optional style modifiers exact,
184 onelevel, children, and subtree for exact, onelevel, children
185 and subtree matches, which cause <pattern> to be normalized ac‐
186 cording to the DN normalization rules, or the special regex
187 style, which causes the <pattern> to be treated as a POSIX
188 (''extended'') regular expression, as discussed in regex(7)
189 and/or re_format(7). A pattern of * means any non-anonymous DN.
190 The third form is a SASL id, with the optional fields <mech> and
191 <realm> that allow to specify a SASL mechanism, and eventually a
192 SASL realm, for those mechanisms that support one. The need to
193 allow the specification of a mechanism is still debated, and
194 users are strongly discouraged to rely on this possibility. The
195 fourth form is a group specification, consisting of the keyword
196 group, optionally followed by the specification of the group ob‐
197 jectClass and member attributeType. The group with DN <pattern>
198 is searched with base scope, and in case of match, the values of
199 the member attributeType are searched for the asserted DN. For
200 backwards compatibility, if no identity type is provided, i.e.
201 only <pattern> is present, an exact DN is assumed; as a conse‐
202 quence, <pattern> is subjected to DN normalization. Since the
203 interpretation of authzFrom and authzTo can impact security,
204 users are strongly encouraged to explicitly set the type of
205 identity specification that is being used. A subset of these
206 rules can be used as third arg in the olcAuthzRegexp statement
207 (see below); significantly, the URI and the dn.exact:<dn> forms.
208 olcAuthzRegexp: <match> <replace>
210 Used by the authentication framework to convert simple user
211 names, such as provided by SASL subsystem, to an LDAP DN used
212 for authorization purposes. Note that the resultant DN need not
213 refer to an existing entry to be considered valid. When an au‐
214 thorization request is received from the SASL subsystem, the
215 SASL USERNAME, REALM, and MECHANISM are taken, when available,
216 and combined into a name of the form
217 UID=<username>[[,CN=<realm>],CN=<mechanism>],CN=auth
219 This name is then compared against the match POSIX (''ex‐
221 tended'') regular expression, and if the match is successful,
222 the name is replaced with the replace string. If there are
223 wildcard strings in the match regular expression that are en‐
224 closed in parenthesis, e.g.
225 UID=([^,]*),CN=.*
227 then the portion of the name that matched the wildcard will be
229 stored in the numbered placeholder variable $1. If there are
230 other wildcard strings in parenthesis, the matching strings will
231 be in $2, $3, etc. up to $9. The placeholders can then be used
232 in the replace string, e.g.
233 UID=$1,OU=Accounts,DC=example,DC=com
235 The replaced name can be either a DN, i.e. a string prefixed by
237 "dn:", or an LDAP URI. If the latter, the server will use the
238 URI to search its own database(s) and, if the search returns ex‐
239 actly one entry, the name is replaced by the DN of that entry.
240 The LDAP URI must have no hostport, attrs, or extensions compo‐
241 nents, but the filter is mandatory, e.g.
242 ldap:///OU=Accounts,DC=example,DC=com??one?(UID=$1)
244 The protocol portion of the URI must be strictly ldap. Note
246 that this search is subject to access controls. Specifically,
247 the authentication identity must have "auth" access in the sub‐
248 ject.
249 Multiple olcAuthzRegexp values can be specified to allow for
251 multiple matching and replacement patterns. The matching pat‐
252 terns are checked in the order they appear in the attribute,
253 stopping at the first successful match.
254 olcConcurrency: <integer>
257 Specify a desired level of concurrency. Provided to the under‐
258 lying thread system as a hint. The default is not to provide
259 any hint. This setting is only meaningful on some platforms
260 where there is not a one to one correspondence between user
261 threads and kernel threads.
262 olcConnMaxPending: <integer>
264 Specify the maximum number of pending requests for an anonymous
265 session. If requests are submitted faster than the server can
266 process them, they will be queued up to this limit. If the limit
267 is exceeded, the session is closed. The default is 100.
268 olcConnMaxPendingAuth: <integer>
270 Specify the maximum number of pending requests for an authenti‐
271 cated session. The default is 1000.
272 olcDisallows: <features>
274 Specify a set of features to disallow (default none). bind_anon
275 disables acceptance of anonymous bind requests. Note that this
276 setting does not prohibit anonymous directory access (See "re‐
277 quire authc"). bind_simple disables simple (bind) authentica‐
278 tion. tls_2_anon disables forcing session to anonymous status
279 (see also tls_authc) upon StartTLS operation receipt. tls_authc
280 disallows the StartTLS operation if authenticated (see also
281 tls_2_anon).
282 olcGentleHUP: { TRUE | FALSE }
284 A SIGHUP signal will only cause a 'gentle' shutdown-attempt:
285 Slapd will stop listening for new connections, but will not
286 close the connections to the current clients. Future write op‐
287 erations return unwilling-to-perform, though. Slapd terminates
288 when all clients have closed their connections (if they ever
289 do), or - as before - if it receives a SIGTERM signal. This can
290 be useful if you wish to terminate the server and start a new
291 slapd server with another database, without disrupting the cur‐
292 rently active clients. The default is FALSE. You may wish to
293 use olcIdleTimeout along with this option.
294 olcIdleTimeout: <integer>
296 Specify the number of seconds to wait before forcibly closing an
297 idle client connection. A setting of 0 disables this feature.
298 The default is 0. You may also want to set the olcWriteTimeout
299 option.
300 olcIndexIntLen: <integer>
302 Specify the key length for ordered integer indices. The most
303 significant bytes of the binary integer will be used for index
304 keys. The default value is 4, which provides exact indexing for
305 31 bit values. A floating point representation is used to index
306 too large values.
307 olcIndexSubstrIfMaxlen: <integer>
309 Specify the maximum length for subinitial and subfinal indices.
310 Only this many characters of an attribute value will be pro‐
311 cessed by the indexing functions; any excess characters are ig‐
312 nored. The default is 4.
313 olcIndexSubstrIfMinlen: <integer>
315 Specify the minimum length for subinitial and subfinal indices.
316 An attribute value must have at least this many characters in
317 order to be processed by the indexing functions. The default is
318 2.
319 olcIndexSubstrAnyLen: <integer>
321 Specify the length used for subany indices. An attribute value
322 must have at least this many characters in order to be pro‐
323 cessed. Attribute values longer than this length will be pro‐
324 cessed in segments of this length. The default is 4. The subany
325 index will also be used in subinitial and subfinal index lookups
326 when the filter string is longer than the olcIndexSubstrIfMaxlen
327 value.
328 olcIndexSubstrAnyStep: <integer>
330 Specify the steps used in subany index lookups. This value sets
331 the offset for the segments of a filter string that are pro‐
332 cessed for a subany index lookup. The default is 2. For example,
333 with the default values, a search using this filter "cn=*abcde‐
334 fgh*" would generate index lookups for "abcd", "cdef", and
335 "efgh".
336 Note: Indexing support depends on the particular backend in use. Also,
339 changing these settings will generally require deleting any indices
340 that depend on these parameters and recreating them with slapindex(8).
341 olcListenerThreads: <integer>
344 Specify the number of threads to use for the connection manager.
345 The default is 1 and this is typically adequate for up to 16 CPU
346 cores. The value should be set to a power of 2.
347 olcLocalSSF: <SSF>
349 Specifies the Security Strength Factor (SSF) to be given local
350 LDAP sessions, such as those to the ldapi:// listener. For a
351 description of SSF values, see olcSaslSecProps's minssf option
352 description. The default is 71.
353 olcLogFile: <filename>
355 Specify a file for recording debug log messages. By default
356 these messages only go to stderr and are not recorded anywhere
357 else. Specifying a logfile copies messages to both stderr and
358 the logfile.
359 olcLogLevel: <integer> [...]
361 Specify the level at which debugging statements and operation
362 statistics should be syslogged (currently logged to the sys‐
363 logd(8) LOG_LOCAL4 facility). They must be considered subsys‐
364 tems rather than increasingly verbose log levels. Some messages
365 with higher priority are logged regardless of the configured
366 loglevel as soon as any logging is configured. Log levels are
367 additive, and available levels are:
368 1 (0x1 trace) trace function calls
369 2 (0x2 packets) debug packet handling
370 4 (0x4 args) heavy trace debugging (function args)
371 8 (0x8 conns) connection management
372 16 (0x10 BER) print out packets sent and received
373 32 (0x20 filter) search filter processing
374 64 (0x40 config) configuration file processing
375 128 (0x80 ACL) access control list processing
376 256 (0x100 stats) stats log connections/operations/re‐
377 sults
378 512 (0x200 stats2) stats log entries sent
379 1024 (0x400 shell) print communication with shell back‐
380 ends
381 2048 (0x800 parse) entry parsing
382 16384 (0x4000 sync) LDAPSync replication
391 32768 (0x8000 none) only messages that get logged what‐
392 ever log level is set
393 The desired log level can be input as a single integer that com‐
394 bines the (ORed) desired levels, both in decimal or in hexadeci‐
395 mal notation, as a list of integers (that are ORed internally),
396 or as a list of the names that are shown between parenthesis,
397 such that
398 olcLogLevel: 129
400 olcLogLevel: 0x81
401 olcLogLevel: 128 1
402 olcLogLevel: 0x80 0x1
403 olcLogLevel: acl trace
404 are equivalent. The keyword any can be used as a shortcut to
406 enable logging at all levels (equivalent to -1). The keyword
407 none, or the equivalent integer representation, causes those
408 messages that are logged regardless of the configured ol‐
409 cLogLevel to be logged. In fact, if no olcLogLevel (or a 0
410 level) is defined, no logging occurs, so at least the none level
411 is required to have high priority messages logged.
412 olcPasswordCryptSaltFormat: <format>
414 Specify the format of the salt passed to crypt(3) when generat‐
415 ing {CRYPT} passwords (see olcPasswordHash) during processing of
416 LDAP Password Modify Extended Operations (RFC 3062).
417 This string needs to be in sprintf(3) format and may include one
419 (and only one) %s conversion. This conversion will be substi‐
420 tuted with a string of random characters from [A-Za-z0-9./].
421 For example, "%.2s" provides a two character salt and "$1$%.8s"
422 tells some versions of crypt(3) to use an MD5 algorithm and pro‐
423 vides 8 random characters of salt. The default is "%s", which
424 provides 31 characters of salt.
425 olcPidFile: <filename>
427 The (absolute) name of a file that will hold the slapd server's
428 process ID (see getpid(2)).
429 olcPluginLogFile: <filename>
431 The ( absolute ) name of a file that will contain log messages
432 from SLAPI plugins. See slapd.plugin(5) for details.
433 olcReferral: <url>
435 Specify the referral to pass back when slapd(8) cannot find a
436 local database to handle a request. If multiple values are
437 specified, each url is provided.
438 olcReverseLookup: TRUE | FALSE
440 Enable/disable client name unverified reverse lookup (default is
441 FALSE if compiled with --enable-rlookups).
442 olcRootDSE: <file>
444 Specify the name of an LDIF(5) file containing user defined at‐
445 tributes for the root DSE. These attributes are returned in ad‐
446 dition to the attributes normally produced by slapd.
447 The root DSE is an entry with information about the server and
449 its capabilities, in operational attributes. It has the empty
450 DN, and can be read with e.g.:
451 ldapsearch -x -b "" -s base "+"
452 See RFC 4512 section 5.1 for details.
453 olcSaslAuxprops: <plugin> [...]
455 Specify which auxprop plugins to use for authentication lookups.
456 The default is empty, which just uses slapd's internal support.
457 Usually no other auxprop plugins are needed.
458 olcSaslHost: <fqdn>
460 Used to specify the fully qualified domain name used for SASL
461 processing.
462 olcSaslRealm: <realm>
464 Specify SASL realm. Default is empty.
465 olcSaslCbinding: none | tls-unique | tls-endpoint
467 Specify the channel-binding type, see also
468 LDAP_OPT_X_SASL_CBINDING. Default is none.
469 olcSaslSecProps: <properties>
471 Used to specify Cyrus SASL security properties. The none flag
472 (without any other properties) causes the flag properties de‐
473 fault, "noanonymous,noplain", to be cleared. The noplain flag
474 disables mechanisms susceptible to simple passive attacks. The
475 noactive flag disables mechanisms susceptible to active attacks.
476 The nodict flag disables mechanisms susceptible to passive dic‐
477 tionary attacks. The noanonymous flag disables mechanisms which
478 support anonymous login. The forwardsec flag require forward
479 secrecy between sessions. The passcred require mechanisms which
480 pass client credentials (and allow mechanisms which can pass
481 credentials to do so). The minssf=<factor> property specifies
482 the minimum acceptable security strength factor as an integer
483 approximate to effective key length used for encryption. 0
484 (zero) implies no protection, 1 implies integrity protection
485 only, 56 allows DES or other weak ciphers, 112 allows triple DES
486 and other strong ciphers, 128 allows RC4, Blowfish and other
487 modern strong ciphers. The default is 0. The maxssf=<factor>
488 property specifies the maximum acceptable security strength fac‐
489 tor as an integer (see minssf description). The default is
490 INT_MAX. The maxbufsize=<size> property specifies the maximum
491 security layer receive buffer size allowed. 0 disables security
492 layers. The default is 65536.
493 olcServerID: <integer> [<URL>]
495 Specify an integer ID from 0 to 4095 for this server (limited to
496 3 hexadecimal digits). The ID may also be specified as a hexa‐
497 decimal ID by prefixing the value with "0x". Non-zero IDs are
498 required when using multi-provider replication and each provider
499 must have a unique non-zero ID. Note that this requirement also
500 applies to separate providers contributing to a glued set of
501 databases. If the URL is provided, this directive may be speci‐
502 fied multiple times, providing a complete list of participating
503 servers and their IDs. The fully qualified hostname of each
504 server should be used in the supplied URLs. The IDs are used in
505 the "replica id" field of all CSNs generated by the specified
506 server. The default value is zero, which is only valid for sin‐
507 gle provider replication. Example:
508 olcServerID: 1 ldap://ldap1.example.com
510 olcServerID: 2 ldap://ldap2.example.com
511 olcSockbufMaxIncoming: <integer>
513 Specify the maximum incoming LDAP PDU size for anonymous ses‐
514 sions. The default is 262143.
515 olcSockbufMaxIncomingAuth: <integer>
517 Specify the maximum incoming LDAP PDU size for authenticated
518 sessions. The default is 4194303.
519 olcTCPBuffer [listener=<URL>] [{read|write}=]<size>
521 Specify the size of the TCP buffer. A global value for both
522 read and write TCP buffers related to any listener is defined,
523 unless the listener is explicitly specified, or either the read
524 or write qualifiers are used. See tcp(7) for details. Note
525 that some OS-es implement automatic TCP buffer tuning.
526 olcThreads: <integer>
528 Specify the maximum size of the primary thread pool. The de‐
529 fault is 16; the minimum value is 2.
530 olcToolThreads: <integer>
532 Specify the maximum number of threads to use in tool mode. This
533 should not be greater than the number of CPUs in the system.
534 The default is 1.
535 olcWriteTimeout: <integer>
537 Specify the number of seconds to wait before forcibly closing a
538 connection with an outstanding write. This allows recovery from
539 various network hang conditions. A setting of 0 disables this
540 feature. The default is 0.
541
543 If slapd is built with support for Transport Layer Security, there are
544 more options you can specify.
545 When using OpenSSL, if neither olcTLSCACertificateFile nor olcTLSCAC‐
547 ertificatePath is set, the system-wide default set of CA certificates
548 is used.
549 olcTLSCipherSuite: <cipher-suite-spec>
551 Permits configuring what ciphers will be accepted and the pref‐
552 erence order. <cipher-suite-spec> should be a cipher specifica‐
553 tion for the TLS library in use (OpenSSL, GnuTLS, or Mozilla
554 NSS). Example:
555 OpenSSL:
557 olcTLSCipherSuite: HIGH:MEDIUM:+SSLv2
558 GnuTLS:
560 olcTLSCiphersuite: SECURE256:!AES-128-CBC
561 To check what ciphers a given spec selects in OpenSSL, use:
563 openssl ciphers -v <cipher-suite-spec>
565 With GnuTLS the available specs can be found in the manual page
567 of gnutls-cli(1) (see the description of the option --priority).
568 In older versions of GnuTLS, where gnutls-cli does not support
570 the option --priority, you can obtain the — more limited — list
571 of ciphers by calling:
572 gnutls-cli -l
574 When using Mozilla NSS, the OpenSSL cipher suite specifications
576 are used and translated into the format used internally by
577 Mozilla NSS. There isn't an easy way to list the cipher suites
578 from the command line. The authoritative list is in the source
579 code for Mozilla NSS in the file sslinfo.c in the structure
580 static const SSLCipherSuiteInfo suiteInfo[]
581 olcTLSCACertificateFile: <filename>
583 Specifies the file that contains certificates for all of the
584 Certificate Authorities that slapd will recognize.
585 olcTLSCACertificatePath: <path>
587 Specifies the path of a directory that contains Certificate Au‐
588 thority certificates in separate individual files. Usually only
589 one of this or the olcTLSCACertificateFile is defined. If both
590 are specified, both locations will be used. This directive is
591 not supported when using GnuTLS.
592 When using Mozilla NSS, <path> may contain a Mozilla NSS
594 cert/key database. If <path> contains a Mozilla NSS cert/key
595 database and CA cert files, OpenLDAP will use the cert/key data‐
596 base and will ignore the CA cert files.
597 olcTLSCertificateFile: <filename>
599 Specifies the file that contains the slapd server certificate.
600 When using Mozilla NSS, if using a cert/key database (specified
602 with olcTLSCACertificatePath), olcTLSCertificateFile specifies
603 the name of the certificate to use:
604 olcTLSCertificateFile: Server-Cert
605 If using a token other than the internal built in token, specify
606 the token name first, followed by a colon:
607 olcTLSCertificateFile: my hardware device:Server-Cert
608 Use certutil -L to list the certificates by name:
609 certutil -d /path/to/certdbdir -L
610 olcTLSCertificateKeyFile: <filename>
612 Specifies the file that contains the slapd server private key
613 that matches the certificate stored in the olcTLSCertificateFile
614 file. If the private key is protected with a password, the pass‐
615 word must be manually typed in when slapd starts. Usually the
616 private key is not protected with a password, to allow slapd to
617 start without manual intervention, so it is of critical impor‐
618 tance that the file is protected carefully.
619 When using Mozilla NSS, olcTLSCertificateKeyFile specifies the
621 name of a file that contains the password for the key for the
622 certificate specified with olcTLSCertificateFile. The modutil
623 command can be used to turn off password protection for the
624 cert/key database. For example, if olcTLSCACertificatePath
625 specifes /etc/openldap/certdb as the location of the cert/key
626 database, use modutil to change the password to the empty
627 string:
628 modutil -dbdir /etc/openldap/certdb -changepw 'NSS Certificate DB'
629 You must have the old password, if any. Ignore the WARNING
630 about the running browser. Press 'Enter' for the new password.
631 olcTLSDHParamFile: <filename>
634 This directive specifies the file that contains parameters for
635 Diffie-Hellman ephemeral key exchange. This is required in or‐
636 der to use a DSA certificate on the server, or an RSA certifi‐
637 cate missing the "key encipherment" key usage. Note that set‐
638 ting this option may also enable Anonymous Diffie-Hellman key
639 exchanges in certain non-default cipher suites. Anonymous key
640 exchanges should generally be avoided since they provide no ac‐
641 tual client or server authentication and provide no protection
642 against man-in-the-middle attacks. You should append "!ADH" to
643 your cipher suites to ensure that these suites are not used.
644 When using Mozilla NSS these parameters are always generated
645 randomly so this directive is ignored.
646 olcTLSECName: <name>
648 Specify the name of the curve(s) to use for Elliptic curve
649 Diffie-Hellman ephemeral key exchange. This option is only used
650 for OpenSSL. This option is not used with GnuTLS; the curves
651 may be chosen in the GnuTLS ciphersuite specification. This op‐
652 tion is also ignored for Mozilla NSS.
653 olcTLSProtocolMin: <major>[.<minor>]
655 Specifies minimum SSL/TLS protocol version that will be negoti‐
656 ated. If the server doesn't support at least that version, the
657 SSL handshake will fail. To require TLS 1.x or higher, set this
658 option to 3.(x+1), e.g.,
659 olcTLSProtocolMin: 3.2
661 would require TLS 1.1. Specifying a minimum that is higher than
663 that supported by the OpenLDAP implementation will result in it
664 requiring the highest level that it does support. This direc‐
665 tive is ignored with GnuTLS.
666 olcTLSRandFile: <filename>
668 Specifies the file to obtain random bits from when /dev/[u]ran‐
669 dom is not available. Generally set to the name of the
670 EGD/PRNGD socket. The environment variable RANDFILE can also be
671 used to specify the filename. This directive is ignored with
672 GnuTLS and Mozilla NSS.
673 olcTLSVerifyClient: <level>
675 Specifies what checks to perform on client certificates in an
676 incoming TLS session, if any. The <level> can be specified as
677 one of the following keywords:
678 never This is the default. slapd will not ask the client for a
680 certificate.
681 allow The client certificate is requested. If no certificate
683 is provided, the session proceeds normally. If a bad
684 certificate is provided, it will be ignored and the ses‐
685 sion proceeds normally.
686 try The client certificate is requested. If no certificate
688 is provided, the session proceeds normally. If a bad
689 certificate is provided, the session is immediately ter‐
690 minated.
691 demand | hard | true
693 These keywords are all equivalent, for compatibility rea‐
694 sons. The client certificate is requested. If no cer‐
695 tificate is provided, or a bad certificate is provided,
696 the session is immediately terminated.
697 Note that a valid client certificate is required in order
699 to use the SASL EXTERNAL authentication mechanism with a
700 TLS session. As such, a non-default olcTLSVerifyClient
701 setting must be chosen to enable SASL EXTERNAL authenti‐
702 cation.
703 olcTLSCRLCheck: <level>
705 Specifies if the Certificate Revocation List (CRL) of the CA
706 should be used to verify if the client certificates have not
707 been revoked. This requires olcTLSCACertificatePath parameter to
708 be set. This parameter is ignored with GnuTLS and Mozilla NSS.
709 <level> can be specified as one of the following keywords:
710 none No CRL checks are performed
712 peer Check the CRL of the peer certificate
714 all Check the CRL for a whole certificate chain
716 olcTLSCRLFile: <filename>
718 Specifies a file containing a Certificate Revocation List to be
719 used for verifying that certificates have not been revoked. This
720 parameter is only valid when using GnuTLS or Mozilla NSS.
721
723 If slapd is compiled with --enable-modules then the module-related en‐
724 tries will be available. These entries are named cn=module{x},cn=config
725 and must have the olcModuleList objectClass. One entry should be cre‐
726 ated per olcModulePath. Normally the config engine generates the "{x}"
727 index in the RDN automatically, so it can be omitted when initially
728 loading these entries.
729 olcModuleLoad: <filename>
731 Specify the name of a dynamically loadable module to load. The
732 filename may be an absolute path name or a simple filename. Non-
733 absolute names are searched for in the directories specified by
734 the olcModulePath option.
735 olcModulePath: <pathspec>
737 Specify a list of directories to search for loadable modules.
738 Typically the path is colon-separated but this depends on the
739 operating system. The default is /usr/lib64/openldap, which is
740 where the standard OpenLDAP install will place its modules.
741
743 Schema definitions are created as entries in the cn=schema,cn=config
744 subtree. These entries must have the olcSchemaConfig objectClass. As
745 noted above, the actual cn=schema,cn=config entry is predefined and any
746 values specified for it are ignored.
747 olcAttributetypes: ( <oid> [NAME <name>] [DESC <description>]
750 [OBSOLETE] [SUP <oid>] [EQUALITY <oid>] [ORDERING <oid>]
751 [SUBSTR <oid>] [SYNTAX <oidlen>] [SINGLE-VALUE] [COLLECTIVE]
752 [NO-USER-MODIFICATION] [USAGE <attributeUsage>] )
753 Specify an attribute type using the LDAPv3 syntax defined in RFC
754 4512. The slapd parser extends the RFC 4512 definition by
755 allowing string forms as well as numeric OIDs to be used for the
756 attribute OID and attribute syntax OID. (See the
757 olcObjectIdentifier description.)
758 olcDitContentRules: ( <oid> [NAME <name>] [DESC <description>]
761 [OBSOLETE] [AUX <oids>] [MUST <oids>] [MAY <oids>]
762 [NOT <oids>] )
763 Specify an DIT Content Rule using the LDAPv3 syntax defined in
764 RFC 4512. The slapd parser extends the RFC 4512 definition by
765 allowing string forms as well as numeric OIDs to be used for the
766 attribute OID and attribute syntax OID. (See the
767 olcObjectIdentifier description.)
768 olcObjectClasses: ( <oid> [NAME <name>] [DESC <description>] [OBSOLETE]
771 [SUP <oids>] [{ ABSTRACT | STRUCTURAL | AUXILIARY }]
772 [MUST <oids>] [MAY <oids>] )
773 Specify an objectclass using the LDAPv3 syntax defined in RFC
774 4512. The slapd parser extends the RFC 4512 definition by
775 allowing string forms as well as numeric OIDs to be used for the
776 object class OID. (See the olcObjectIdentifier description.)
777 Object classes are "STRUCTURAL" by default.
778 olcObjectIdentifier: <name> { <oid> | <name>[:<suffix>] }
780 Define a string name that equates to the given OID. The string
781 can be used in place of the numeric OID in objectclass and
782 attribute definitions. The name can also be used with a suffix
783 of the form ":xx" in which case the value "oid.xx" will be used.
784
787 Options in these entries only apply to the configuration of a single
788 type of backend. All backends may support this class of options, but
789 currently none do. The entry must be named
790 olcBackend=<databasetype>,cn=config and must have the olcBackendConfig
791 objectClass. <databasetype> should be one of bdb, config, dnssrv, hdb,
792 ldap, ldif, mdb, meta, monitor, ndb, null, passwd, perl, relay, shell,
793 or sql. At present, no backend implements any options of this type, so
794 this entry should not be used.
795
798 Database options are set in entries named
799 olcDatabase={x}<databasetype>,cn=config and must have the
800 olcDatabaseConfig objectClass. Normally the config engine generates the
801 "{x}" index in the RDN automatically, so it can be omitted when
802 initially loading these entries.
803 The special frontend database is always numbered "{-1}" and the config
805 database is always numbered "{0}".
806
809 Options in this section may be set in the special "frontend" database
810 and inherited in all the other databases. These options may be altered
811 by further settings in each specific database. The frontend entry must
812 be named olcDatabase=frontend,cn=config and must have the
813 olcFrontendConfig objectClass.
814 olcAccess: to <what> [ by <who> <access> <control> ]+
816 Grant access (specified by <access>) to a set of entries and/or
817 attributes (specified by <what>) by one or more requestors
818 (specified by <who>). If no access controls are present, the
819 default policy allows anyone and everyone to read anything but
820 restricts updates to rootdn. (e.g., "olcAccess: to * by *
821 read"). See slapd.access(5) and the "OpenLDAP Administrator's
822 Guide" for details.
823 Access controls set in the frontend are appended to any access
825 controls set on the specific databases. The rootdn of a
826 database can always read and write EVERYTHING in that database.
827 Extra special care must be taken with the access controls on the
829 config database. Unlike other databases, the default policy for
830 the config database is to only allow access to the rootdn.
831 Regular users should not have read access, and write access
832 should be granted very carefully to privileged administrators.
833 olcDefaultSearchBase: <dn>
836 Specify a default search base to use when client submits a non-
837 base search request with an empty base DN. Base scoped search
838 requests with an empty base DN are not affected. This setting
839 is only allowed in the frontend entry.
840 olcExtraAttrs: <attr>
842 Lists what attributes need to be added to search requests.
843 Local storage backends return the entire entry to the frontend.
844 The frontend takes care of only returning the requested
845 attributes that are allowed by ACLs. However, features like
846 access checking and so may need specific attributes that are not
847 automatically returned by remote storage backends, like proxy
848 backends and so on. <attr> is an attribute that is needed for
849 internal purposes and thus always needs to be collected, even
850 when not explicitly requested by clients. This attribute is
851 multi-valued.
852 olcPasswordHash: <hash> [<hash>...]
854 This option configures one or more hashes to be used in
855 generation of user passwords stored in the userPassword
856 attribute during processing of LDAP Password Modify Extended
857 Operations (RFC 3062). The <hash> must be one of {SSHA}, {SHA},
858 {SMD5}, {MD5}, {CRYPT}, and {CLEARTEXT}. The default is {SSHA}.
859 {SHA} and {SSHA} use the SHA-1 algorithm (FIPS 160-1), the
861 latter with a seed.
862 {MD5} and {SMD5} use the MD5 algorithm (RFC 1321), the latter
864 with a seed.
865 {CRYPT} uses the crypt(3).
867 {CLEARTEXT} indicates that the new password should be added to
869 userPassword as clear text.
870 Note that this option does not alter the normal user
872 applications handling of userPassword during LDAP Add, Modify,
873 or other LDAP operations. This setting is only allowed in the
874 frontend entry.
875 olcReadOnly: TRUE | FALSE
877 This option puts the database into "read-only" mode. Any
878 attempts to modify the database will return an "unwilling to
879 perform" error. By default, olcReadOnly is FALSE. Note that
880 when this option is set TRUE on the frontend, it cannot be reset
881 without restarting the server, since further writes to the
882 config database will be rejected.
883 olcRequires: <conditions>
885 Specify a set of conditions to require (default none). The
886 directive may be specified globally and/or per-database;
887 databases inherit global conditions, so per-database
888 specifications are additive. bind requires bind operation prior
889 to directory operations. LDAPv3 requires session to be using
890 LDAP version 3. authc requires authentication prior to
891 directory operations. SASL requires SASL authentication prior
892 to directory operations. strong requires strong authentication
893 prior to directory operations. The strong keyword allows
894 protected "simple" authentication as well as SASL
895 authentication. none may be used to require no conditions
896 (useful to clear out globally set conditions within a particular
897 database); it must occur first in the list of conditions.
898 olcRestrict: <oplist>
900 Specify a list of operations that are restricted. Restrictions
901 on a specific database override any frontend setting.
902 Operations can be any of add, bind, compare, delete,
903 extended[=<OID>], modify, rename, search, or the special pseudo-
904 operations read and write, which respectively summarize read and
905 write operations. The use of restrict write is equivalent to
906 olcReadOnly: TRUE (see above). The extended keyword allows one
907 to indicate the OID of the specific operation to be restricted.
908 olcSchemaDN: <dn>
910 Specify the distinguished name for the subschema subentry that
911 controls the entries on this server. The default is
912 "cn=Subschema".
913 olcSecurity: <factors>
915 Specify a set of security strength factors (separated by white
916 space) to require (see olcSaslSecprops's minssf option for a
917 description of security strength factors). The directive may be
918 specified globally and/or per-database. ssf=<n> specifies the
919 overall security strength factor. transport=<n> specifies the
920 transport security strength factor. tls=<n> specifies the TLS
921 security strength factor. sasl=<n> specifies the SASL security
922 strength factor. update_ssf=<n> specifies the overall security
923 strength factor to require for directory updates.
924 update_transport=<n> specifies the transport security strength
925 factor to require for directory updates. update_tls=<n>
926 specifies the TLS security strength factor to require for
927 directory updates. update_sasl=<n> specifies the SASL security
928 strength factor to require for directory updates.
929 simple_bind=<n> specifies the security strength factor required
930 for simple username/password authentication. Note that the
931 transport factor is measure of security provided by the
932 underlying transport, e.g. ldapi:// (and eventually IPSEC). It
933 is not normally used.
934 olcSizeLimit: {<integer>|unlimited}
936 olcSizeLimit: size[.{soft|hard|unchecked}]=<integer> [...]
938 Specify the maximum number of entries to return from a search
939 operation. The default size limit is 500. Use unlimited to
940 specify no limits. The second format allows a fine grain
941 setting of the size limits. Extra args can be added in the same
942 value or as additional values. See olcLimits for an explanation
943 of the different flags.
944 olcSortVals: <attr> [...]
946 Specify a list of multi-valued attributes whose values will
947 always be maintained in sorted order. Using this option will
948 allow Modify, Compare, and filter evaluations on these
949 attributes to be performed more efficiently. The resulting sort
950 order depends on the attributes' syntax and matching rules and
951 may not correspond to lexical order or any other recognizable
952 order. This setting is only allowed in the frontend entry.
953 olcTimeLimit: {<integer>|unlimited}
955 olcTimeLimit: time[.{soft|hard}]=<integer> [...]
957 Specify the maximum number of seconds (in real time) slapd will
958 spend answering a search request. The default time limit is
959 3600. Use unlimited to specify no limits. The second format
960 allows a fine grain setting of the time limits. Extra args can
961 be added in the same value or as additional values. See
962 olcLimits for an explanation of the different flags.
963
966 Options in this section only apply to the specific database for which
967 they are defined. They are supported by every type of backend. All of
968 the Global Database Options may also be used here.
969 olcAddContentAcl: TRUE | FALSE
971 Controls whether Add operations will perform ACL checks on the
972 content of the entry being added. This check is off by default.
973 See the slapd.access(5) manual page for more details on ACL
974 requirements for Add operations.
975 olcHidden: TRUE | FALSE
977 Controls whether the database will be used to answer queries. A
978 database that is hidden will never be selected to answer any
979 queries, and any suffix configured on the database will be
980 ignored in checks for conflicts with other databases. By
981 default, olcHidden is FALSE.
982 olcLastMod: TRUE | FALSE
984 Controls whether slapd will automatically maintain the
985 modifiersName, modifyTimestamp, creatorsName, and
986 createTimestamp attributes for entries. It also controls the
987 entryCSN and entryUUID attributes, which are needed by the
988 syncrepl provider. By default, olcLastMod is TRUE.
989 olcLimits: <selector> <limit> [<limit> [...]]
991 Specify time and size limits based on the operation's initiator
992 or base DN. The argument <selector> can be any of
993 anonymous | users | [<dnspec>=]<pattern> |
995 group[/oc[/at]]=<pattern>
996 with
998 <dnspec> ::= dn[.<type>][.<style>]
1000 <type> ::= self | this
1002 <style> ::= exact | base | onelevel | subtree | children
1004 | regex | anonymous
1005 DN type self is the default and means the bound user, while this
1007 means the base DN of the operation. The term anonymous matches
1008 all unauthenticated clients. The term users matches all
1009 authenticated clients; otherwise an exact dn pattern is assumed
1010 unless otherwise specified by qualifying the (optional) key
1011 string dn with exact or base (which are synonyms), to require an
1012 exact match; with onelevel, to require exactly one level of
1013 depth match; with subtree, to allow any level of depth match,
1014 including the exact match; with children, to allow any level of
1015 depth match, not including the exact match; regex explicitly
1016 requires the (default) match based on POSIX (''extended'')
1017 regular expression pattern. Finally, anonymous matches unbound
1018 operations; the pattern field is ignored. The same behavior is
1019 obtained by using the anonymous form of the <selector> clause.
1020 The term group, with the optional objectClass oc and
1021 attributeType at fields, followed by pattern, sets the limits
1022 for any DN listed in the values of the at attribute (default
1023 member) of the oc group objectClass (default groupOfNames) whose
1024 DN exactly matches pattern.
1025 The currently supported limits are size and time.
1027 The syntax for time limits is time[.{soft|hard}]=<integer>,
1029 where integer is the number of seconds slapd will spend
1030 answering a search request. If no time limit is explicitly
1031 requested by the client, the soft limit is used; if the
1032 requested time limit exceeds the hard limit, the value of the
1033 limit is used instead. If the hard limit is set to the keyword
1034 soft, the soft limit is used in either case; if it is set to the
1035 keyword unlimited, no hard limit is enforced. Explicit requests
1036 for time limits smaller or equal to the hard limit are honored.
1037 If no limit specifier is set, the value is assigned to the soft
1038 limit, and the hard limit is set to soft, to preserve the
1039 original behavior.
1040 The syntax for size limits is
1042 size[.{soft|hard|unchecked}]=<integer>, where integer is the
1043 maximum number of entries slapd will return answering a search
1044 request. If no size limit is explicitly requested by the
1045 client, the soft limit is used; if the requested size limit
1046 exceeds the hard limit, the value of the limit is used instead.
1047 If the hard limit is set to the keyword soft, the soft limit is
1048 used in either case; if it is set to the keyword unlimited, no
1049 hard limit is enforced. Explicit requests for size limits
1050 smaller or equal to the hard limit are honored. The unchecked
1051 specifier sets a limit on the number of candidates a search
1052 request is allowed to examine. The rationale behind it is that
1053 searches for non-properly indexed attributes may result in large
1054 sets of candidates, which must be examined by slapd(8) to
1055 determine whether they match the search filter or not. The
1056 unchecked limit provides a means to drop such operations before
1057 they are even started. If the selected candidates exceed the
1058 unchecked limit, the search will abort with Unwilling to
1059 perform. If it is set to the keyword unlimited, no limit is
1060 applied (the default). If it is set to disable, the search is
1061 not even performed; this can be used to disallow searches for a
1062 specific set of users. If no limit specifier is set, the value
1063 is assigned to the soft limit, and the hard limit is set to
1064 soft, to preserve the original behavior.
1065 In case of no match, the global limits are used. The default
1067 values are the same as for olcSizeLimit and olcTimeLimit; no
1068 limit is set on unchecked.
1069 If pagedResults control is requested, the hard size limit is
1071 used by default, because the request of a specific page size is
1072 considered an explicit request for a limitation on the number of
1073 entries to be returned. However, the size limit applies to the
1074 total count of entries returned within the search, and not to a
1075 single page. Additional size limits may be enforced; the syntax
1076 is size.pr={<integer>|noEstimate|unlimited}, where integer is
1077 the max page size if no explicit limit is set; the keyword
1078 noEstimate inhibits the server from returning an estimate of the
1079 total number of entries that might be returned (note: the
1080 current implementation does not return any estimate). The
1081 keyword unlimited indicates that no limit is applied to the
1082 pagedResults control page size. The syntax
1083 size.prtotal={<integer>|unlimited|disabled} allows one to set a
1084 limit on the total number of entries that the pagedResults
1085 control will return. By default it is set to the hard limit.
1086 When set, integer is the max number of entries that the whole
1087 search with pagedResults control can return. Use unlimited to
1088 allow unlimited number of entries to be returned, e.g. to allow
1089 the use of the pagedResults control as a means to circumvent
1090 size limitations on regular searches; the keyword disabled
1091 disables the control, i.e. no paged results can be returned.
1092 Note that the total number of entries returned when the
1093 pagedResults control is requested cannot exceed the hard size
1094 limit of regular searches unless extended by the prtotal switch.
1095 olcMaxDerefDepth: <depth>
1097 Specifies the maximum number of aliases to dereference when
1098 trying to resolve an entry, used to avoid infinite alias loops.
1099 The default is 15.
1100 olcMirrorMode: TRUE | FALSE
1102 This option puts a consumer database into "mirror" mode. Update
1103 operations will be accepted from any user, not just the
1104 updatedn. The database must already be configured as syncrepl
1105 consumer before this keyword may be set. This mode also
1106 requires a olcServerID (see above) to be configured. By
1107 default, this setting is FALSE.
1108 olcPlugin: <plugin_type> <lib_path> <init_function> [<arguments>]
1110 Configure a SLAPI plugin. See the slapd.plugin(5) manpage for
1111 more details.
1112 olcRootDN: <dn>
1114 Specify the distinguished name that is not subject to access
1115 control or administrative limit restrictions for operations on
1116 this database. This DN may or may not be associated with an
1117 entry. An empty root DN (the default) specifies no root access
1118 is to be granted. It is recommended that the rootdn only be
1119 specified when needed (such as when initially populating a
1120 database). If the rootdn is within a namingContext (suffix) of
1121 the database, a simple bind password may also be provided using
1122 the olcRootPW directive. Note that the rootdn is always needed
1123 when using syncrepl. The olcRootDN of the cn=config database
1124 defaults to cn=config itself.
1125 olcRootPW: <password>
1127 Specify a password (or hash of the password) for the rootdn.
1128 The password can only be set if the rootdn is within the
1129 namingContext (suffix) of the database. This option accepts all
1130 RFC 2307 userPassword formats known to the server (see
1131 olcPasswordHash description) as well as cleartext.
1132 slappasswd(8) may be used to generate a hash of a password.
1133 Cleartext and {CRYPT} passwords are not recommended. If empty
1134 (the default), authentication of the root DN is by other means
1135 (e.g. SASL). Use of SASL is encouraged.
1136 olcSubordinate: [TRUE | FALSE | advertise]
1138 Specify that the current backend database is a subordinate of
1139 another backend database. A subordinate database may have only
1140 one suffix. This option may be used to glue multiple databases
1141 into a single namingContext. If the suffix of the current
1142 database is within the namingContext of a superior database,
1143 searches against the superior database will be propagated to the
1144 subordinate as well. All of the databases associated with a
1145 single namingContext should have identical rootdns. Behavior of
1146 other LDAP operations is unaffected by this setting. In
1147 particular, it is not possible to use moddn to move an entry
1148 from one subordinate to another subordinate within the
1149 namingContext.
1150 If the optional advertise flag is supplied, the naming context
1152 of this database is advertised in the root DSE. The default is
1153 to hide this database context, so that only the superior context
1154 is visible.
1155 If the slap tools slapcat(8), slapadd(8), or slapindex(8) are
1157 used on the superior database, any glued subordinates that
1158 support these tools are opened as well.
1159 Databases that are glued together should usually be configured
1161 with the same indices (assuming they support indexing), even for
1162 attributes that only exist in some of these databases. In
1163 general, all of the glued databases should be configured as
1164 similarly as possible, since the intent is to provide the
1165 appearance of a single directory.
1166 Note that the subordinate functionality is implemented
1168 internally by the glue overlay and as such its behavior will
1169 interact with other overlays in use. By default, the glue
1170 overlay is automatically configured as the last overlay on the
1171 superior database. Its position on the database can be
1172 explicitly configured by setting an overlay glue directive at
1173 the desired position. This explicit configuration is necessary
1174 e.g. when using the syncprov overlay, which needs to follow
1175 glue in order to work over all of the glued databases. E.g.
1176 dn: olcDatabase={1}mdb,cn=config
1177 olcSuffix: dc=example,dc=com
1178 ...
1179 dn: olcOverlay={0}glue,olcDatabase={1}mdb,cn=config
1181 ...
1182 dn: olcOverlay={1}syncprov,olcDatabase={1}mdb,cn=config
1184 ...
1185 See the Overlays section below for more details.
1186 olcSuffix: <dn suffix>
1188 Specify the DN suffix of queries that will be passed to this
1189 backend database. Multiple suffix lines can be given and at
1190 least one is required for each database definition.
1191 If the suffix of one database is "inside" that of another, the
1193 database with the inner suffix must come first in the
1194 configuration file. You may also want to glue such databases
1195 together with the olcSubordinate attribute.
1196 olcSyncUseSubentry: TRUE | FALSE
1198 Store the syncrepl contextCSN in a subentry instead of the
1199 context entry of the database. The subentry's RDN will be
1200 "cn=ldapsync". The default is FALSE, meaning the contextCSN is
1201 stored in the context entry.
1202 olcSyncrepl: rid=<replica ID> provider=ldap[s]://<hostname>[:port]
1204 searchbase=<base DN> [type=refreshOnly|refreshAndPersist]
1205 [interval=dd:hh:mm:ss] [retry=[<retry interval> <# of
1206 retries>]+] [filter=<filter str>] [scope=sub|one|base|subord]
1207 [attrs=<attr list>] [exattrs=<attr list>] [attrsonly]
1208 [sizelimit=<limit>] [timelimit=<limit>] [schemachecking=on|off]
1209 [network-timeout=<seconds>] [timeout=<seconds>]
1210 [bindmethod=simple|sasl] [binddn=<dn>] [saslmech=<mech>]
1211 [authcid=<identity>] [authzid=<identity>] [credentials=<passwd>]
1212 [realm=<realm>] [secprops=<properties>]
1213 [keepalive=<idle>:<probes>:<interval>] [starttls=yes|critical]
1214 [tls_cert=<file>] [tls_key=<file>] [tls_cacert=<file>]
1215 [tls_cacertdir=<path>] [tls_reqcert=never|allow|try|demand]
1216 [tls_reqsan=never|allow|try|demand] [tls_cipher_suite=<ciphers>]
1217 [tls_ecname=<names>] [tls_crlcheck=none|peer|all]
1218 [tls_protocol_min=<major>[.<minor>]] [suffixmassage=<real DN>]
1219 [logbase=<base DN>] [logfilter=<filter str>]
1220 [syncdata=default|accesslog|changelog]
1221 Specify the current database as a consumer which is kept up-to-
1222 date with the provider content by establishing the current
1223 slapd(8) as a replication consumer site running a syncrepl
1224 replication engine. The consumer content is kept synchronized
1225 to the provider content using the LDAP Content Synchronization
1226 protocol. Refer to the "OpenLDAP Administrator's Guide" for
1227 detailed information on setting up a replicated slapd directory
1228 service using the syncrepl replication engine.
1229 rid identifies the current syncrepl directive within the
1231 replication consumer site. It is a non-negative integer having
1232 no more than three decimal digits.
1233 provider specifies the replication provider site containing the
1235 provider content as an LDAP URI. If <port> is not given, the
1236 standard LDAP port number (389 or 636) is used.
1237 The content of the syncrepl consumer is defined using a search
1239 specification as its result set. The consumer slapd will send
1240 search requests to the provider slapd according to the search
1241 specification. The search specification includes searchbase,
1242 scope, filter, attrs, attrsonly, sizelimit, and timelimit
1243 parameters as in the normal search specification. The exattrs
1244 option may also be used to specify attributes that should be
1245 omitted from incoming entries. The scope defaults to sub, the
1246 filter defaults to (objectclass=*), and there is no default
1247 searchbase. The attrs list defaults to "*,+" to return all user
1248 and operational attributes, and attrsonly and exattrs are unset
1249 by default. The sizelimit and timelimit only accept "unlimited"
1250 and positive integers, and both default to "unlimited". Note,
1251 however, that any provider-side limits for the replication
1252 identity will be enforced by the provider regardless of the
1253 limits requested by the LDAP Content Synchronization operation,
1254 much like for any other search operation.
1255 The LDAP Content Synchronization protocol has two operation
1257 types. In the refreshOnly operation, the next synchronization
1258 search operation is periodically rescheduled at an interval time
1259 (specified by interval parameter; 1 day by default) after each
1260 synchronization operation finishes. In the refreshAndPersist
1261 operation, a synchronization search remains persistent in the
1262 provider slapd. Further updates to the provider will generate
1263 searchResultEntry to the consumer slapd as the search responses
1264 to the persistent synchronization search. If the initial search
1265 fails due to an error, the next synchronization search operation
1266 is periodically rescheduled at an interval time (specified by
1267 interval parameter; 1 day by default)
1268 If an error occurs during replication, the consumer will attempt
1270 to reconnect according to the retry parameter which is a list of
1271 the <retry interval> and <# of retries> pairs. For example,
1272 retry="60 10 300 3" lets the consumer retry every 60 seconds for
1273 the first 10 times and then retry every 300 seconds for the next
1274 3 times before stop retrying. The `+' in <# of retries> means
1275 indefinite number of retries until success.
1276 The schema checking can be enforced at the LDAP Sync consumer
1278 site by turning on the schemachecking parameter. The default is
1279 off.
1280 The network-timeout parameter sets how long the consumer will
1282 wait to establish a network connection to the provider. Once a
1283 connection is established, the timeout parameter determines how
1284 long the consumer will wait for the initial Bind request to
1285 complete. The defaults for these parameters come from
1286 ldap.conf(5).
1287 A bindmethod of simple requires the options binddn and
1289 credentials and should only be used when adequate security
1290 services (e.g. TLS or IPSEC) are in place. A bindmethod of sasl
1291 requires the option saslmech. Depending on the mechanism, an
1292 authentication identity and/or credentials can be specified
1293 using authcid and credentials. The authzid parameter may be
1294 used to specify an authorization identity. Specific security
1295 properties (as with the sasl-secprops keyword above) for a SASL
1296 bind can be set with the secprops option. A non default SASL
1297 realm can be set with the realm option. The provider, other
1298 than allow authentication of the syncrepl identity, should grant
1299 that identity appropriate access privileges to the data that is
1300 being replicated (access directive), and appropriate time and
1301 size limits (limits directive).
1302 The keepalive parameter sets the values of idle, probes, and
1304 interval used to check whether a socket is alive; idle is the
1305 number of seconds a connection needs to remain idle before TCP
1306 starts sending keepalive probes; probes is the maximum number of
1307 keepalive probes TCP should send before dropping the connection;
1308 interval is interval in seconds between individual keepalive
1309 probes. Only some systems support the customization of these
1310 values; the keepalive parameter is ignored otherwise, and
1311 system-wide settings are used.
1312 The starttls parameter specifies use of the StartTLS extended
1314 operation to establish a TLS session before Binding to the
1315 provider. If the critical argument is supplied, the session will
1316 be aborted if the StartTLS request fails. Otherwise the syncrepl
1317 session continues without TLS. The tls_reqcert setting defaults
1318 to "demand", the tls_reqsan setting defaults to "allow", and the
1319 other TLS settings default to the same as the main slapd TLS
1320 settings.
1321 The suffixmassage parameter allows the consumer to pull entries
1323 from a remote directory whose DN suffix differs from the local
1324 directory. The portion of the remote entries' DNs that matches
1325 the searchbase will be replaced with the suffixmassage DN.
1326 Rather than replicating whole entries, the consumer can query
1328 logs of data modifications. This mode of operation is referred
1329 to as delta syncrepl. In addition to the above parameters, the
1330 logbase and logfilter parameters must be set appropriately for
1331 the log that will be used. The syncdata parameter must be set to
1332 either "accesslog" if the log conforms to the slapo-accesslog(5)
1333 log format, or "changelog" if the log conforms to the obsolete
1334 changelog format. If the syncdata parameter is omitted or set to
1335 "default" then the log parameters are ignored.
1336 olcUpdateDN: <dn>
1338 This option is only applicable in a replica database. It
1339 specifies the DN permitted to update (subject to access
1340 controls) the replica. It is only needed in certain push-mode
1341 replication scenarios. Generally, this DN should not be the
1342 same as the rootdn used at the provider.
1343 olcUpdateRef: <url>
1345 Specify the referral to pass back when slapd(8) is asked to
1346 modify a replicated local database. If multiple values are
1347 specified, each url is provided.
1348
1351 Each database may allow specific configuration options; they are
1352 documented separately in the backends' manual pages. See the
1353 slapd.backends(5) manual page for an overview of available backends.
1354
1356 An overlay is a piece of code that intercepts database operations in
1357 order to extend or change them. Overlays are pushed onto a stack over
1358 the database, and so they will execute in the reverse of the order in
1359 which they were configured and the database itself will receive control
1360 last of all.
1361 Overlays must be configured as child entries of a specific database.
1363 The entry's RDN must be of the form olcOverlay={x}<overlaytype> and the
1364 entry must have the olcOverlayConfig objectClass. Normally the config
1365 engine generates the "{x}" index in the RDN automatically, so it can be
1366 omitted when initially loading these entries.
1367 See the slapd.overlays(5) manual page for an overview of available
1369 overlays.
1370
1372 Here is a short example of a configuration in LDIF suitable for use
1373 with slapadd(8) :
1374 dn: cn=config
1376 objectClass: olcGlobal
1377 cn: config
1378 olcPidFile: /var/run/slapd.pid
1379 olcAttributeOptions: x-hidden lang-
1380 dn: cn=schema,cn=config
1382 objectClass: olcSchemaConfig
1383 cn: schema
1384 include: file:///etc/openldap/schema/core.ldif
1386 dn: olcDatabase=frontend,cn=config
1388 objectClass: olcDatabaseConfig
1389 objectClass: olcFrontendConfig
1390 olcDatabase: frontend
1391 # Subtypes of "name" (e.g. "cn" and "ou") with the
1392 # option ";x-hidden" can be searched for/compared,
1393 # but are not shown. See slapd.access(5).
1394 olcAccess: to attrs=name;x-hidden by * =cs
1395 # Protect passwords. See slapd.access(5).
1396 olcAccess: to attrs=userPassword by * auth
1397 # Read access to other attributes and entries.
1398 olcAccess: to * by * read
1399 # set a rootpw for the config database so we can bind.
1401 # deny access to everyone else.
1402 dn: olcDatabase=config,cn=config
1403 objectClass: olcDatabaseConfig
1404 olcDatabase: config
1405 olcRootPW: {SSHA}XKYnrjvGT3wZFQrDD5040US592LxsdLy
1406 olcAccess: to * by * none
1407 dn: olcDatabase=bdb,cn=config
1409 objectClass: olcDatabaseConfig
1410 objectClass: olcBdbConfig
1411 olcDatabase: bdb
1412 olcSuffix: "dc=our-domain,dc=com"
1413 # The database directory MUST exist prior to
1414 # running slapd AND should only be accessible
1415 # by the slapd/tools. Mode 0700 recommended.
1416 olcDbDirectory: /var/openldap-data
1417 # Indices to maintain
1418 olcDbIndex: objectClass eq
1419 olcDbIndex: cn,sn,mail pres,eq,approx,sub
1420 # We serve small clients that do not handle referrals,
1422 # so handle remote lookups on their behalf.
1423 dn: olcDatabase=ldap,cn=config
1424 objectClass: olcDatabaseConfig
1425 objectClass: olcLdapConfig
1426 olcDatabase: ldap
1427 olcSuffix: ""
1428 olcDbUri: ldap://ldap.some-server.com/
1429 Assuming the above data was saved in a file named "config.ldif" and the
1431 /etc/openldap/slapd.d directory has been created, this command will
1432 initialize the configuration:
1433 slapadd -F /etc/openldap/slapd.d -n 0 -l config.ldif
1434 "OpenLDAP Administrator's Guide" contains a longer annotated example of
1437 a slapd configuration.
1438 Alternatively, an existing slapd.conf file can be converted to the new
1440 format using slapd or any of the slap tools:
1441 slaptest -f /etc/openldap/slapd.conf -F /etc/openldap/slapd.d
1442
1445 /etc/openldap/slapd.conf
1446 default slapd configuration file
1447 /etc/openldap/slapd.d
1449 default slapd configuration directory
1450
1452 ldap(3), ldif(5), gnutls-cli(1), slapd.access(5), slapd.backends(5),
1453 slapd.conf(5), slapd.overlays(5), slapd.plugin(5), slapd(8),
1454 slapacl(8), slapadd(8), slapauth(8), slapcat(8), slapdn(8),
1455 slapindex(8), slappasswd(8), slaptest(8).
1456 "OpenLDAP Administrator's Guide" (http://www.OpenLDAP.org/doc/admin/)
1458
1460 OpenLDAP Software is developed and maintained by The OpenLDAP Project
1461 <http://www.openldap.org/>. OpenLDAP Software is derived from the
1462 University of Michigan LDAP 3.3 Release.
1463OpenLDAP 2.4.57 2021/01/18 SLAPD-CONFIG(5)