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