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 olcLocalSSF: <SSF>
346 Specifies the Security Strength Factor (SSF) to be given local
347 LDAP sessions, such as those to the ldapi:// listener. For a
348 description of SSF values, see olcSaslSecProps's minssf option
349 description. The default is 71.
350 olcLogFile: <filename>
352 Specify a file for recording debug log messages. By default
353 these messages only go to stderr and are not recorded anywhere
354 else. Specifying a logfile copies messages to both stderr and
355 the logfile.
356 olcLogLevel: <integer> [...]
358 Specify the level at which debugging statements and operation
359 statistics should be syslogged (currently logged to the sys‐
360 logd(8) LOG_LOCAL4 facility). They must be considered subsys‐
361 tems rather than increasingly verbose log levels. Some messages
362 with higher priority are logged regardless of the configured
363 loglevel as soon as any logging is configured. Log levels are
364 additive, and available levels are:
365 1 (0x1 trace) trace function calls
366 2 (0x2 packets) debug packet handling
367 4 (0x4 args) heavy trace debugging (function args)
368 8 (0x8 conns) connection management
369 16 (0x10 BER) print out packets sent and received
370 32 (0x20 filter) search filter processing
371 64 (0x40 config) configuration file processing
372 128 (0x80 ACL) access control list processing
373 256 (0x100 stats) stats log connections/opera‐
374 tions/results
375 512 (0x200 stats2) stats log entries sent
376 1024 (0x400 shell) print communication with shell back‐
377 ends
378 2048 (0x800 parse) entry parsing
379 16384 (0x4000 sync) LDAPSync replication
388 32768 (0x8000 none) only messages that get logged what‐
389 ever log level is set
390 The desired log level can be input as a single integer that com‐
391 bines the (ORed) desired levels, both in decimal or in hexadeci‐
392 mal notation, as a list of integers (that are ORed internally),
393 or as a list of the names that are shown between brackets, such
394 that
395 olcLogLevel: 129
397 olcLogLevel: 0x81
398 olcLogLevel: 128 1
399 olcLogLevel: 0x80 0x1
400 olcLogLevel: acl trace
401 are equivalent. The keyword any can be used as a shortcut to
403 enable logging at all levels (equivalent to -1). The keyword
404 none, or the equivalent integer representation, causes those
405 messages that are logged regardless of the configured
406 olcLogLevel to be logged. In fact, if no olcLogLevel (or a 0
407 level) is defined, no logging occurs, so at least the none level
408 is required to have high priority messages logged.
409 olcPasswordCryptSaltFormat: <format>
411 Specify the format of the salt passed to crypt(3) when generat‐
412 ing {CRYPT} passwords (see olcPasswordHash) during processing of
413 LDAP Password Modify Extended Operations (RFC 3062).
414 This string needs to be in sprintf(3) format and may include one
416 (and only one) %s conversion. This conversion will be substi‐
417 tuted with a string of random characters from [A-Za-z0-9./].
418 For example, "%.2s" provides a two character salt and "$1$%.8s"
419 tells some versions of crypt(3) to use an MD5 algorithm and pro‐
420 vides 8 random characters of salt. The default is "%s", which
421 provides 31 characters of salt.
422 olcPidFile: <filename>
424 The (absolute) name of a file that will hold the slapd server's
425 process ID (see getpid(2)).
426 olcPluginLogFile: <filename>
428 The ( absolute ) name of a file that will contain log messages
429 from SLAPI plugins. See slapd.plugin(5) for details.
430 olcReferral: <url>
432 Specify the referral to pass back when slapd(8) cannot find a
433 local database to handle a request. If multiple values are
434 specified, each url is provided.
435 olcReverseLookup: TRUE | FALSE
437 Enable/disable client name unverified reverse lookup (default is
438 FALSE if compiled with --enable-rlookups).
439 olcRootDSE: <file>
441 Specify the name of an LDIF(5) file containing user defined
442 attributes for the root DSE. These attributes are returned in
443 addition to the attributes normally produced by slapd.
444 The root DSE is an entry with information about the server and
446 its capabilities, in operational attributes. It has the empty
447 DN, and can be read with e.g.:
448 ldapsearch -x -b "" -s base "+"
449 See RFC 4512 section 5.1 for details.
450 olcSaslAuxprops: <plugin> [...]
452 Specify which auxprop plugins to use for authentication lookups.
453 The default is empty, which just uses slapd's internal support.
454 Usually no other auxprop plugins are needed.
455 olcSaslHost: <fqdn>
457 Used to specify the fully qualified domain name used for SASL
458 processing.
459 olcSaslRealm: <realm>
461 Specify SASL realm. Default is empty.
462 olcSaslSecProps: <properties>
464 Used to specify Cyrus SASL security properties. The none flag
465 (without any other properties) causes the flag properties
466 default, "noanonymous,noplain", to be cleared. The noplain flag
467 disables mechanisms susceptible to simple passive attacks. The
468 noactive flag disables mechanisms susceptible to active attacks.
469 The nodict flag disables mechanisms susceptible to passive dic‐
470 tionary attacks. The noanonymous flag disables mechanisms which
471 support anonymous login. The forwardsec flag require forward
472 secrecy between sessions. The passcred require mechanisms which
473 pass client credentials (and allow mechanisms which can pass
474 credentials to do so). The minssf=<factor> property specifies
475 the minimum acceptable security strength factor as an integer
476 approximate to effective key length used for encryption. 0
477 (zero) implies no protection, 1 implies integrity protection
478 only, 56 allows DES or other weak ciphers, 112 allows triple DES
479 and other strong ciphers, 128 allows RC4, Blowfish and other
480 modern strong ciphers. The default is 0. The maxssf=<factor>
481 property specifies the maximum acceptable security strength fac‐
482 tor as an integer (see minssf description). The default is
483 INT_MAX. The maxbufsize=<size> property specifies the maximum
484 security layer receive buffer size allowed. 0 disables security
485 layers. The default is 65536.
486 olcServerID: <integer> [<URL>]
488 Specify an integer ID from 0 to 4095 for this server (limited to
489 3 hexadecimal digits). The ID may also be specified as a hexa‐
490 decimal ID by prefixing the value with "0x". These IDs are
491 required when using multimaster replication and each master must
492 have a unique ID. Note that this requirement also applies to
493 separate masters contributing to a glued set of databases. If
494 the URL is provided, this directive may be specified multiple
495 times, providing a complete list of participating servers and
496 their IDs. The fully qualified hostname of each server should be
497 used in the supplied URLs. The IDs are used in the "replica id"
498 field of all CSNs generated by the specified server. The default
499 value is zero. Example:
500 olcServerID: 1 ldap://ldap1.example.com
502 olcServerID: 2 ldap://ldap2.example.com
503 olcSockbufMaxIncoming: <integer>
505 Specify the maximum incoming LDAP PDU size for anonymous ses‐
506 sions. The default is 262143.
507 olcSockbufMaxIncomingAuth: <integer>
509 Specify the maximum incoming LDAP PDU size for authenticated
510 sessions. The default is 4194303.
511 olcTCPBuffer [listener=<URL>] [{read|write}=]<size>
513 Specify the size of the TCP buffer. A global value for both
514 read and write TCP buffers related to any listener is defined,
515 unless the listener is explicitly specified, or either the read
516 or write qualifiers are used. See tcp(7) for details. Note
517 that some OS-es implement automatic TCP buffer tuning.
518 olcThreads: <integer>
520 Specify the maximum size of the primary thread pool. The
521 default is 16; the minimum value is 2.
522 olcToolThreads: <integer>
524 Specify the maximum number of threads to use in tool mode. This
525 should not be greater than the number of CPUs in the system.
526 The default is 1.
527 olcWriteTimeout: <integer>
529 Specify the number of seconds to wait before forcibly closing a
530 connection with an outstanding write. This allows recovery from
531 various network hang conditions. A setting of 0 disables this
532 feature. The default is 0.
533
535 If slapd is built with support for Transport Layer Security, there are
536 more options you can specify.
537 olcTLSCipherSuite: <cipher-suite-spec>
539 Permits configuring what ciphers will be accepted and the pref‐
540 erence order. <cipher-suite-spec> should be a cipher specifica‐
541 tion for OpenSSL. Example:
542 olcTLSCipherSuite: HIGH:MEDIUM:+SSLv2
544 To check what ciphers a given spec selects in OpenSSL, use:
546 openssl ciphers -v <cipher-suite-spec>
548 To obtain the list of ciphers in GNUtls use:
550 gnutls-cli -l
552 olcTLSCACertificateFile: <filename>
554 Specifies the file that contains certificates for all of the
555 Certificate Authorities that slapd will recognize.
556 olcTLSCACertificatePath: <path>
558 Specifies the path of a directory that contains Certificate
559 Authority certificates in separate individual files. Usually
560 only one of this or the olcTLSCACertificateFile is defined. If
561 both are specified, both locations will be used. This directive
562 is not supported when using GNUtls.
563 olcTLSCertificateFile: <filename>
565 Specifies the file that contains the slapd server certificate.
566 olcTLSCertificateKeyFile: <filename>
568 Specifies the file that contains the slapd server private key
569 that matches the certificate stored in the olcTLSCertificateFile
570 file. If the private key is protected with a password, the pass‐
571 word must be manually typed in when slapd starts. Usually the
572 private key is not protected with a password, to allow slapd to
573 start without manual intervention, so it is of critical impor‐
574 tance that the file is protected carefully.
575 olcTLSDHParamFile: <filename>
577 This directive specifies the file that contains parameters for
578 Diffie-Hellman ephemeral key exchange. This is required in
579 order to use a DSA certificate on the server. If multiple sets
580 of parameters are present in the file, all of them will be pro‐
581 cessed. Note that setting this option may also enable Anonymous
582 Diffie-Hellman key exchanges in certain non-default cipher
583 suites. You should append "!ADH" to your cipher suites if you
584 have changed them from the default, otherwise no certificate
585 exchanges or verification will be done. When using GNUtls these
586 parameters are always generated randomly so this directive is
587 ignored.
588 olcTLSRandFile: <filename>
590 Specifies the file to obtain random bits from when /dev/[u]ran‐
591 dom is not available. Generally set to the name of the
592 EGD/PRNGD socket. The environment variable RANDFILE can also be
593 used to specify the filename. This directive is ignored with
594 GNUtls.
595 olcTLSVerifyClient: <level>
597 Specifies what checks to perform on client certificates in an
598 incoming TLS session, if any. The <level> can be specified as
599 one of the following keywords:
600 never This is the default. slapd will not ask the client for a
602 certificate.
603 allow The client certificate is requested. If no certificate
605 is provided, the session proceeds normally. If a bad
606 certificate is provided, it will be ignored and the ses‐
607 sion proceeds normally.
608 try The client certificate is requested. If no certificate
610 is provided, the session proceeds normally. If a bad
611 certificate is provided, the session is immediately ter‐
612 minated.
613 demand | hard | true
615 These keywords are all equivalent, for compatibility rea‐
616 sons. The client certificate is requested. If no cer‐
617 tificate is provided, or a bad certificate is provided,
618 the session is immediately terminated.
619 Note that a valid client certificate is required in order
621 to use the SASL EXTERNAL authentication mechanism with a
622 TLS session. As such, a non-default olcTLSVerifyClient
623 setting must be chosen to enable SASL EXTERNAL authenti‐
624 cation.
625 olcTLSCRLCheck: <level>
627 Specifies if the Certificate Revocation List (CRL) of the CA
628 should be used to verify if the client certificates have not
629 been revoked. This requires olcTLSCACertificatePath parameter to
630 be set. This parameter is ignored with GNUtls. <level> can be
631 specified as one of the following keywords:
632 none No CRL checks are performed
634 peer Check the CRL of the peer certificate
636 all Check the CRL for a whole certificate chain
638 olcTLSCRLFile: <filename>
640 Specifies a file containing a Certificate Revocation List to be
641 used for verifying that certificates have not been revoked. This
642 parameter is only valid when using GNUtls.
643
645 If slapd is compiled with --enable-modules then the module-related
646 entries will be available. These entries are named cn=module{x},cn=con‐
647 fig and must have the olcModuleList objectClass. One entry should be
648 created per olcModulePath. Normally the config engine generates the
649 "{x}" index in the RDN automatically, so it can be omitted when ini‐
650 tially loading these entries.
651 olcModuleLoad: <filename>
653 Specify the name of a dynamically loadable module to load. The
654 filename may be an absolute path name or a simple filename. Non-
655 absolute names are searched for in the directories specified by
656 the olcModulePath option.
657 olcModulePath: <pathspec>
659 Specify a list of directories to search for loadable modules.
660 Typically the path is colon-separated but this depends on the
661 operating system. The default is /usr/lib64/openldap, which is
662 where the standard OpenLDAP install will place its modules.
663
665 Schema definitions are created as entries in the cn=schema,cn=config
666 subtree. These entries must have the olcSchemaConfig objectClass. As
667 noted above, the actual cn=schema,cn=config entry is predefined and any
668 values specified for it are ignored.
669 olcAttributetypes: ( <oid> [NAME <name>] [DESC <description>]
672 [OBSOLETE] [SUP <oid>] [EQUALITY <oid>] [ORDERING <oid>]
673 [SUBSTR <oid>] [SYNTAX <oidlen>] [SINGLE-VALUE] [COLLECTIVE]
674 [NO-USER-MODIFICATION] [USAGE <attributeUsage>] )
675 Specify an attribute type using the LDAPv3 syntax defined in RFC
676 4512. The slapd parser extends the RFC 4512 definition by
677 allowing string forms as well as numeric OIDs to be used for the
678 attribute OID and attribute syntax OID. (See the
679 olcObjectIdentifier description.)
680 olcDitContentRules: ( <oid> [NAME <name>] [DESC <description>]
683 [OBSOLETE] [AUX <oids>] [MUST <oids>] [MAY <oids>]
684 [NOT <oids>] )
685 Specify an DIT Content Rule using the LDAPv3 syntax defined in
686 RFC 4512. The slapd parser extends the RFC 4512 definition by
687 allowing string forms as well as numeric OIDs to be used for the
688 attribute OID and attribute syntax OID. (See the
689 olcObjectIdentifier description.)
690 olcObjectClasses: ( <oid> [NAME <name>] [DESC <description>] [OBSOLETE]
693 [SUP <oids>] [{ ABSTRACT | STRUCTURAL | AUXILIARY }]
694 [MUST <oids>] [MAY <oids>] )
695 Specify an objectclass using the LDAPv3 syntax defined in RFC
696 4512. The slapd parser extends the RFC 4512 definition by
697 allowing string forms as well as numeric OIDs to be used for the
698 object class OID. (See the olcObjectIdentifier description.)
699 Object classes are "STRUCTURAL" by default.
700 olcObjectIdentifier: <name> { <oid> | <name>[:<suffix>] }
702 Define a string name that equates to the given OID. The string
703 can be used in place of the numeric OID in objectclass and
704 attribute definitions. The name can also be used with a suffix
705 of the form ":xx" in which case the value "oid.xx" will be used.
706
709 Options in these entries only apply to the configuration of a single
710 type of backend. All backends may support this class of options. The
711 entry must be named olcBackend=<databasetype>,cn=config and must have
712 the olcBackendConfig objectClass. <databasetype> should be one of bdb,
713 config, dnssrv, hdb, ldap, ldif, meta, monitor, null, passwd, perl,
714 relay, shell, or sql. At present, no backend implements any options of
715 this type.
716
719 Database options are set in entries named
720 olcDatabase={x}<databasetype>,cn=config and must have the
721 olcDatabaseConfig objectClass. Normally the config engine generates the
722 "{x}" index in the RDN automatically, so it can be omitted when
723 initially loading these entries.
724 The special frontend database is always numbered "{-1}" and the config
726 database is always numbered "{0}".
727
730 Options in this section may be set in the special "frontend" database
731 and inherited in all the other databases. These options may be altered
732 by further settings in each specific database. The frontend entry must
733 be named olcDatabase=frontend,cn=config and must have the
734 olcFrontendConfig objectClass.
735 olcAccess: to <what> [ by <who> <access> <control> ]+
737 Grant access (specified by <access>) to a set of entries and/or
738 attributes (specified by <what>) by one or more requestors
739 (specified by <who>). If no access controls are present, the
740 default policy allows anyone and everyone to read anything but
741 restricts updates to rootdn. (e.g., "olcAccess: to * by *
742 read"). See slapd.access(5) and the "OpenLDAP Administrator's
743 Guide" for details.
744 Access controls set in the frontend are appended to any access
746 controls set on the specific databases. The rootdn of a
747 database can always read and write EVERYTHING in that database.
748 Extra special care must be taken with the access controls on the
750 config database. Unlike other databases, the default policy for
751 the config database is to only allow access to the rootdn.
752 Regular users should not have read access, and write access
753 should be granted very carefully to privileged administrators.
754 olcDefaultSearchBase: <dn>
757 Specify a default search base to use when client submits a non-
758 base search request with an empty base DN. Base scoped search
759 requests with an empty base DN are not affected. This setting
760 is only allowed in the frontend entry.
761 olcPasswordHash: <hash> [<hash>...]
763 This option configures one or more hashes to be used in
764 generation of user passwords stored in the userPassword
765 attribute during processing of LDAP Password Modify Extended
766 Operations (RFC 3062). The <hash> must be one of {SSHA}, {SHA},
767 {SMD5}, {MD5}, {CRYPT}, and {CLEARTEXT}. The default is {SSHA}.
768 {SHA} and {SSHA} use the SHA-1 algorithm (FIPS 160-1), the
770 latter with a seed.
771 {MD5} and {SMD5} use the MD5 algorithm (RFC 1321), the latter
773 with a seed.
774 {CRYPT} uses the crypt(3).
776 {CLEARTEXT} indicates that the new password should be added to
778 userPassword as clear text.
779 Note that this option does not alter the normal user
781 applications handling of userPassword during LDAP Add, Modify,
782 or other LDAP operations. This setting is only allowed in the
783 frontend entry.
784 olcReadOnly: TRUE | FALSE
786 This option puts the database into "read-only" mode. Any
787 attempts to modify the database will return an "unwilling to
788 perform" error. By default, olcReadOnly is FALSE. Note that
789 when this option is set TRUE on the frontend, it cannot be reset
790 without restarting the server, since further writes to the
791 config database will be rejected.
792 olcRequires: <conditions>
794 Specify a set of conditions to require (default none). The
795 directive may be specified globally and/or per-database;
796 databases inherit global conditions, so per-database
797 specifications are additive. bind requires bind operation prior
798 to directory operations. LDAPv3 requires session to be using
799 LDAP version 3. authc requires authentication prior to
800 directory operations. SASL requires SASL authentication prior
801 to directory operations. strong requires strong authentication
802 prior to directory operations. The strong keyword allows
803 protected "simple" authentication as well as SASL
804 authentication. none may be used to require no conditions
805 (useful to clear out globally set conditions within a particular
806 database); it must occur first in the list of conditions.
807 olcRestrict: <oplist>
809 Specify a list of operations that are restricted. Restrictions
810 on a specific database override any frontend setting.
811 Operations can be any of add, bind, compare, delete,
812 extended[=<OID>], modify, rename, search, or the special pseudo-
813 operations read and write, which respectively summarize read and
814 write operations. The use of restrict write is equivalent to
815 olcReadOnly: TRUE (see above). The extended keyword allows to
816 indicate the OID of the specific operation to be restricted.
817 olcSchemaDN: <dn>
819 Specify the distinguished name for the subschema subentry that
820 controls the entries on this server. The default is
821 "cn=Subschema".
822 olcSecurity: <factors>
824 Specify a set of security strength factors (separated by white
825 space) to require (see olcSaslSecprops's minssf option for a
826 description of security strength factors). The directive may be
827 specified globally and/or per-database. ssf=<n> specifies the
828 overall security strength factor. transport=<n> specifies the
829 transport security strength factor. tls=<n> specifies the TLS
830 security strength factor. sasl=<n> specifies the SASL security
831 strength factor. update_ssf=<n> specifies the overall security
832 strength factor to require for directory updates.
833 update_transport=<n> specifies the transport security strength
834 factor to require for directory updates. update_tls=<n>
835 specifies the TLS security strength factor to require for
836 directory updates. update_sasl=<n> specifies the SASL security
837 strength factor to require for directory updates.
838 simple_bind=<n> specifies the security strength factor required
839 for simple username/password authentication. Note that the
840 transport factor is measure of security provided by the
841 underlying transport, e.g. ldapi:// (and eventually IPSEC). It
842 is not normally used.
843 olcSizeLimit: {<integer>|unlimited}
845 olcSizeLimit: size[.{soft|hard|unchecked}]=<integer> [...]
847 Specify the maximum number of entries to return from a search
848 operation. The default size limit is 500. Use unlimited to
849 specify no limits. The second format allows a fine grain
850 setting of the size limits. Extra args can be added in the same
851 value or as additional values. See olcLimits for an explanation
852 of the different flags.
853 olcSortVals: <attr> [...]
855 Specify a list of multi-valued attributes whose values will
856 always be maintained in sorted order. Using this option will
857 allow Modify, Compare, and filter evaluations on these
858 attributes to be performed more efficiently. The resulting sort
859 order depends on the attributes' syntax and matching rules and
860 may not correspond to lexical order or any other recognizable
861 order. This setting is only allowed in the frontend entry.
862 olcTimeLimit: {<integer>|unlimited}
864 olcTimeLimit: time[.{soft|hard}]=<integer> [...]
866 Specify the maximum number of seconds (in real time) slapd will
867 spend answering a search request. The default time limit is
868 3600. Use unlimited to specify no limits. The second format
869 allows a fine grain setting of the time limits. Extra args can
870 be added in the same value or as additional values. See
871 olcLimits for an explanation of the different flags.
872
875 Options in this section only apply to the specific database for which
876 they are defined. They are supported by every type of backend. All of
877 the Global Database Options may also be used here.
878 olcAddContentAcl: TRUE | FALSE
880 Controls whether Add operations will perform ACL checks on the
881 content of the entry being added. This check is off by default.
882 See the slapd.access(5) manual page for more details on ACL
883 requirements for Add operations.
884 olcHidden: TRUE | FALSE
886 Controls whether the database will be used to answer queries. A
887 database that is hidden will never be selected to answer any
888 queries, and any suffix configured on the database will be
889 ignored in checks for conflicts with other databases. By
890 default, olcHidden is FALSE.
891 olcLastMod: TRUE | FALSE
893 Controls whether slapd will automatically maintain the
894 modifiersName, modifyTimestamp, creatorsName, and
895 createTimestamp attributes for entries. It also controls the
896 entryCSN and entryUUID attributes, which are needed by the
897 syncrepl provider. By default, olcLastMod is TRUE.
898 olcLimits: <selector> <limit> [<limit> [...]]
900 Specify time and size limits based on the operation's initiator
901 or base DN. The argument <selector> can be any of
902 anonymous | users | [<dnspec>=]<pattern> |
904 group[/oc[/at]]=<pattern>
905 with
907 <dnspec> ::= dn[.<type>][.<style>]
909 <type> ::= self | this
911 <style> ::= exact | base | onelevel | subtree | children
913 | regex | anonymous
914 DN type self is the default and means the bound user, while this
916 means the base DN of the operation. The term anonymous matches
917 all unauthenticated clients. The term users matches all
918 authenticated clients; otherwise an exact dn pattern is assumed
919 unless otherwise specified by qualifying the (optional) key
920 string dn with exact or base (which are synonyms), to require an
921 exact match; with onelevel, to require exactly one level of
922 depth match; with subtree, to allow any level of depth match,
923 including the exact match; with children, to allow any level of
924 depth match, not including the exact match; regex explicitly
925 requires the (default) match based on POSIX (''extended'')
926 regular expression pattern. Finally, anonymous matches unbound
927 operations; the pattern field is ignored. The same behavior is
928 obtained by using the anonymous form of the <selector> clause.
929 The term group, with the optional objectClass oc and
930 attributeType at fields, followed by pattern, sets the limits
931 for any DN listed in the values of the at attribute (default
932 member) of the oc group objectClass (default groupOfNames) whose
933 DN exactly matches pattern.
934 The currently supported limits are size and time.
936 The syntax for time limits is time[.{soft|hard}]=<integer>,
938 where integer is the number of seconds slapd will spend
939 answering a search request. If no time limit is explicitly
940 requested by the client, the soft limit is used; if the
941 requested time limit exceeds the hard limit, the value of the
942 limit is used instead. If the hard limit is set to the keyword
943 soft, the soft limit is used in either case; if it is set to the
944 keyword unlimited, no hard limit is enforced. Explicit requests
945 for time limits smaller or equal to the hard limit are honored.
946 If no limit specifier is set, the value is assigned to the soft
947 limit, and the hard limit is set to soft, to preserve the
948 original behavior.
949 The syntax for size limits is
951 size[.{soft|hard|unchecked}]=<integer>, where integer is the
952 maximum number of entries slapd will return answering a search
953 request. If no size limit is explicitly requested by the
954 client, the soft limit is used; if the requested size limit
955 exceeds the hard limit, the value of the limit is used instead.
956 If the hard limit is set to the keyword soft, the soft limit is
957 used in either case; if it is set to the keyword unlimited, no
958 hard limit is enforced. Explicit requests for size limits
959 smaller or equal to the hard limit are honored. The unchecked
960 specifier sets a limit on the number of candidates a search
961 request is allowed to examine. The rationale behind it is that
962 searches for non-properly indexed attributes may result in large
963 sets of candidates, which must be examined by slapd(8) to
964 determine whether they match the search filter or not. The
965 unchecked limit provides a means to drop such operations before
966 they are even started. If the selected candidates exceed the
967 unchecked limit, the search will abort with Unwilling to
968 perform. If it is set to the keyword unlimited, no limit is
969 applied (the default). If it is set to disable, the search is
970 not even performed; this can be used to disallow searches for a
971 specific set of users. If no limit specifier is set, the value
972 is assigned to the soft limit, and the hard limit is set to
973 soft, to preserve the original behavior.
974 In case of no match, the global limits are used. The default
976 values are the same as for olcSizeLimit and olcTimeLimit; no
977 limit is set on unchecked.
978 If pagedResults control is requested, the hard size limit is
980 used by default, because the request of a specific page size is
981 considered an explicit request for a limitation on the number of
982 entries to be returned. However, the size limit applies to the
983 total count of entries returned within the search, and not to a
984 single page. Additional size limits may be enforced; the syntax
985 is size.pr={<integer>|noEstimate|unlimited}, where integer is
986 the max page size if no explicit limit is set; the keyword
987 noEstimate inhibits the server from returning an estimate of the
988 total number of entries that might be returned (note: the
989 current implementation does not return any estimate). The
990 keyword unlimited indicates that no limit is applied to the
991 pagedResults control page size. The syntax
992 size.prtotal={<integer>|unlimited|disabled} allows to set a
993 limit on the total number of entries that a pagedResults control
994 allows to return. By default it is set to the hard limit. When
995 set, integer is the max number of entries that the whole search
996 with pagedResults control can return. Use unlimited to allow
997 unlimited number of entries to be returned, e.g. to allow the
998 use of the pagedResults control as a means to circumvent size
999 limitations on regular searches; the keyword disabled disables
1000 the control, i.e. no paged results can be returned. Note that
1001 the total number of entries returned when the pagedResults
1002 control is requested cannot exceed the hard size limit of
1003 regular searches unless extended by the prtotal switch.
1004 olcMaxDerefDepth: <depth>
1006 Specifies the maximum number of aliases to dereference when
1007 trying to resolve an entry, used to avoid infinite alias loops.
1008 The default is 15.
1009 olcMirrorMode: TRUE | FALSE
1011 This option puts a replica database into "mirror" mode. Update
1012 operations will be accepted from any user, not just the
1013 updatedn. The database must already be configured as syncrepl
1014 consumer before this keyword may be set. This mode also
1015 requires a olcServerID (see above) to be configured. By
1016 default, this setting is FALSE.
1017 olcPlugin: <plugin_type> <lib_path> <init_function> [<arguments>]
1019 Configure a SLAPI plugin. See the slapd.plugin(5) manpage for
1020 more details.
1021 olcRootDN: <dn>
1023 Specify the distinguished name that is not subject to access
1024 control or administrative limit restrictions for operations on
1025 this database. This DN may or may not be associated with an
1026 entry. An empty root DN (the default) specifies no root access
1027 is to be granted. It is recommended that the rootdn only be
1028 specified when needed (such as when initially populating a
1029 database). If the rootdn is within a namingContext (suffix) of
1030 the database, a simple bind password may also be provided using
1031 the olcRootPW directive. Note that the rootdn is always needed
1032 when using syncrepl. The olcRootDN of the cn=config database
1033 defaults to cn=config itself.
1034 olcRootPW: <password>
1036 Specify a password (or hash of the password) for the rootdn.
1037 The password can only be set if the rootdn is within the
1038 namingContext (suffix) of the database. This option accepts all
1039 RFC 2307 userPassword formats known to the server (see
1040 olcPasswordHash description) as well as cleartext.
1041 slappasswd(8) may be used to generate a hash of a password.
1042 Cleartext and {CRYPT} passwords are not recommended. If empty
1043 (the default), authentication of the root DN is by other means
1044 (e.g. SASL). Use of SASL is encouraged.
1045 olcSubordinate: [TRUE | FALSE | advertise]
1047 Specify that the current backend database is a subordinate of
1048 another backend database. A subordinate database may have only
1049 one suffix. This option may be used to glue multiple databases
1050 into a single namingContext. If the suffix of the current
1051 database is within the namingContext of a superior database,
1052 searches against the superior database will be propagated to the
1053 subordinate as well. All of the databases associated with a
1054 single namingContext should have identical rootdns. Behavior of
1055 other LDAP operations is unaffected by this setting. In
1056 particular, it is not possible to use moddn to move an entry
1057 from one subordinate to another subordinate within the
1058 namingContext.
1059 If the optional advertise flag is supplied, the naming context
1061 of this database is advertised in the root DSE. The default is
1062 to hide this database context, so that only the superior context
1063 is visible.
1064 If the slap tools slapcat(8), slapadd(8), or slapindex(8) are
1066 used on the superior database, any glued subordinates that
1067 support these tools are opened as well.
1068 Databases that are glued together should usually be configured
1070 with the same indices (assuming they support indexing), even for
1071 attributes that only exist in some of these databases. In
1072 general, all of the glued databases should be configured as
1073 similarly as possible, since the intent is to provide the
1074 appearance of a single directory.
1075 Note that the subordinate functionality is implemented
1077 internally by the glue overlay and as such its behavior will
1078 interact with other overlays in use. By default, the glue
1079 overlay is automatically configured as the last overlay on the
1080 superior database. Its position on the database can be
1081 explicitly configured by setting an overlay glue directive at
1082 the desired position. This explicit configuration is necessary
1083 e.g. when using the syncprov overlay, which needs to follow
1084 glue in order to work over all of the glued databases. E.g.
1085 dn: olcDatabase={1}bdb,cn=config
1086 olcSuffix: dc=example,dc=com
1087 ...
1088 dn: olcOverlay={0}glue,olcDatabase={1}bdb,cn=config
1090 ...
1091 dn: olcOverlay={1}syncprov,olcDatabase={1}bdb,cn=config
1093 ...
1094 See the Overlays section below for more details.
1095 olcSuffix: <dn suffix>
1097 Specify the DN suffix of queries that will be passed to this
1098 backend database. Multiple suffix lines can be given and at
1099 least one is required for each database definition.
1100 If the suffix of one database is "inside" that of another, the
1102 database with the inner suffix must come first in the
1103 configuration file. You may also want to glue such databases
1104 together with the olcSubordinate attribute.
1105 olcSyncUseSubentry: TRUE | FALSE
1107 Store the syncrepl contextCSN in a subentry instead of the
1108 context entry of the database. The subentry's RDN will be
1109 "cn=ldapsync". The default is FALSE, meaning the contextCSN is
1110 stored in the context entry.
1111 olcSyncrepl: rid=<replica ID> provider=ldap[s]://<hostname>[:port]
1113 searchbase=<base DN> [type=refreshOnly|refreshAndPersist]
1114 [interval=dd:hh:mm:ss] [retry=[<retry interval> <# of
1115 retries>]+] [filter=<filter str>] [scope=sub|one|base|subord]
1116 [attrs=<attr list>] [exattrs=<attr list>] [attrsonly]
1117 [sizelimit=<limit>] [timelimit=<limit>] [schemachecking=on|off]
1118 [network-timeout=<seconds>] [timeout=<seconds>]
1119 [bindmethod=simple|sasl] [binddn=<dn>] [saslmech=<mech>]
1120 [authcid=<identity>] [authzid=<identity>] [credentials=<passwd>]
1121 [realm=<realm>] [secprops=<properties>]
1122 [keepalive=<idle>:<probes>:<interval>] [starttls=yes|critical]
1123 [tls_cert=<file>] [tls_key=<file>] [tls_cacert=<file>]
1124 [tls_cacertdir=<path>] [tls_reqcert=never|allow|try|demand]
1125 [tls_ciphersuite=<ciphers>] [tls_crlcheck=none|peer|all]
1126 [logbase=<base DN>] [logfilter=<filter str>]
1127 [syncdata=default|accesslog|changelog]
1128 Specify the current database as a replica which is kept up-to-
1129 date with the master content by establishing the current
1130 slapd(8) as a replication consumer site running a syncrepl
1131 replication engine. The replica content is kept synchronized to
1132 the master content using the LDAP Content Synchronization
1133 protocol. Refer to the "OpenLDAP Administrator's Guide" for
1134 detailed information on setting up a replicated slapd directory
1135 service using the syncrepl replication engine.
1136 rid identifies the current syncrepl directive within the
1138 replication consumer site. It is a non-negative integer having
1139 no more than three decimal digits.
1140 provider specifies the replication provider site containing the
1142 master content as an LDAP URI. If <port> is not given, the
1143 standard LDAP port number (389 or 636) is used.
1144 The content of the syncrepl replica is defined using a search
1146 specification as its result set. The consumer slapd will send
1147 search requests to the provider slapd according to the search
1148 specification. The search specification includes searchbase,
1149 scope, filter, attrs, attrsonly, sizelimit, and timelimit
1150 parameters as in the normal search specification. The exattrs
1151 option may also be used to specify attributes that should be
1152 omitted from incoming entries. The scope defaults to sub, the
1153 filter defaults to (objectclass=*), and there is no default
1154 searchbase. The attrs list defaults to "*,+" to return all user
1155 and operational attributes, and attrsonly and exattrs are unset
1156 by default. The sizelimit and timelimit only accept "unlimited"
1157 and positive integers, and both default to "unlimited". Note,
1158 however, that any provider-side limits for the replication
1159 identity will be enforced by the provider regardless of the
1160 limits requested by the LDAP Content Synchronization operation,
1161 much like for any other search operation.
1162 The LDAP Content Synchronization protocol has two operation
1164 types. In the refreshOnly operation, the next synchronization
1165 search operation is periodically rescheduled at an interval time
1166 (specified by interval parameter; 1 day by default) after each
1167 synchronization operation finishes. In the refreshAndPersist
1168 operation, a synchronization search remains persistent in the
1169 provider slapd. Further updates to the master replica will
1170 generate searchResultEntry to the consumer slapd as the search
1171 responses to the persistent synchronization search.
1172 If an error occurs during replication, the consumer will attempt
1174 to reconnect according to the retry parameter which is a list of
1175 the <retry interval> and <# of retries> pairs. For example,
1176 retry="60 10 300 3" lets the consumer retry every 60 seconds for
1177 the first 10 times and then retry every 300 seconds for the next
1178 3 times before stop retrying. The `+' in <# of retries> means
1179 indefinite number of retries until success.
1180 The schema checking can be enforced at the LDAP Sync consumer
1182 site by turning on the schemachecking parameter. The default is
1183 off.
1184 The network-timeout parameter sets how long the consumer will
1186 wait to establish a network connection to the provider. Once a
1187 connection is established, the timeout parameter determines how
1188 long the consumer will wait for the initial Bind request to
1189 complete. The defaults for these parameters come from
1190 ldap.conf(5).
1191 A bindmethod of simple requires the options binddn and
1193 credentials and should only be used when adequate security
1194 services (e.g. TLS or IPSEC) are in place. A bindmethod of sasl
1195 requires the option saslmech. Depending on the mechanism, an
1196 authentication identity and/or credentials can be specified
1197 using authcid and credentials. The authzid parameter may be
1198 used to specify an authorization identity. Specific security
1199 properties (as with the sasl-secprops keyword above) for a SASL
1200 bind can be set with the secprops option. A non default SASL
1201 realm can be set with the realm option. The provider, other
1202 than allow authentication of the syncrepl identity, should grant
1203 that identity appropriate access privileges to the data that is
1204 being replicated (access directive), and appropriate time and
1205 size limits (limits directive).
1206 The keepalive parameter sets the values of idle, probes, and
1208 interval used to check whether a socket is alive; idle is the
1209 number of seconds a connection needs to remain idle before TCP
1210 starts sending keepalive probes; probes is the maximum number of
1211 keepalive probes TCP should send before dropping the connection;
1212 interval is interval in seconds between individual keepalive
1213 probes. Only some systems support the customization of these
1214 values; the keepalive parameter is ignored otherwise, and
1215 system-wide settings are used.
1216 The starttls parameter specifies use of the StartTLS extended
1218 operation to establish a TLS session before Binding to the
1219 provider. If the critical argument is supplied, the session will
1220 be aborted if the StartTLS request fails. Otherwise the syncrepl
1221 session continues without TLS. The tls_reqcert setting defaults
1222 to "demand" and the other TLS settings default to the same as
1223 the main slapd TLS settings.
1224 Rather than replicating whole entries, the consumer can query
1226 logs of data modifications. This mode of operation is referred
1227 to as delta syncrepl. In addition to the above parameters, the
1228 logbase and logfilter parameters must be set appropriately for
1229 the log that will be used. The syncdata parameter must be set to
1230 either "accesslog" if the log conforms to the slapo-accesslog(5)
1231 log format, or "changelog" if the log conforms to the obsolete
1232 changelog format. If the syncdata parameter is omitted or set to
1233 "default" then the log parameters are ignored.
1234 olcUpdateDN: <dn>
1236 This option is only applicable in a slave database. It
1237 specifies the DN permitted to update (subject to access
1238 controls) the replica. It is only needed in certain push-mode
1239 replication scenarios. Generally, this DN should not be the
1240 same as the rootdn used at the master.
1241 olcUpdateRef: <url>
1243 Specify the referral to pass back when slapd(8) is asked to
1244 modify a replicated local database. If multiple values are
1245 specified, each url is provided.
1246
1249 Each database may allow specific configuration options; they are
1250 documented separately in the backends' manual pages. See the
1251 slapd.backends(5) manual page for an overview of available backends.
1252
1254 An overlay is a piece of code that intercepts database operations in
1255 order to extend or change them. Overlays are pushed onto a stack over
1256 the database, and so they will execute in the reverse of the order in
1257 which they were configured and the database itself will receive control
1258 last of all.
1259 Overlays must be configured as child entries of a specific database.
1261 The entry's RDN must be of the form olcOverlay={x}<overlaytype> and the
1262 entry must have the olcOverlayConfig objectClass. Normally the config
1263 engine generates the "{x}" index in the RDN automatically, so it can be
1264 omitted when initially loading these entries.
1265 See the slapd.overlays(5) manual page for an overview of available
1267 overlays.
1268
1270 Here is a short example of a configuration in LDIF suitable for use
1271 with slapadd(8) :
1272 dn: cn=config
1274 objectClass: olcGlobal
1275 cn: config
1276 olcPidFile: /var/run/slapd.pid
1277 olcAttributeOptions: x-hidden lang-
1278 dn: cn=schema,cn=config
1280 objectClass: olcSchemaConfig
1281 cn: schema
1282 include: /etc/openldap/schema/core.ldif
1284 dn: olcDatabase=frontend,cn=config
1286 objectClass: olcDatabaseConfig
1287 objectClass: olcFrontendConfig
1288 olcDatabase: frontend
1289 # Subtypes of "name" (e.g. "cn" and "ou") with the
1290 # option ";x-hidden" can be searched for/compared,
1291 # but are not shown. See slapd.access(5).
1292 olcAccess: to attrs=name;x-hidden by * =cs
1293 # Protect passwords. See slapd.access(5).
1294 olcAccess: to attrs=userPassword by * auth
1295 # Read access to other attributes and entries.
1296 olcAccess: to * by * read
1297 # set a rootpw for the config database so we can bind.
1299 # deny access to everyone else.
1300 dn: olcDatabase=config,cn=config
1301 objectClass: olcDatabaseConfig
1302 olcDatabase: config
1303 olcRootPW: {SSHA}XKYnrjvGT3wZFQrDD5040US592LxsdLy
1304 olcAccess: to * by * none
1305 dn: olcDatabase=bdb,cn=config
1307 objectClass: olcDatabaseConfig
1308 objectClass: olcBdbConfig
1309 olcDatabase: bdb
1310 olcSuffix: "dc=our-domain,dc=com"
1311 # The database directory MUST exist prior to
1312 # running slapd AND should only be accessible
1313 # by the slapd/tools. Mode 0700 recommended.
1314 olcDbDirectory: /var/openldap-data
1315 # Indices to maintain
1316 olcDbIndex: objectClass eq
1317 olcDbIndex: cn,sn,mail pres,eq,approx,sub
1318 # We serve small clients that do not handle referrals,
1320 # so handle remote lookups on their behalf.
1321 dn: olcDatabase=ldap,cn=config
1322 objectClass: olcDatabaseConfig
1323 objectClass: olcLdapConfig
1324 olcDatabase: ldap
1325 olcSuffix: ""
1326 olcDbUri: ldap://ldap.some-server.com/
1327 Assuming the above data was saved in a file named "config.ldif" and the
1329 /etc/openldap/slapd.d directory has been created, this command will
1330 initialize the configuration:
1331 slapadd -F /etc/openldap/slapd.d -n 0 -l config.ldif
1332 "OpenLDAP Administrator's Guide" contains a longer annotated example of
1335 a slapd configuration.
1336 Alternatively, an existing slapd.conf file can be converted to the new
1338 format using slapd or any of the slap tools:
1339 slaptest -f /etc/openldap/slapd.conf -F /etc/openldap/slapd.d
1340
1343 /etc/openldap/slapd.conf
1344 default slapd configuration file
1345 /etc/openldap/slapd.d
1347 default slapd configuration directory
1348
1350 ldap(3), ldif(5), slapd.access(5), slapd.backends(5), slapd.conf(5),
1351 slapd.overlays(5), slapd.plugin(5), slapd(8), slapacl(8), slapadd(8),
1352 slapauth(8), slapcat(8), slapdn(8), slapindex(8), slappasswd(8),
1353 slaptest(8).
1354 "OpenLDAP Administrator's Guide" (http://www.OpenLDAP.org/doc/admin/)
1356
1358 OpenLDAP Software is developed and maintained by The OpenLDAP Project
1359 <http://www.openldap.org/>. OpenLDAP Software is derived from
1360 University of Michigan LDAP 3.3 Release.
1361OpenLDAP 2.4.23 2010/06/30 SLAPD-CONFIG(5)