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 brackets, such
399 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". These IDs are
496 required when using multimaster replication and each master must
497 have a unique ID. Note that this requirement also applies to
498 separate masters contributing to a glued set of databases. If
499 the URL is provided, this directive may be specified multiple
500 times, providing a complete list of participating servers and
501 their IDs. The fully qualified hostname of each server should be
502 used in the supplied URLs. The IDs are used in the "replica id"
503 field of all CSNs generated by the specified server. The default
504 value is zero. Example:
505 olcServerID: 1 ldap://ldap1.example.com
507 olcServerID: 2 ldap://ldap2.example.com
508 olcSockbufMaxIncoming: <integer>
510 Specify the maximum incoming LDAP PDU size for anonymous ses‐
511 sions. The default is 262143.
512 olcSockbufMaxIncomingAuth: <integer>
514 Specify the maximum incoming LDAP PDU size for authenticated
515 sessions. The default is 4194303.
516 olcTCPBuffer [listener=<URL>] [{read|write}=]<size>
518 Specify the size of the TCP buffer. A global value for both
519 read and write TCP buffers related to any listener is defined,
520 unless the listener is explicitly specified, or either the read
521 or write qualifiers are used. See tcp(7) for details. Note
522 that some OS-es implement automatic TCP buffer tuning.
523 olcThreads: <integer>
525 Specify the maximum size of the primary thread pool. The
526 default is 16; the minimum value is 2.
527 olcToolThreads: <integer>
529 Specify the maximum number of threads to use in tool mode. This
530 should not be greater than the number of CPUs in the system.
531 The default is 1.
532 olcWriteTimeout: <integer>
534 Specify the number of seconds to wait before forcibly closing a
535 connection with an outstanding write. This allows recovery from
536 various network hang conditions. A setting of 0 disables this
537 feature. The default is 0.
538
540 If slapd is built with support for Transport Layer Security, there are
541 more options you can specify.
542 olcTLSCipherSuite: <cipher-suite-spec>
544 Permits configuring what ciphers will be accepted and the pref‐
545 erence order. <cipher-suite-spec> should be a cipher specifica‐
546 tion for the TLS library in use (OpenSSL, GnuTLS, or Mozilla
547 NSS). Example:
548 OpenSSL:
550 olcTLSCipherSuite: HIGH:MEDIUM:+SSLv2
551 GnuTLS:
553 TLSCiphersuite SECURE256:!AES-128-CBC
554 To check what ciphers a given spec selects in OpenSSL, use:
556 openssl ciphers -v <cipher-suite-spec>
558 With GnuTLS the available specs can be found in the manual page
560 of gnutls-cli(1) (see the description of the option --priority).
561 In older versions of GnuTLS, where gnutls-cli does not support
563 the option --priority, you can obtain the — more limited — list
564 of ciphers by calling:
565 gnutls-cli -l
567 When using Mozilla NSS, the OpenSSL cipher suite specifications
569 are used and translated into the format used internally by
570 Mozilla NSS. There isn't an easy way to list the cipher suites
571 from the command line. The authoritative list is in the source
572 code for Mozilla NSS in the file sslinfo.c in the structure
573 static const SSLCipherSuiteInfo suiteInfo[]
574 olcTLSCACertificateFile: <filename>
576 Specifies the file that contains certificates for all of the
577 Certificate Authorities that slapd will recognize.
578 olcTLSCACertificatePath: <path>
580 Specifies the path of a directory that contains Certificate
581 Authority certificates in separate individual files. Usually
582 only one of this or the olcTLSCACertificateFile is defined. If
583 both are specified, both locations will be used. This directive
584 is not supported when using GnuTLS.
585 When using Mozilla NSS, <path> may contain a Mozilla NSS
587 cert/key database. If <path> contains a Mozilla NSS cert/key
588 database and CA cert files, OpenLDAP will use the cert/key data‐
589 base and will ignore the CA cert files.
590 olcTLSCertificateFile: <filename>
592 Specifies the file that contains the slapd server certificate.
593 When using Mozilla NSS, if using a cert/key database (specified
595 with olcTLSCACertificatePath), olcTLSCertificateFile specifies
596 the name of the certificate to use:
597 olcTLSCertificateFile: Server-Cert
598 If using a token other than the internal built in token, specify
599 the token name first, followed by a colon:
600 olcTLSCertificateFile: my hardware device:Server-Cert
601 Use certutil -L to list the certificates by name:
602 certutil -d /path/to/certdbdir -L
603 olcTLSCertificateKeyFile: <filename>
605 Specifies the file that contains the slapd server private key
606 that matches the certificate stored in the olcTLSCertificateFile
607 file. If the private key is protected with a password, the pass‐
608 word must be manually typed in when slapd starts. Usually the
609 private key is not protected with a password, to allow slapd to
610 start without manual intervention, so it is of critical impor‐
611 tance that the file is protected carefully.
612 When using Mozilla NSS, olcTLSCertificateKeyFile specifies the
614 name of a file that contains the password for the key for the
615 certificate specified with olcTLSCertificateFile. The modutil
616 command can be used to turn off password protection for the
617 cert/key database. For example, if olcTLSCACertificatePath
618 specifes /etc/openldap/certdb as the location of the cert/key
619 database, use modutil to change the password to the empty
620 string:
621 modutil -dbdir /etc/openldap/certdb -changepw 'NSS Certificate DB'
622 You must have the old password, if any. Ignore the WARNING
623 about the running browser. Press 'Enter' for the new password.
624 olcTLSDHParamFile: <filename>
627 This directive specifies the file that contains parameters for
628 Diffie-Hellman ephemeral key exchange. This is required in
629 order to use a DSA certificate on the server. If multiple sets
630 of parameters are present in the file, all of them will be pro‐
631 cessed. Note that setting this option may also enable Anonymous
632 Diffie-Hellman key exchanges in certain non-default cipher
633 suites. You should append "!ADH" to your cipher suites if you
634 have changed them from the default, otherwise no certificate
635 exchanges or verification will be done. When using GnuTLS or
636 Mozilla NSS these parameters are always generated randomly so
637 this directive is ignored.
638 olcTLSProtocolMin: <major>[.<minor>]
640 Specifies minimum SSL/TLS protocol version that will be negoti‐
641 ated. If the server doesn't support at least that version, the
642 SSL handshake will fail. To require TLS 1.x or higher, set this
643 option to 3.(x+1), e.g.,
644 olcTLSProtocolMin: 3.2
646 would require TLS 1.1. Specifying a minimum that is higher than
648 that supported by the OpenLDAP implementation will result in it
649 requiring the highest level that it does support. This direc‐
650 tive is ignored with GnuTLS.
651 olcTLSRandFile: <filename>
653 Specifies the file to obtain random bits from when /dev/[u]ran‐
654 dom is not available. Generally set to the name of the
655 EGD/PRNGD socket. The environment variable RANDFILE can also be
656 used to specify the filename. This directive is ignored with
657 GnuTLS and Mozilla NSS.
658 olcTLSVerifyClient: <level>
660 Specifies what checks to perform on client certificates in an
661 incoming TLS session, if any. The <level> can be specified as
662 one of the following keywords:
663 never This is the default. slapd will not ask the client for a
665 certificate.
666 allow The client certificate is requested. If no certificate
668 is provided, the session proceeds normally. If a bad
669 certificate is provided, it will be ignored and the ses‐
670 sion proceeds normally.
671 try The client certificate is requested. If no certificate
673 is provided, the session proceeds normally. If a bad
674 certificate is provided, the session is immediately ter‐
675 minated.
676 demand | hard | true
678 These keywords are all equivalent, for compatibility rea‐
679 sons. The client certificate is requested. If no cer‐
680 tificate is provided, or a bad certificate is provided,
681 the session is immediately terminated.
682 Note that a valid client certificate is required in order
684 to use the SASL EXTERNAL authentication mechanism with a
685 TLS session. As such, a non-default olcTLSVerifyClient
686 setting must be chosen to enable SASL EXTERNAL authenti‐
687 cation.
688 olcTLSCRLCheck: <level>
690 Specifies if the Certificate Revocation List (CRL) of the CA
691 should be used to verify if the client certificates have not
692 been revoked. This requires olcTLSCACertificatePath parameter to
693 be set. This parameter is ignored with GnuTLS and Mozilla NSS.
694 <level> can be specified as one of the following keywords:
695 none No CRL checks are performed
697 peer Check the CRL of the peer certificate
699 all Check the CRL for a whole certificate chain
701 olcTLSCRLFile: <filename>
703 Specifies a file containing a Certificate Revocation List to be
704 used for verifying that certificates have not been revoked. This
705 parameter is only valid when using GnuTLS or Mozilla NSS.
706
708 If slapd is compiled with --enable-modules then the module-related
709 entries will be available. These entries are named cn=module{x},cn=con‐
710 fig and must have the olcModuleList objectClass. One entry should be
711 created per olcModulePath. Normally the config engine generates the
712 "{x}" index in the RDN automatically, so it can be omitted when ini‐
713 tially loading these entries.
714 olcModuleLoad: <filename>
716 Specify the name of a dynamically loadable module to load. The
717 filename may be an absolute path name or a simple filename. Non-
718 absolute names are searched for in the directories specified by
719 the olcModulePath option.
720 olcModulePath: <pathspec>
722 Specify a list of directories to search for loadable modules.
723 Typically the path is colon-separated but this depends on the
724 operating system. The default is /usr/lib64/openldap, which is
725 where the standard OpenLDAP install will place its modules.
726
728 Schema definitions are created as entries in the cn=schema,cn=config
729 subtree. These entries must have the olcSchemaConfig objectClass. As
730 noted above, the actual cn=schema,cn=config entry is predefined and any
731 values specified for it are ignored.
732 olcAttributetypes: ( <oid> [NAME <name>] [DESC <description>]
735 [OBSOLETE] [SUP <oid>] [EQUALITY <oid>] [ORDERING <oid>]
736 [SUBSTR <oid>] [SYNTAX <oidlen>] [SINGLE-VALUE] [COLLECTIVE]
737 [NO-USER-MODIFICATION] [USAGE <attributeUsage>] )
738 Specify an attribute type using the LDAPv3 syntax defined in RFC
739 4512. The slapd parser extends the RFC 4512 definition by
740 allowing string forms as well as numeric OIDs to be used for the
741 attribute OID and attribute syntax OID. (See the
742 olcObjectIdentifier description.)
743 olcDitContentRules: ( <oid> [NAME <name>] [DESC <description>]
746 [OBSOLETE] [AUX <oids>] [MUST <oids>] [MAY <oids>]
747 [NOT <oids>] )
748 Specify an DIT Content Rule using the LDAPv3 syntax defined in
749 RFC 4512. The slapd parser extends the RFC 4512 definition by
750 allowing string forms as well as numeric OIDs to be used for the
751 attribute OID and attribute syntax OID. (See the
752 olcObjectIdentifier description.)
753 olcObjectClasses: ( <oid> [NAME <name>] [DESC <description>] [OBSOLETE]
756 [SUP <oids>] [{ ABSTRACT | STRUCTURAL | AUXILIARY }]
757 [MUST <oids>] [MAY <oids>] )
758 Specify an objectclass using the LDAPv3 syntax defined in RFC
759 4512. The slapd parser extends the RFC 4512 definition by
760 allowing string forms as well as numeric OIDs to be used for the
761 object class OID. (See the olcObjectIdentifier description.)
762 Object classes are "STRUCTURAL" by default.
763 olcObjectIdentifier: <name> { <oid> | <name>[:<suffix>] }
765 Define a string name that equates to the given OID. The string
766 can be used in place of the numeric OID in objectclass and
767 attribute definitions. The name can also be used with a suffix
768 of the form ":xx" in which case the value "oid.xx" will be used.
769
772 Options in these entries only apply to the configuration of a single
773 type of backend. All backends may support this class of options, but
774 currently none do. The entry must be named
775 olcBackend=<databasetype>,cn=config and must have the olcBackendConfig
776 objectClass. <databasetype> should be one of bdb, config, dnssrv, hdb,
777 ldap, ldif, mdb, meta, monitor, ndb, null, passwd, perl, relay, shell,
778 or sql. At present, no backend implements any options of this type, so
779 this entry should not be used.
780
783 Database options are set in entries named
784 olcDatabase={x}<databasetype>,cn=config and must have the
785 olcDatabaseConfig objectClass. Normally the config engine generates the
786 "{x}" index in the RDN automatically, so it can be omitted when
787 initially loading these entries.
788 The special frontend database is always numbered "{-1}" and the config
790 database is always numbered "{0}".
791
794 Options in this section may be set in the special "frontend" database
795 and inherited in all the other databases. These options may be altered
796 by further settings in each specific database. The frontend entry must
797 be named olcDatabase=frontend,cn=config and must have the
798 olcFrontendConfig objectClass.
799 olcAccess: to <what> [ by <who> <access> <control> ]+
801 Grant access (specified by <access>) to a set of entries and/or
802 attributes (specified by <what>) by one or more requestors
803 (specified by <who>). If no access controls are present, the
804 default policy allows anyone and everyone to read anything but
805 restricts updates to rootdn. (e.g., "olcAccess: to * by *
806 read"). See slapd.access(5) and the "OpenLDAP Administrator's
807 Guide" for details.
808 Access controls set in the frontend are appended to any access
810 controls set on the specific databases. The rootdn of a
811 database can always read and write EVERYTHING in that database.
812 Extra special care must be taken with the access controls on the
814 config database. Unlike other databases, the default policy for
815 the config database is to only allow access to the rootdn.
816 Regular users should not have read access, and write access
817 should be granted very carefully to privileged administrators.
818 olcDefaultSearchBase: <dn>
821 Specify a default search base to use when client submits a non-
822 base search request with an empty base DN. Base scoped search
823 requests with an empty base DN are not affected. This setting
824 is only allowed in the frontend entry.
825 olcExtraAttrs: <attr>
827 Lists what attributes need to be added to search requests.
828 Local storage backends return the entire entry to the frontend.
829 The frontend takes care of only returning the requested
830 attributes that are allowed by ACLs. However, features like
831 access checking and so may need specific attributes that are not
832 automatically returned by remote storage backends, like proxy
833 backends and so on. <attr> is an attribute that is needed for
834 internal purposes and thus always needs to be collected, even
835 when not explicitly requested by clients. This attribute is
836 multi-valued.
837 olcPasswordHash: <hash> [<hash>...]
839 This option configures one or more hashes to be used in
840 generation of user passwords stored in the userPassword
841 attribute during processing of LDAP Password Modify Extended
842 Operations (RFC 3062). The <hash> must be one of {SSHA}, {SHA},
843 {SMD5}, {MD5}, {CRYPT}, and {CLEARTEXT}. The default is {SSHA}.
844 {SHA} and {SSHA} use the SHA-1 algorithm (FIPS 160-1), the
846 latter with a seed.
847 {MD5} and {SMD5} use the MD5 algorithm (RFC 1321), the latter
849 with a seed.
850 {CRYPT} uses the crypt(3).
852 {CLEARTEXT} indicates that the new password should be added to
854 userPassword as clear text.
855 Note that this option does not alter the normal user
857 applications handling of userPassword during LDAP Add, Modify,
858 or other LDAP operations. This setting is only allowed in the
859 frontend entry.
860 olcReadOnly: TRUE | FALSE
862 This option puts the database into "read-only" mode. Any
863 attempts to modify the database will return an "unwilling to
864 perform" error. By default, olcReadOnly is FALSE. Note that
865 when this option is set TRUE on the frontend, it cannot be reset
866 without restarting the server, since further writes to the
867 config database will be rejected.
868 olcRequires: <conditions>
870 Specify a set of conditions to require (default none). The
871 directive may be specified globally and/or per-database;
872 databases inherit global conditions, so per-database
873 specifications are additive. bind requires bind operation prior
874 to directory operations. LDAPv3 requires session to be using
875 LDAP version 3. authc requires authentication prior to
876 directory operations. SASL requires SASL authentication prior
877 to directory operations. strong requires strong authentication
878 prior to directory operations. The strong keyword allows
879 protected "simple" authentication as well as SASL
880 authentication. none may be used to require no conditions
881 (useful to clear out globally set conditions within a particular
882 database); it must occur first in the list of conditions.
883 olcRestrict: <oplist>
885 Specify a list of operations that are restricted. Restrictions
886 on a specific database override any frontend setting.
887 Operations can be any of add, bind, compare, delete,
888 extended[=<OID>], modify, rename, search, or the special pseudo-
889 operations read and write, which respectively summarize read and
890 write operations. The use of restrict write is equivalent to
891 olcReadOnly: TRUE (see above). The extended keyword allows to
892 indicate the OID of the specific operation to be restricted.
893 olcSchemaDN: <dn>
895 Specify the distinguished name for the subschema subentry that
896 controls the entries on this server. The default is
897 "cn=Subschema".
898 olcSecurity: <factors>
900 Specify a set of security strength factors (separated by white
901 space) to require (see olcSaslSecprops's minssf option for a
902 description of security strength factors). The directive may be
903 specified globally and/or per-database. ssf=<n> specifies the
904 overall security strength factor. transport=<n> specifies the
905 transport security strength factor. tls=<n> specifies the TLS
906 security strength factor. sasl=<n> specifies the SASL security
907 strength factor. update_ssf=<n> specifies the overall security
908 strength factor to require for directory updates.
909 update_transport=<n> specifies the transport security strength
910 factor to require for directory updates. update_tls=<n>
911 specifies the TLS security strength factor to require for
912 directory updates. update_sasl=<n> specifies the SASL security
913 strength factor to require for directory updates.
914 simple_bind=<n> specifies the security strength factor required
915 for simple username/password authentication. Note that the
916 transport factor is measure of security provided by the
917 underlying transport, e.g. ldapi:// (and eventually IPSEC). It
918 is not normally used.
919 olcSizeLimit: {<integer>|unlimited}
921 olcSizeLimit: size[.{soft|hard|unchecked}]=<integer> [...]
923 Specify the maximum number of entries to return from a search
924 operation. The default size limit is 500. Use unlimited to
925 specify no limits. The second format allows a fine grain
926 setting of the size limits. Extra args can be added in the same
927 value or as additional values. See olcLimits for an explanation
928 of the different flags.
929 olcSortVals: <attr> [...]
931 Specify a list of multi-valued attributes whose values will
932 always be maintained in sorted order. Using this option will
933 allow Modify, Compare, and filter evaluations on these
934 attributes to be performed more efficiently. The resulting sort
935 order depends on the attributes' syntax and matching rules and
936 may not correspond to lexical order or any other recognizable
937 order. This setting is only allowed in the frontend entry.
938 olcTimeLimit: {<integer>|unlimited}
940 olcTimeLimit: time[.{soft|hard}]=<integer> [...]
942 Specify the maximum number of seconds (in real time) slapd will
943 spend answering a search request. The default time limit is
944 3600. Use unlimited to specify no limits. The second format
945 allows a fine grain setting of the time limits. Extra args can
946 be added in the same value or as additional values. See
947 olcLimits for an explanation of the different flags.
948
951 Options in this section only apply to the specific database for which
952 they are defined. They are supported by every type of backend. All of
953 the Global Database Options may also be used here.
954 olcAddContentAcl: TRUE | FALSE
956 Controls whether Add operations will perform ACL checks on the
957 content of the entry being added. This check is off by default.
958 See the slapd.access(5) manual page for more details on ACL
959 requirements for Add operations.
960 olcHidden: TRUE | FALSE
962 Controls whether the database will be used to answer queries. A
963 database that is hidden will never be selected to answer any
964 queries, and any suffix configured on the database will be
965 ignored in checks for conflicts with other databases. By
966 default, olcHidden is FALSE.
967 olcLastMod: TRUE | FALSE
969 Controls whether slapd will automatically maintain the
970 modifiersName, modifyTimestamp, creatorsName, and
971 createTimestamp attributes for entries. It also controls the
972 entryCSN and entryUUID attributes, which are needed by the
973 syncrepl provider. By default, olcLastMod is TRUE.
974 olcLimits: <selector> <limit> [<limit> [...]]
976 Specify time and size limits based on the operation's initiator
977 or base DN. The argument <selector> can be any of
978 anonymous | users | [<dnspec>=]<pattern> |
980 group[/oc[/at]]=<pattern>
981 with
983 <dnspec> ::= dn[.<type>][.<style>]
985 <type> ::= self | this
987 <style> ::= exact | base | onelevel | subtree | children
989 | regex | anonymous
990 DN type self is the default and means the bound user, while this
992 means the base DN of the operation. The term anonymous matches
993 all unauthenticated clients. The term users matches all
994 authenticated clients; otherwise an exact dn pattern is assumed
995 unless otherwise specified by qualifying the (optional) key
996 string dn with exact or base (which are synonyms), to require an
997 exact match; with onelevel, to require exactly one level of
998 depth match; with subtree, to allow any level of depth match,
999 including the exact match; with children, to allow any level of
1000 depth match, not including the exact match; regex explicitly
1001 requires the (default) match based on POSIX (''extended'')
1002 regular expression pattern. Finally, anonymous matches unbound
1003 operations; the pattern field is ignored. The same behavior is
1004 obtained by using the anonymous form of the <selector> clause.
1005 The term group, with the optional objectClass oc and
1006 attributeType at fields, followed by pattern, sets the limits
1007 for any DN listed in the values of the at attribute (default
1008 member) of the oc group objectClass (default groupOfNames) whose
1009 DN exactly matches pattern.
1010 The currently supported limits are size and time.
1012 The syntax for time limits is time[.{soft|hard}]=<integer>,
1014 where integer is the number of seconds slapd will spend
1015 answering a search request. If no time limit is explicitly
1016 requested by the client, the soft limit is used; if the
1017 requested time limit exceeds the hard limit, the value of the
1018 limit is used instead. If the hard limit is set to the keyword
1019 soft, the soft limit is used in either case; if it is set to the
1020 keyword unlimited, no hard limit is enforced. Explicit requests
1021 for time limits smaller or equal to the hard limit are honored.
1022 If no limit specifier is set, the value is assigned to the soft
1023 limit, and the hard limit is set to soft, to preserve the
1024 original behavior.
1025 The syntax for size limits is
1027 size[.{soft|hard|unchecked}]=<integer>, where integer is the
1028 maximum number of entries slapd will return answering a search
1029 request. If no size limit is explicitly requested by the
1030 client, the soft limit is used; if the requested size limit
1031 exceeds the hard limit, the value of the limit is used instead.
1032 If the hard limit is set to the keyword soft, the soft limit is
1033 used in either case; if it is set to the keyword unlimited, no
1034 hard limit is enforced. Explicit requests for size limits
1035 smaller or equal to the hard limit are honored. The unchecked
1036 specifier sets a limit on the number of candidates a search
1037 request is allowed to examine. The rationale behind it is that
1038 searches for non-properly indexed attributes may result in large
1039 sets of candidates, which must be examined by slapd(8) to
1040 determine whether they match the search filter or not. The
1041 unchecked limit provides a means to drop such operations before
1042 they are even started. If the selected candidates exceed the
1043 unchecked limit, the search will abort with Unwilling to
1044 perform. If it is set to the keyword unlimited, no limit is
1045 applied (the default). If it is set to disable, the search is
1046 not even performed; this can be used to disallow searches for a
1047 specific set of users. If no limit specifier is set, the value
1048 is assigned to the soft limit, and the hard limit is set to
1049 soft, to preserve the original behavior.
1050 In case of no match, the global limits are used. The default
1052 values are the same as for olcSizeLimit and olcTimeLimit; no
1053 limit is set on unchecked.
1054 If pagedResults control is requested, the hard size limit is
1056 used by default, because the request of a specific page size is
1057 considered an explicit request for a limitation on the number of
1058 entries to be returned. However, the size limit applies to the
1059 total count of entries returned within the search, and not to a
1060 single page. Additional size limits may be enforced; the syntax
1061 is size.pr={<integer>|noEstimate|unlimited}, where integer is
1062 the max page size if no explicit limit is set; the keyword
1063 noEstimate inhibits the server from returning an estimate of the
1064 total number of entries that might be returned (note: the
1065 current implementation does not return any estimate). The
1066 keyword unlimited indicates that no limit is applied to the
1067 pagedResults control page size. The syntax
1068 size.prtotal={<integer>|unlimited|disabled} allows to set a
1069 limit on the total number of entries that a pagedResults control
1070 allows to return. By default it is set to the hard limit. When
1071 set, integer is the max number of entries that the whole search
1072 with pagedResults control can return. Use unlimited to allow
1073 unlimited number of entries to be returned, e.g. to allow the
1074 use of the pagedResults control as a means to circumvent size
1075 limitations on regular searches; the keyword disabled disables
1076 the control, i.e. no paged results can be returned. Note that
1077 the total number of entries returned when the pagedResults
1078 control is requested cannot exceed the hard size limit of
1079 regular searches unless extended by the prtotal switch.
1080 olcMaxDerefDepth: <depth>
1082 Specifies the maximum number of aliases to dereference when
1083 trying to resolve an entry, used to avoid infinite alias loops.
1084 The default is 15.
1085 olcMirrorMode: TRUE | FALSE
1087 This option puts a replica database into "mirror" mode. Update
1088 operations will be accepted from any user, not just the
1089 updatedn. The database must already be configured as syncrepl
1090 consumer before this keyword may be set. This mode also
1091 requires a olcServerID (see above) to be configured. By
1092 default, this setting is FALSE.
1093 olcPlugin: <plugin_type> <lib_path> <init_function> [<arguments>]
1095 Configure a SLAPI plugin. See the slapd.plugin(5) manpage for
1096 more details.
1097 olcRootDN: <dn>
1099 Specify the distinguished name that is not subject to access
1100 control or administrative limit restrictions for operations on
1101 this database. This DN may or may not be associated with an
1102 entry. An empty root DN (the default) specifies no root access
1103 is to be granted. It is recommended that the rootdn only be
1104 specified when needed (such as when initially populating a
1105 database). If the rootdn is within a namingContext (suffix) of
1106 the database, a simple bind password may also be provided using
1107 the olcRootPW directive. Note that the rootdn is always needed
1108 when using syncrepl. The olcRootDN of the cn=config database
1109 defaults to cn=config itself.
1110 olcRootPW: <password>
1112 Specify a password (or hash of the password) for the rootdn.
1113 The password can only be set if the rootdn is within the
1114 namingContext (suffix) of the database. This option accepts all
1115 RFC 2307 userPassword formats known to the server (see
1116 olcPasswordHash description) as well as cleartext.
1117 slappasswd(8) may be used to generate a hash of a password.
1118 Cleartext and {CRYPT} passwords are not recommended. If empty
1119 (the default), authentication of the root DN is by other means
1120 (e.g. SASL). Use of SASL is encouraged.
1121 olcSubordinate: [TRUE | FALSE | advertise]
1123 Specify that the current backend database is a subordinate of
1124 another backend database. A subordinate database may have only
1125 one suffix. This option may be used to glue multiple databases
1126 into a single namingContext. If the suffix of the current
1127 database is within the namingContext of a superior database,
1128 searches against the superior database will be propagated to the
1129 subordinate as well. All of the databases associated with a
1130 single namingContext should have identical rootdns. Behavior of
1131 other LDAP operations is unaffected by this setting. In
1132 particular, it is not possible to use moddn to move an entry
1133 from one subordinate to another subordinate within the
1134 namingContext.
1135 If the optional advertise flag is supplied, the naming context
1137 of this database is advertised in the root DSE. The default is
1138 to hide this database context, so that only the superior context
1139 is visible.
1140 If the slap tools slapcat(8), slapadd(8), or slapindex(8) are
1142 used on the superior database, any glued subordinates that
1143 support these tools are opened as well.
1144 Databases that are glued together should usually be configured
1146 with the same indices (assuming they support indexing), even for
1147 attributes that only exist in some of these databases. In
1148 general, all of the glued databases should be configured as
1149 similarly as possible, since the intent is to provide the
1150 appearance of a single directory.
1151 Note that the subordinate functionality is implemented
1153 internally by the glue overlay and as such its behavior will
1154 interact with other overlays in use. By default, the glue
1155 overlay is automatically configured as the last overlay on the
1156 superior database. Its position on the database can be
1157 explicitly configured by setting an overlay glue directive at
1158 the desired position. This explicit configuration is necessary
1159 e.g. when using the syncprov overlay, which needs to follow
1160 glue in order to work over all of the glued databases. E.g.
1161 dn: olcDatabase={1}bdb,cn=config
1162 olcSuffix: dc=example,dc=com
1163 ...
1164 dn: olcOverlay={0}glue,olcDatabase={1}bdb,cn=config
1166 ...
1167 dn: olcOverlay={1}syncprov,olcDatabase={1}bdb,cn=config
1169 ...
1170 See the Overlays section below for more details.
1171 olcSuffix: <dn suffix>
1173 Specify the DN suffix of queries that will be passed to this
1174 backend database. Multiple suffix lines can be given and at
1175 least one is required for each database definition.
1176 If the suffix of one database is "inside" that of another, the
1178 database with the inner suffix must come first in the
1179 configuration file. You may also want to glue such databases
1180 together with the olcSubordinate attribute.
1181 olcSyncUseSubentry: TRUE | FALSE
1183 Store the syncrepl contextCSN in a subentry instead of the
1184 context entry of the database. The subentry's RDN will be
1185 "cn=ldapsync". The default is FALSE, meaning the contextCSN is
1186 stored in the context entry.
1187 olcSyncrepl: rid=<replica ID> provider=ldap[s]://<hostname>[:port]
1189 searchbase=<base DN> [type=refreshOnly|refreshAndPersist]
1190 [interval=dd:hh:mm:ss] [retry=[<retry interval> <# of
1191 retries>]+] [filter=<filter str>] [scope=sub|one|base|subord]
1192 [attrs=<attr list>] [exattrs=<attr list>] [attrsonly]
1193 [sizelimit=<limit>] [timelimit=<limit>] [schemachecking=on|off]
1194 [network-timeout=<seconds>] [timeout=<seconds>]
1195 [bindmethod=simple|sasl] [binddn=<dn>] [saslmech=<mech>]
1196 [authcid=<identity>] [authzid=<identity>] [credentials=<passwd>]
1197 [realm=<realm>] [secprops=<properties>]
1198 [keepalive=<idle>:<probes>:<interval>] [starttls=yes|critical]
1199 [tls_cert=<file>] [tls_key=<file>] [tls_cacert=<file>]
1200 [tls_cacertdir=<path>] [tls_reqcert=never|allow|try|demand]
1201 [tls_ciphersuite=<ciphers>] [tls_crlcheck=none|peer|all]
1202 [tls_protocol_min=<major>[.<minor>]] [suffixmassage=<real DN>]
1203 [logbase=<base DN>] [logfilter=<filter str>]
1204 [syncdata=default|accesslog|changelog]
1205 Specify the current database as a replica which is kept up-to-
1206 date with the master content by establishing the current
1207 slapd(8) as a replication consumer site running a syncrepl
1208 replication engine. The replica content is kept synchronized to
1209 the master content using the LDAP Content Synchronization
1210 protocol. Refer to the "OpenLDAP Administrator's Guide" for
1211 detailed information on setting up a replicated slapd directory
1212 service using the syncrepl replication engine.
1213 rid identifies the current syncrepl directive within the
1215 replication consumer site. It is a non-negative integer having
1216 no more than three decimal digits.
1217 provider specifies the replication provider site containing the
1219 master content as an LDAP URI. If <port> is not given, the
1220 standard LDAP port number (389 or 636) is used.
1221 The content of the syncrepl replica is defined using a search
1223 specification as its result set. The consumer slapd will send
1224 search requests to the provider slapd according to the search
1225 specification. The search specification includes searchbase,
1226 scope, filter, attrs, attrsonly, sizelimit, and timelimit
1227 parameters as in the normal search specification. The exattrs
1228 option may also be used to specify attributes that should be
1229 omitted from incoming entries. The scope defaults to sub, the
1230 filter defaults to (objectclass=*), and there is no default
1231 searchbase. The attrs list defaults to "*,+" to return all user
1232 and operational attributes, and attrsonly and exattrs are unset
1233 by default. The sizelimit and timelimit only accept "unlimited"
1234 and positive integers, and both default to "unlimited". Note,
1235 however, that any provider-side limits for the replication
1236 identity will be enforced by the provider regardless of the
1237 limits requested by the LDAP Content Synchronization operation,
1238 much like for any other search operation.
1239 The LDAP Content Synchronization protocol has two operation
1241 types. In the refreshOnly operation, the next synchronization
1242 search operation is periodically rescheduled at an interval time
1243 (specified by interval parameter; 1 day by default) after each
1244 synchronization operation finishes. In the refreshAndPersist
1245 operation, a synchronization search remains persistent in the
1246 provider slapd. Further updates to the master replica will
1247 generate searchResultEntry to the consumer slapd as the search
1248 responses to the persistent synchronization search.
1249 If an error occurs during replication, the consumer will attempt
1251 to reconnect according to the retry parameter which is a list of
1252 the <retry interval> and <# of retries> pairs. For example,
1253 retry="60 10 300 3" lets the consumer retry every 60 seconds for
1254 the first 10 times and then retry every 300 seconds for the next
1255 3 times before stop retrying. The `+' in <# of retries> means
1256 indefinite number of retries until success.
1257 The schema checking can be enforced at the LDAP Sync consumer
1259 site by turning on the schemachecking parameter. The default is
1260 off.
1261 The network-timeout parameter sets how long the consumer will
1263 wait to establish a network connection to the provider. Once a
1264 connection is established, the timeout parameter determines how
1265 long the consumer will wait for the initial Bind request to
1266 complete. The defaults for these parameters come from
1267 ldap.conf(5).
1268 A bindmethod of simple requires the options binddn and
1270 credentials and should only be used when adequate security
1271 services (e.g. TLS or IPSEC) are in place. A bindmethod of sasl
1272 requires the option saslmech. Depending on the mechanism, an
1273 authentication identity and/or credentials can be specified
1274 using authcid and credentials. The authzid parameter may be
1275 used to specify an authorization identity. Specific security
1276 properties (as with the sasl-secprops keyword above) for a SASL
1277 bind can be set with the secprops option. A non default SASL
1278 realm can be set with the realm option. The provider, other
1279 than allow authentication of the syncrepl identity, should grant
1280 that identity appropriate access privileges to the data that is
1281 being replicated (access directive), and appropriate time and
1282 size limits (limits directive).
1283 The keepalive parameter sets the values of idle, probes, and
1285 interval used to check whether a socket is alive; idle is the
1286 number of seconds a connection needs to remain idle before TCP
1287 starts sending keepalive probes; probes is the maximum number of
1288 keepalive probes TCP should send before dropping the connection;
1289 interval is interval in seconds between individual keepalive
1290 probes. Only some systems support the customization of these
1291 values; the keepalive parameter is ignored otherwise, and
1292 system-wide settings are used.
1293 The starttls parameter specifies use of the StartTLS extended
1295 operation to establish a TLS session before Binding to the
1296 provider. If the critical argument is supplied, the session will
1297 be aborted if the StartTLS request fails. Otherwise the syncrepl
1298 session continues without TLS. The tls_reqcert setting defaults
1299 to "demand" and the other TLS settings default to the same as
1300 the main slapd TLS settings.
1301 The suffixmassage parameter allows the consumer to pull entries
1303 from a remote directory whose DN suffix differs from the local
1304 directory. The portion of the remote entries' DNs that matches
1305 the searchbase will be replaced with the suffixmassage DN.
1306 Rather than replicating whole entries, the consumer can query
1308 logs of data modifications. This mode of operation is referred
1309 to as delta syncrepl. In addition to the above parameters, the
1310 logbase and logfilter parameters must be set appropriately for
1311 the log that will be used. The syncdata parameter must be set to
1312 either "accesslog" if the log conforms to the slapo-accesslog(5)
1313 log format, or "changelog" if the log conforms to the obsolete
1314 changelog format. If the syncdata parameter is omitted or set to
1315 "default" then the log parameters are ignored.
1316 olcUpdateDN: <dn>
1318 This option is only applicable in a slave database. It
1319 specifies the DN permitted to update (subject to access
1320 controls) the replica. It is only needed in certain push-mode
1321 replication scenarios. Generally, this DN should not be the
1322 same as the rootdn used at the master.
1323 olcUpdateRef: <url>
1325 Specify the referral to pass back when slapd(8) is asked to
1326 modify a replicated local database. If multiple values are
1327 specified, each url is provided.
1328
1331 Each database may allow specific configuration options; they are
1332 documented separately in the backends' manual pages. See the
1333 slapd.backends(5) manual page for an overview of available backends.
1334
1336 An overlay is a piece of code that intercepts database operations in
1337 order to extend or change them. Overlays are pushed onto a stack over
1338 the database, and so they will execute in the reverse of the order in
1339 which they were configured and the database itself will receive control
1340 last of all.
1341 Overlays must be configured as child entries of a specific database.
1343 The entry's RDN must be of the form olcOverlay={x}<overlaytype> and the
1344 entry must have the olcOverlayConfig objectClass. Normally the config
1345 engine generates the "{x}" index in the RDN automatically, so it can be
1346 omitted when initially loading these entries.
1347 See the slapd.overlays(5) manual page for an overview of available
1349 overlays.
1350
1352 Here is a short example of a configuration in LDIF suitable for use
1353 with slapadd(8) :
1354 dn: cn=config
1356 objectClass: olcGlobal
1357 cn: config
1358 olcPidFile: /var/run/slapd.pid
1359 olcAttributeOptions: x-hidden lang-
1360 dn: cn=schema,cn=config
1362 objectClass: olcSchemaConfig
1363 cn: schema
1364 include: file:///etc/openldap/schema/core.ldif
1366 dn: olcDatabase=frontend,cn=config
1368 objectClass: olcDatabaseConfig
1369 objectClass: olcFrontendConfig
1370 olcDatabase: frontend
1371 # Subtypes of "name" (e.g. "cn" and "ou") with the
1372 # option ";x-hidden" can be searched for/compared,
1373 # but are not shown. See slapd.access(5).
1374 olcAccess: to attrs=name;x-hidden by * =cs
1375 # Protect passwords. See slapd.access(5).
1376 olcAccess: to attrs=userPassword by * auth
1377 # Read access to other attributes and entries.
1378 olcAccess: to * by * read
1379 # set a rootpw for the config database so we can bind.
1381 # deny access to everyone else.
1382 dn: olcDatabase=config,cn=config
1383 objectClass: olcDatabaseConfig
1384 olcDatabase: config
1385 olcRootPW: {SSHA}XKYnrjvGT3wZFQrDD5040US592LxsdLy
1386 olcAccess: to * by * none
1387 dn: olcDatabase=bdb,cn=config
1389 objectClass: olcDatabaseConfig
1390 objectClass: olcBdbConfig
1391 olcDatabase: bdb
1392 olcSuffix: "dc=our-domain,dc=com"
1393 # The database directory MUST exist prior to
1394 # running slapd AND should only be accessible
1395 # by the slapd/tools. Mode 0700 recommended.
1396 olcDbDirectory: /var/openldap-data
1397 # Indices to maintain
1398 olcDbIndex: objectClass eq
1399 olcDbIndex: cn,sn,mail pres,eq,approx,sub
1400 # We serve small clients that do not handle referrals,
1402 # so handle remote lookups on their behalf.
1403 dn: olcDatabase=ldap,cn=config
1404 objectClass: olcDatabaseConfig
1405 objectClass: olcLdapConfig
1406 olcDatabase: ldap
1407 olcSuffix: ""
1408 olcDbUri: ldap://ldap.some-server.com/
1409 Assuming the above data was saved in a file named "config.ldif" and the
1411 /etc/openldap/slapd.d directory has been created, this command will
1412 initialize the configuration:
1413 slapadd -F /etc/openldap/slapd.d -n 0 -l config.ldif
1414 "OpenLDAP Administrator's Guide" contains a longer annotated example of
1417 a slapd configuration.
1418 Alternatively, an existing slapd.conf file can be converted to the new
1420 format using slapd or any of the slap tools:
1421 slaptest -f /etc/openldap/slapd.conf -F /etc/openldap/slapd.d
1422
1425 /etc/openldap/slapd.conf
1426 default slapd configuration file
1427 /etc/openldap/slapd.d
1429 default slapd configuration directory
1430
1432 ldap(3), ldif(5), gnutls-cli(1), slapd.access(5), slapd.backends(5),
1433 slapd.conf(5), slapd.overlays(5), slapd.plugin(5), slapd(8),
1434 slapacl(8), slapadd(8), slapauth(8), slapcat(8), slapdn(8),
1435 slapindex(8), slappasswd(8), slaptest(8).
1436 "OpenLDAP Administrator's Guide" (http://www.OpenLDAP.org/doc/admin/)
1438
1440 OpenLDAP Software is developed and maintained by The OpenLDAP Project
1441 <http://www.openldap.org/>. OpenLDAP Software is derived from
1442 University of Michigan LDAP 3.3 Release.
1443OpenLDAP 2.4.40 2014/09/20 SLAPD-CONFIG(5)