1SLAPD-CONFIG(5)               File Formats Manual              SLAPD-CONFIG(5)
2
3
4

NAME

6       slapd-config - configuration backend to slapd
7

SYNOPSIS

9       /etc/openldap/slapd.d
10

DESCRIPTION

12       The config backend manages all of the configuration information for the
13       slapd(8) daemon.  This configuration information is also  used  by  the
14       SLAPD tools slapacl(8), slapadd(8), slapauth(8), slapcat(8), slapdn(8),
15       slapindex(8), slapmodify(8), and slaptest(8).
16
17       The config backend is backward compatible with the older  slapd.conf(5)
18       file  but  provides the ability to change the configuration dynamically
19       at runtime. If slapd is run with only a slapd.conf file dynamic changes
20       will  be allowed but they will not persist across a server restart. Dy‐
21       namic changes are only saved when slapd is running from a slapd.d  con‐
22       figuration directory.
23
24       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
30              cn=Module
31                     dynamically loaded modules
32
33              cn=Schema
34                     schema definitions
35
36              olcBackend=xxx
37                     backend-specific settings
38
39              olcDatabase=xxx
40                     database-specific settings
41
42       The  cn=Module  entries  will only appear in configurations where slapd
43       was built with support for dynamically loaded  modules.  There  can  be
44       multiple  entries, one for each configured module path. Within each en‐
45       try there will be values recorded for each module  loaded  on  a  given
46       path. These entries have no children.
47
48       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
55       olcBackend entries are for storing settings specific to a single  back‐
56       end  type (and thus global to all database instances of that type).  At
57       present, only back-mdb implements any options of  this  type,  so  this
58       setting is not needed for any other backends.
59
60       olcDatabase  entries  store  settings specific to a single database in‐
61       stance. These entries may have olcOverlay child  entries  corresponding
62       to  any overlays configured on the database. The olcDatabase and olcOv‐
63       erlay entries may also have miscellaneous child entries for other  set‐
64       tings as needed. There are two special database entries that are prede‐
65       fined - one is an entry for the config database itself, and  the  other
66       is  for  the "frontend" database. Settings in the frontend database are
67       inherited by the other databases, unless they are explicitly overridden
68       in a specific database.
69
70       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
76       The parser for many of these attributes is the same as used for parsing
77       the slapd.conf keywords. As such, slapd.conf keywords that allow multi‐
78       ple  items  to  be specified on one line, separated by whitespace, will
79       allow multiple items to be specified in one attribute  value.  However,
80       when  reading the attribute via LDAP, the items will be returned as in‐
81       dividual attribute values.
82
83       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

GLOBAL CONFIGURATION OPTIONS

88       Options described in this section apply to the server as a whole.   Ar‐
89       guments  that  should  be replaced by actual text are shown in brackets
90       <>.
91
92       These options may only be specified in the cn=config entry. This  entry
93       must have an objectClass of olcGlobal.
94
95
96       olcAllows: <features>
97              Specify  a set of features to allow (default none).  bind_v2 al‐
98              lows acceptance of LDAPv2 bind  requests.   Note  that  slapd(8)
99              does  not  truly  implement LDAPv2 (RFC 1777), now Historic (RFC
100              3494).  bind_anon_cred allows anonymous  bind  when  credentials
101              are  not  empty  (e.g.   when DN is empty).  bind_anon_dn allows
102              unauthenticated (anonymous) bind when  DN  is  not  empty.   up‐
103              date_anon  allows  unauthenticated (anonymous) update operations
104              to be processed (subject to access controls and  other  adminis‐
105              trative   limits).    proxy_authz_anon   allows  unauthenticated
106              (anonymous) proxy authorization control to be processed (subject
107              to  access controls, authorization and other administrative lim‐
108              its).
109
110       olcArgsFile: <filename>
111              The (absolute) name of a file that will hold the slapd  server's
112              command line (program name and options).
113
114       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
121              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
133              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
138       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
147       olcAuthzPolicy: <policy>
148              Used to specify which rules  to  use  for  Proxy  Authorization.
149              Proxy  authorization  allows  a  client  to  authenticate to the
150              server using one user's credentials,  but  specify  a  different
151              identity  to  use for authorization and access control purposes.
152              It essentially allows user A to login as user B, using user  A's
153              password.   The  none flag disables proxy authorization. This is
154              the default setting.  The from flag will use rules  in  the  au‐
155              thzFrom attribute of the authorization DN.  The to flag will use
156              rules in the authzTo attribute of the  authentication  DN.   The
157              any  flag, an alias for the deprecated value of both, will allow
158              any of the above, whatever succeeds first (checked in  to,  from
159              sequence.  The all flag requires both authorizations to succeed.
160
161              The rules are mechanisms to specify which identities are allowed
162              to perform proxy authorization.  The authzFrom attribute  in  an
163              entry  specifies which other users are allowed to proxy login to
164              this entry. The authzTo attribute in an  entry  specifies  which
165              other  users  this  user can authorize as.  Use of authzTo rules
166              can be easily abused if users are  allowed  to  write  arbitrary
167              values to this attribute.  In general the authzTo attribute must
168              be protected with ACLs such that only privileged users can  mod‐
169              ify  it.   The value of authzFrom and authzTo describes an iden‐
170              tity or a set of identities; it can take five forms:
171
172                     ldap:///<base>??[<scope>]?<filter>
173                     dn[.<dnstyle>]:<pattern>
174                     u[.<mech>[<realm>]]:<pattern>
175                     group[/objectClass[/attributeType]]:<pattern>
176                     <pattern>
177
178                     <dnstyle>:={exact|onelevel|children|subtree|regex}
179
180              The first form is a valid LDAP URI where the <host>:<port>,  the
181              <attrs>  and  the  <extensions> portions must be absent, so that
182              the search occurs locally on either authzFrom or authzTo.
183
184
185              The second form is a DN, with the optional style  modifiers  ex‐
186              act,  onelevel, children, and subtree for exact, onelevel, chil‐
187              dren and subtree matches, which cause <pattern> to be normalized
188              according  to  the  DN normalization rules, or the special regex
189              style, which causes the <pattern>  to  be  treated  as  a  POSIX
190              (''extended'')  regular  expression,  as  discussed  in regex(7)
191              and/or re_format(7).  A pattern of * means any non-anonymous DN.
192
193
194              The third form is a SASL id, with the optional fields <mech> and
195              <realm> that allow to specify a SASL mechanism, and eventually a
196              SASL realm, for those mechanisms that support one.  The need  to
197              allow  the  specification  of  a mechanism is still debated, and
198              users are strongly discouraged to rely on this possibility.
199
200
201              The fourth form is a group specification.  It  consists  of  the
202              keyword  group,  optionally followed by the specification of the
203              group objectClass and attributeType.  The  objectClass  defaults
204              to  groupOfNames.   The  attributeType  defaults to member.  The
205              group with DN <pattern> is searched with base scope, filtered on
206              the  specified  objectClass.   The  values  of the resulting at‐
207              tributeType are searched for the asserted DN.
208
209
210              The fifth form is provided for backwards compatibility.   If  no
211              identity  type  is  provided, i.e. only <pattern> is present, an
212              exact DN is assumed; as a consequence, <pattern> is subjected to
213              DN normalization.
214
215
216              Since the interpretation of authzFrom and authzTo can impact se‐
217              curity, users are strongly encouraged to explicitly set the type
218              of identity specification that is being used.  A subset of these
219              rules can be used as third arg in the  olcAuthzRegexp  statement
220              (see  below); significantly, the URI, provided it results in ex‐
221              actly one entry, and the dn.exact:<dn> forms.
222
223       olcAuthzRegexp: <match> <replace>
224              Used by the authentication  framework  to  convert  simple  user
225              names,  such  as  provided  by SASL subsystem, or extracted from
226              certificates in case of cert-based SASL  EXTERNAL,  or  provided
227              within  the RFC 4370 "proxied authorization" control, to an LDAP
228              DN used for authorization purposes.  Note that the resulting  DN
229              need  not  refer  to  an  existing entry to be considered valid.
230              When an authorization request is received from the SASL  subsys‐
231              tem,  the  SASL  USERNAME,  REALM, and MECHANISM are taken, when
232              available, and combined into a name of the form
233
234                     UID=<username>[[,CN=<realm>],CN=<mechanism>],CN=auth
235
236              This name is  then  compared  against  the  match  POSIX  (''ex‐
237              tended'')  regular  expression,  and if the match is successful,
238              the name is replaced with the  replace  string.   If  there  are
239              wildcard  strings  in  the match regular expression that are en‐
240              closed in parenthesis, e.g.
241
242                     UID=([^,]*),CN=.*
243
244              then the portion of the name that matched the wildcard  will  be
245              stored  in  the  numbered  placeholder variable $1. If there are
246              other wildcard strings in parenthesis, the matching strings will
247              be  in  $2, $3, etc. up to $9. The placeholders can then be used
248              in the replace string, e.g.
249
250                     UID=$1,OU=Accounts,DC=example,DC=com
251
252              The replaced name can be either a DN, i.e. a string prefixed  by
253              "dn:",  or  an LDAP URI.  If the latter, the server will use the
254              URI to search its own database(s) and, if the search returns ex‐
255              actly  one  entry, the name is replaced by the DN of that entry.
256              The LDAP URI must have no hostport, attrs, or extensions  compo‐
257              nents, but the filter is mandatory, e.g.
258
259                     ldap:///OU=Accounts,DC=example,DC=com??one?(UID=$1)
260
261              The  protocol  portion  of  the URI must be strictly ldap.  Note
262              that this search is subject to access  controls.   Specifically,
263              the  authentication identity must have "auth" access in the sub‐
264              ject.
265
266              Multiple olcAuthzRegexp values can be  specified  to  allow  for
267              multiple  matching  and  replacement patterns. The matching pat‐
268              terns are checked in the order they  appear  in  the  attribute,
269              stopping at the first successful match.
270
271
272       olcConcurrency: <integer>
273              Specify  a desired level of concurrency.  Provided to the under‐
274              lying thread system as a hint.  The default is  not  to  provide
275              any  hint.  This  setting  is  only meaningful on some platforms
276              where there is not a one  to  one  correspondence  between  user
277              threads and kernel threads.
278
279       olcConnMaxPending: <integer>
280              Specify  the maximum number of pending requests for an anonymous
281              session.  If requests are submitted faster than the  server  can
282              process them, they will be queued up to this limit. If the limit
283              is exceeded, the session is closed. The default is 100.
284
285       olcConnMaxPendingAuth: <integer>
286              Specify the maximum number of pending requests for an  authenti‐
287              cated session.  The default is 1000.
288
289       olcDisallows: <features>
290              Specify a set of features to disallow (default none).  bind_anon
291              disables acceptance of anonymous bind requests.  Note that  this
292              setting  does  not prohibit anonymous directory access (See "re‐
293              quire authc").  bind_simple disables simple  (bind)  authentica‐
294              tion.   tls_2_anon  disables forcing session to anonymous status
295              (see also tls_authc) upon StartTLS operation receipt.  tls_authc
296              disallows  the  StartTLS  operation  if  authenticated (see also
297              tls_2_anon).  proxy_authz_non_critical  disables  acceptance  of
298              the proxied authorization control (RFC4370) with criticality set
299              to FALSE.  dontusecopy_non_critical disables acceptance  of  the
300              dontUseCopy control (a work in progress) with criticality set to
301              FALSE.
302
303       olcGentleHUP: { TRUE | FALSE }
304              A SIGHUP signal will only  cause  a  'gentle'  shutdown-attempt:
305              Slapd  will  stop  listening  for  new connections, but will not
306              close the connections to the current clients.  Future write  op‐
307              erations  return unwilling-to-perform, though.  Slapd terminates
308              when all clients have closed their  connections  (if  they  ever
309              do), or - as before - if it receives a SIGTERM signal.  This can
310              be useful if you wish to terminate the server and  start  a  new
311              slapd  server with another database, without disrupting the cur‐
312              rently active clients.  The default is FALSE.  You may  wish  to
313              use olcIdleTimeout along with this option.
314
315       olcIdleTimeout: <integer>
316              Specify the number of seconds to wait before forcibly closing an
317              idle client connection.  A setting of 0 disables  this  feature.
318              The  default  is 0. You may also want to set the olcWriteTimeout
319              option.
320
321       olcIndexHash64: { on | off }
322              Use a 64 bit hash for indexing. The default is  to  use  32  bit
323              hashes.  These hashes are used for equality and substring index‐
324              ing. The 64 bit version may be needed to avoid index  collisions
325              when  the  number  of  indexed values exceeds ~64 million. (Note
326              that substring indexing generates multiple index values per  ac‐
327              tual attribute value.)  Indices generated with 32 bit hashes are
328              incompatible with the 64 bit version, and vice versa. Any exist‐
329              ing databases must be fully reloaded when changing this setting.
330              This directive is only supported on 64 bit CPUs.
331
332       olcIndexIntLen: <integer>
333              Specify the key length for ordered  integer  indices.  The  most
334              significant  bytes  of the binary integer will be used for index
335              keys. The default value is 4, which provides exact indexing  for
336              31 bit values.  A floating point representation is used to index
337              too large values.
338
339       olcIndexSubstrIfMaxlen: <integer>
340              Specify the maximum length for subinitial and subfinal  indices.
341              Only  this  many  characters  of an attribute value will be pro‐
342              cessed by the indexing functions; any excess characters are  ig‐
343              nored. The default is 4.
344
345       olcIndexSubstrIfMinlen: <integer>
346              Specify  the minimum length for subinitial and subfinal indices.
347              An attribute value must have at least this  many  characters  in
348              order  to be processed by the indexing functions. The default is
349              2.
350
351       olcIndexSubstrAnyLen: <integer>
352              Specify the length used for subany indices. An  attribute  value
353              must  have  at  least  this  many characters in order to be pro‐
354              cessed. Attribute values longer than this length  will  be  pro‐
355              cessed  in segments of this length. The default is 4. The subany
356              index will also be used in subinitial and subfinal index lookups
357              when the filter string is longer than the olcIndexSubstrIfMaxlen
358              value.
359
360       olcIndexSubstrAnyStep: <integer>
361              Specify the steps used in subany index lookups. This value  sets
362              the  offset  for  the  segments of a filter string that are pro‐
363              cessed for a subany index lookup. The default is 2. For example,
364              with  the default values, a search using this filter "cn=*abcde‐
365              fgh*" would generate  index  lookups  for  "abcd",  "cdef",  and
366              "efgh".
367
368
369       Note:  Indexing support depends on the particular backend in use. Also,
370       changing these settings will generally  require  deleting  any  indices
371       that depend on these parameters and recreating them with slapindex(8).
372
373
374       olcListenerThreads: <integer>
375              Specify the number of threads to use for the connection manager.
376              The default is 1 and this is typically adequate for up to 16 CPU
377              cores.  The value should be set to a power of 2.
378
379       olcLocalSSF: <SSF>
380              Specifies  the  Security Strength Factor (SSF) to be given local
381              LDAP sessions, such as those to the ldapi://  listener.   For  a
382              description  of  SSF values, see olcSaslSecProps's minssf option
383              description.  The default is 71.
384
385       olcLogFile: <filename>
386              Specify a file for recording slapd debug  messages.  By  default
387              these  messages  only  go  to  stderr, are not recorded anywhere
388              else, and are unrelated to messages exposed by  the  olcLogLevel
389              configuration parameter. Specifying a logfile copies messages to
390              both stderr and the logfile.
391
392       olcLogFileFormat: debug | syslog-utc | syslog-localtime
393              Specify the prefix format for messages written to  the  logfile.
394              The  debug format is the normal format used for slapd debug mes‐
395              sages, with a timestamp in hexadecimal, followed by a thread ID.
396              The  other  options  are  to  use syslog(3) style prefixes, with
397              timestamps either in UTC or in the local timezone.  The  default
398              is debug format.
399
400       olcLogFileOnly: TRUE | FALSE
401              Specify  that  debug  messages  should only go to the configured
402              logfile, and not to stderr.
403
404       olcLogFileRotate: <max> <Mbytes> <hours>
405              Specify automatic rotation for the  configured  logfile  as  the
406              maximum  number  of  old  logfiles  to retain, a maximum size in
407              megabytes to allow a logfile to grow before rotation, and a max‐
408              imum  age in hours for a logfile to be used before rotation. The
409              maximum number must be in the range  1-99.   Setting  Mbytes  or
410              hours  to zero disables the size or age check, respectively.  At
411              least one of Mbytes or hours must be non-zero. By default no au‐
412              tomatic rotation will be performed.
413
414       olcLogLevel: <integer> [...]
415              Specify  the  level  at which debugging statements and operation
416              statistics should be syslogged (currently  logged  to  the  sys‐
417              logd(8)  LOG_LOCAL4  facility).  They must be considered subsys‐
418              tems rather than increasingly verbose log levels.  Some messages
419              with  higher  priority  are  logged regardless of the configured
420              loglevel as soon as any logging is configured.  Log  levels  are
421              additive, and available levels are:
422                     1      (0x1 trace) trace function calls
423                     2      (0x2 packets) debug packet handling
424                     4      (0x4 args) heavy trace debugging (function args)
425                     8      (0x8 conns) connection management
426                     16     (0x10 BER) print out packets sent and received
427                     32     (0x20 filter) search filter processing
428                     64     (0x40 config) configuration file processing
429                     128    (0x80 ACL) access control list processing
430                     256    (0x100  stats)  connections,  LDAP operations, re‐
431                            sults (recommended)
432                     512    (0x200 stats2) stats2 log entries sent
433                     1024   (0x400 shell) print communication with shell back‐
434                            ends
435                     2048   (0x800 parse) entry parsing
436
437
438
439
440
441
442
443
444                     16384  (0x4000 sync) LDAPSync replication
445                     32768  (0x8000  none) only messages that get logged what‐
446                            ever log level is set
447              The desired log level can be input as a single integer that com‐
448              bines the (ORed) desired levels, both in decimal or in hexadeci‐
449              mal notation, as a list of integers (that are ORed  internally),
450              or  as  a  list of the names that are shown between parenthesis,
451              such that
452
453                  olcLogLevel: 129
454                  olcLogLevel: 0x81
455                  olcLogLevel: 128 1
456                  olcLogLevel: 0x80 0x1
457                  olcLogLevel: acl trace
458
459              are equivalent.  The keyword any can be used as  a  shortcut  to
460              enable  logging  at  all levels (equivalent to -1).  The keyword
461              none, or the equivalent  integer  representation,  causes  those
462              messages  that  are  logged  regardless  of  the  configured ol‐
463              cLogLevel to be logged.  In fact, if  no  olcLogLevel  (or  a  0
464              level) is defined, no logging occurs, so at least the none level
465              is required to have high priority messages logged.
466
467              Note that the packets, BER, and parse levels are only  available
468              as debug output on stderr, and are not sent to syslog.
469
470              This  setting defaults to stats.  This level should usually also
471              be included when using other  loglevels,  to  help  analyze  the
472              logs.
473
474       olcMaxFilterDepth: <integer>
475              Specify  the maximum depth of nested filters in search requests.
476              The default is 1000.
477
478       olcPasswordCryptSaltFormat: <format>
479              Specify the format of the salt passed to crypt(3) when  generat‐
480              ing {CRYPT} passwords (see olcPasswordHash) during processing of
481              LDAP Password Modify Extended Operations (RFC 3062).
482
483              This string needs to be in sprintf(3) format and may include one
484              (and  only  one) %s conversion.  This conversion will be substi‐
485              tuted with a string of  random  characters  from  [A-Za-z0-9./].
486              For  example, "%.2s" provides a two character salt and "$1$%.8s"
487              tells some versions of crypt(3) to use an MD5 algorithm and pro‐
488              vides  8  random characters of salt.  The default is "%s", which
489              provides 31 characters of salt.
490
491       olcPidFile: <filename>
492              The (absolute) name of a file that will hold the slapd  server's
493              process ID (see getpid(2)).
494
495       olcPluginLogFile: <filename>
496              The  (  absolute ) name of a file that will contain log messages
497              from SLAPI plugins. See slapd.plugin(5) for details.
498
499       olcReferral: <url>
500              Specify the referral to pass back when slapd(8)  cannot  find  a
501              local  database  to  handle  a  request.  If multiple values are
502              specified, each url is provided.
503
504       olcReverseLookup: TRUE | FALSE
505              Enable/disable client name unverified reverse lookup (default is
506              FALSE if compiled with --enable-rlookups).
507
508       olcRootDSE: <file>
509              Specify  the name of an LDIF(5) file containing user defined at‐
510              tributes for the root DSE.  These attributes are returned in ad‐
511              dition to the attributes normally produced by slapd.
512
513              The  root  DSE is an entry with information about the server and
514              its capabilities, in operational attributes.  It has  the  empty
515              DN, and can be read with e.g.:
516                  ldapsearch -x -b "" -s base "+"
517              See RFC 4512 section 5.1 for details.
518
519       olcSaslAuxprops: <plugin> [...]
520              Specify which auxprop plugins to use for authentication lookups.
521              The default is empty, which just uses slapd's internal  support.
522              Usually no other auxprop plugins are needed.
523
524       olcSaslAuxpropsDontUseCopy: <attr> [...]
525              Specify  which  attribute(s)  should be subject to the don't use
526              copy control. This is necessary for some SASL mechanisms such as
527              OTP   to   work  in  a  replicated  environment.  The  attribute
528              "cmusaslsecretOTP" is the default value.
529
530       olcSaslAuxpropsDontUseCopyIgnore TRUE | FALSE
531              Used to disable replication of the attribute(s) defined by  olc‐
532              SaslAuxpropsDontUseCopy  and  instead  use a local value for the
533              attribute. This allows the SASL mechanism to continue to work if
534              the  provider  is  offline. This can cause replication inconsis‐
535              tency. Defaults to FALSE.
536
537       olcSaslHost: <fqdn>
538              Used to specify the fully qualified domain name  used  for  SASL
539              processing.
540
541       olcSaslRealm: <realm>
542              Specify SASL realm.  Default is empty.
543
544       olcSaslCbinding: none | tls-unique | tls-endpoint
545              Specify      the      channel-binding     type,     see     also
546              LDAP_OPT_X_SASL_CBINDING.  Default is none.
547
548       olcSaslSecProps: <properties>
549              Used to specify Cyrus SASL security properties.  The  none  flag
550              (without  any  other  properties) causes the flag properties de‐
551              fault, "noanonymous,noplain", to be cleared.  The  noplain  flag
552              disables  mechanisms susceptible to simple passive attacks.  The
553              noactive flag disables mechanisms susceptible to active attacks.
554              The  nodict flag disables mechanisms susceptible to passive dic‐
555              tionary attacks.  The noanonymous flag disables mechanisms which
556              support  anonymous  login.   The forwardsec flag require forward
557              secrecy between sessions.  The passcred require mechanisms which
558              pass  client  credentials  (and  allow mechanisms which can pass
559              credentials to do so).  The minssf=<factor>  property  specifies
560              the  minimum  acceptable  security strength factor as an integer
561              approximate to effective key  length  used  for  encryption.   0
562              (zero)  implies  no  protection,  1 implies integrity protection
563              only, 128 allows RC4, Blowfish and other  similar  ciphers,  256
564              will   require   modern   ciphers.    The  default  is  0.   The
565              maxssf=<factor> property specifies the maximum acceptable  secu‐
566              rity  strength  factor  as  an integer (see minssf description).
567              The default is INT_MAX.  The maxbufsize=<size>  property  speci‐
568              fies  the maximum security layer receive buffer size allowed.  0
569              disables security layers.  The default is 65536.
570
571       olcServerID: <integer> [<URL>]
572              Specify an integer ID from 0 to 4095 for this server. The ID may
573              also  be  specified  as  a hexadecimal ID by prefixing the value
574              with "0x".  Non-zero IDs are required when using  multi-provider
575              replication  and  each  provider must have a unique non-zero ID.
576              Note that this requirement also applies  to  separate  providers
577              contributing  to  a  glued set of databases.  If the URL is pro‐
578              vided, this directive may be specified multiple times, providing
579              a  complete  list  of  participating  servers and their IDs. The
580              fully qualified hostname of each server should be  used  in  the
581              supplied URLs. The IDs are used in the "replica id" field of all
582              CSNs generated by the specified server.  The  default  value  is
583              zero,  which is only valid for single provider replication.  Ex‐
584              ample:
585
586            olcServerID: 1 ldap://ldap1.example.com
587            olcServerID: 2 ldap://ldap2.example.com
588
589       olcSockbufMaxIncoming: <integer>
590              Specify the maximum incoming LDAP PDU size  for  anonymous  ses‐
591              sions.  The default is 262143.
592
593       olcSockbufMaxIncomingAuth: <integer>
594              Specify  the  maximum  incoming  LDAP PDU size for authenticated
595              sessions.  The default is 4194303.
596
597       olcTCPBuffer [listener=<URL>] [{read|write}=]<size>
598              Specify the size of the TCP buffer.  A  global  value  for  both
599              read  and  write TCP buffers related to any listener is defined,
600              unless the listener is explicitly specified, or either the  read
601              or  write  qualifiers  are  used.  See tcp(7) for details.  Note
602              that some OS-es implement automatic TCP buffer tuning.
603
604       olcThreads: <integer>
605              Specify the maximum size of the primary thread  pool.   The  de‐
606              fault is 16; the minimum value is 2.
607
608       olcThreadQueues: <integer>
609              Specify  the number of work queues to use for the primary thread
610              pool.  The default is 1 and this is typically adequate for up to
611              8  CPU cores.  The value should not exceed the number of CPUs in
612              the system.
613
614       olcToolThreads: <integer>
615              Specify the maximum number of threads to use in tool mode.  This
616              should  not  be  greater  than the number of CPUs in the system.
617              The default is 1.
618
619       olcWriteTimeout: <integer>
620              Specify the number of seconds to wait before forcibly closing  a
621              connection with an outstanding write.  This allows recovery from
622              various network hang conditions.  A setting of 0  disables  this
623              feature.  The default is 0.
624

TLS OPTIONS

626       If  slapd is built with support for Transport Layer Security, there are
627       more options you can specify.
628
629       When using OpenSSL, if neither  olcTLSCACertificateFile nor  olcTLSCAC‐
630       ertificatePath  is  set, the system-wide default set of CA certificates
631       is used.
632
633       olcTLSCipherSuite: <cipher-suite-spec>
634              Permits configuring what ciphers will be accepted and the  pref‐
635              erence order.  <cipher-suite-spec> should be a cipher specifica‐
636              tion for the TLS library in use (OpenSSL or GnuTLS).  Example:
637
638                     OpenSSL:
639                            olcTLSCipherSuite: HIGH:MEDIUM:+SSLv2
640
641                     GnuTLS:
642                            olcTLSCiphersuite: SECURE256:!AES-128-CBC
643
644              To check what ciphers a given spec selects in OpenSSL, use:
645
646                   openssl ciphers -v <cipher-suite-spec>
647
648              With GnuTLS the available specs can be found in the manual  page
649              of gnutls-cli(1) (see the description of the option --priority).
650
651              In  older  versions of GnuTLS, where gnutls-cli does not support
652              the option --priority, you can obtain the — more limited —  list
653              of ciphers by calling:
654
655                   gnutls-cli -l
656
657       olcTLSCACertificateFile: <filename>
658              Specifies  the  file  that  contains certificates for all of the
659              Certificate Authorities that slapd will recognize.  The certifi‐
660              cate  for  the CA that signed the server certificate must be in‐
661              cluded among these certificates. If the signing  CA  was  not  a
662              top-level  (root)  CA,  certificates  for the entire sequence of
663              CA's from the signing CA to the top-level CA should be  present.
664              Multiple certificates are simply appended to the file; the order
665              is not significant.
666
667       olcTLSCACertificatePath: <path>
668              Specifies the path of directories that contain  Certificate  Au‐
669              thority  certificates in separate individual files. Usually only
670              one of this or the olcTLSCACertificateFile is defined.  If  both
671              are specified, both locations will be used. Multiple directories
672              may be specified, separated by a semi-colon.
673
674       olcTLSCertificateFile: <filename>
675              Specifies the file that contains the slapd server certificate.
676
677              When using OpenSSL that file may also contain any number of  in‐
678              termediate certificates after the server certificate.
679
680       olcTLSCertificateKeyFile: <filename>
681              Specifies  the  file  that contains the slapd server private key
682              that matches the certificate stored in the olcTLSCertificateFile
683              file. If the private key is protected with a password, the pass‐
684              word must be manually typed in when slapd starts.   Usually  the
685              private  key is not protected with a password, to allow slapd to
686              start without manual intervention, so it is of  critical  impor‐
687              tance that the file is protected carefully.
688
689       olcTLSDHParamFile: <filename>
690              This  directive  specifies the file that contains parameters for
691              Diffie-Hellman ephemeral key exchange.  This is required in  or‐
692              der  to  use a DSA certificate on the server, or an RSA certifi‐
693              cate missing the "key encipherment" key usage.  Note  that  set‐
694              ting  this  option  may also enable Anonymous Diffie-Hellman key
695              exchanges in certain non-default cipher suites.   Anonymous  key
696              exchanges  should generally be avoided since they provide no ac‐
697              tual client or server authentication and provide  no  protection
698              against  man-in-the-middle attacks.  You should append "!ADH" to
699              your cipher suites to ensure that these suites are not used.
700
701       olcTLSECName: <name>
702              Specify the name of the  curve(s)  to  use  for  Elliptic  curve
703              Diffie-Hellman ephemeral key exchange.  This option is only used
704              for OpenSSL.  This option is not used with  GnuTLS;  the  curves
705              may be chosen in the GnuTLS ciphersuite specification.
706
707       olcTLSProtocolMin: <major>[.<minor>]
708              Specifies  minimum SSL/TLS protocol version that will be negoti‐
709              ated.  If the server doesn't support at least that version,  the
710              SSL handshake will fail.  To require TLS 1.x or higher, set this
711              option to 3.(x+1), e.g.,
712
713                   olcTLSProtocolMin: 3.2
714
715              would require TLS 1.1.  Specifying a minimum that is higher than
716              that  supported by the OpenLDAP implementation will result in it
717              requiring the highest level that it does support.   This  direc‐
718              tive is ignored with GnuTLS.
719
720       olcTLSRandFile: <filename>
721              Specifies  the file to obtain random bits from when /dev/[u]ran‐
722              dom is  not  available.   Generally  set  to  the  name  of  the
723              EGD/PRNGD socket.  The environment variable RANDFILE can also be
724              used to specify the filename.  This directive  is  ignored  with
725              GnuTLS.
726
727       olcTLSVerifyClient: <level>
728              Specifies  what  checks  to perform on client certificates in an
729              incoming TLS session, if any.  The <level> can be  specified  as
730              one of the following keywords:
731
732              never  This is the default.  slapd will not ask the client for a
733                     certificate.
734
735              allow  The client certificate is requested.  If  no  certificate
736                     is  provided,  the  session  proceeds normally.  If a bad
737                     certificate is provided, it will be ignored and the  ses‐
738                     sion proceeds normally.
739
740              try    The  client  certificate is requested.  If no certificate
741                     is provided, the session proceeds  normally.   If  a  bad
742                     certificate  is provided, the session is immediately ter‐
743                     minated.
744
745              demand | hard | true
746                     These keywords are all equivalent, for compatibility rea‐
747                     sons.   The  client certificate is requested.  If no cer‐
748                     tificate is provided, or a bad certificate  is  provided,
749                     the session is immediately terminated.
750
751                     Note that a valid client certificate is required in order
752                     to use the SASL EXTERNAL authentication mechanism with  a
753                     TLS  session.   As such, a non-default olcTLSVerifyClient
754                     setting must be chosen to enable SASL EXTERNAL  authenti‐
755                     cation.
756
757       olcTLSCRLCheck: <level>
758              Specifies  if  the  Certificate  Revocation List (CRL) of the CA
759              should be used to verify if the  client  certificates  have  not
760              been revoked. This requires olcTLSCACertificatePath parameter to
761              be set. This parameter is ignored with GnuTLS.  <level>  can  be
762              specified as one of the following keywords:
763
764              none   No CRL checks are performed
765
766              peer   Check the CRL of the peer certificate
767
768              all    Check the CRL for a whole certificate chain
769
770       olcTLSCRLFile: <filename>
771              Specifies  a file containing a Certificate Revocation List to be
772              used for verifying that certificates have not been revoked. This
773              parameter is only valid when using GnuTLS.
774

DYNAMIC MODULE OPTIONS

776       If  slapd is compiled with --enable-modules then the module-related en‐
777       tries will be available. These entries are named cn=module{x},cn=config
778       and  must  have the olcModuleList objectClass. One entry should be cre‐
779       ated per olcModulePath.  Normally the config engine generates the "{x}"
780       index  in  the  RDN  automatically, so it can be omitted when initially
781       loading these entries.
782
783       olcModuleLoad: <filename> [<arguments>...]
784              Specify the name of a dynamically loadable module  to  load  and
785              any  additional  arguments if supported by the module. The file‐
786              name may be an absolute path name or a simple filename.  Non-ab‐
787              solute  names  are  searched for in the directories specified by
788              the olcModulePath option.
789
790       olcModulePath: <pathspec>
791              Specify a list of directories to search  for  loadable  modules.
792              Typically  the  path  is colon-separated but this depends on the
793              operating system.  The default is /usr/lib64/openldap, which  is
794              where the standard OpenLDAP install will place its modules.
795

SCHEMA OPTIONS

797       Schema  definitions  are  created as entries in the cn=schema,cn=config
798       subtree. These entries must have the olcSchemaConfig  objectClass.   As
799       noted above, the actual cn=schema,cn=config entry is predefined and any
800       values specified for it are ignored.
801
802
803       olcAttributetypes:    ( <oid>    [NAME <name>]     [DESC <description>]
804              [OBSOLETE]    [SUP <oid>]    [EQUALITY <oid>]   [ORDERING <oid>]
805              [SUBSTR <oid>]  [SYNTAX <oidlen>]  [SINGLE-VALUE]   [COLLECTIVE]
806              [NO-USER-MODIFICATION] [USAGE <attributeUsage>] )
807              Specify an attribute type using the LDAPv3 syntax defined in RFC
808              4512.  The slapd parser  extends  the  RFC  4512  definition  by
809              allowing string forms as well as numeric OIDs to be used for the
810              attribute   OID   and   attribute   syntax   OID.    (See    the
811              olcObjectIdentifier description.)
812
813
814       olcDitContentRules:    ( <oid>    [NAME <name>]    [DESC <description>]
815              [OBSOLETE]     [AUX <oids>]      [MUST <oids>]      [MAY <oids>]
816              [NOT <oids>] )
817              Specify  an  DIT Content Rule using the LDAPv3 syntax defined in
818              RFC 4512.  The slapd parser extends the RFC 4512  definition  by
819              allowing string forms as well as numeric OIDs to be used for the
820              attribute   OID   and   attribute   syntax   OID.    (See    the
821              olcObjectIdentifier description.)
822
823
824       olcLdapSyntaxes   ( <oid>  [DESC <description>]  [X-SUBST  <substitute-
825              syntax>] )
826              Specify an LDAP syntax using the LDAPv3 syntax  defined  in  RFC
827              4512.   The  slapd  parser  extends  the  RFC 4512 definition by
828              allowing string forms as well as numeric OIDs to be used for the
829              syntax  OID.  (See the objectidentifier description.)  The slapd
830              parser also honors the X-SUBST extension  (an  OpenLDAP-specific
831              extension),   which   allows  one  to  use  the  olcLdapSyntaxes
832              attribute to define a non-implemented syntax along with  another
833              syntax,  the extension value substitute-syntax, as its temporary
834              replacement.   The  substitute-syntax  must  be  defined.   This
835              allows  one  to  define  attribute  types  that make use of non-
836              implemented syntaxes  using  the  correct  syntax  OID.   Unless
837              X-SUBST is used, this configuration statement would result in an
838              error, since no handlers would be associated  to  the  resulting
839              syntax structure.
840
841
842       olcObjectClasses: ( <oid> [NAME <name>] [DESC <description>] [OBSOLETE]
843              [SUP <oids>]  [{  ABSTRACT   |   STRUCTURAL   |   AUXILIARY   }]
844              [MUST <oids>] [MAY <oids>] )
845              Specify  an  objectclass  using the LDAPv3 syntax defined in RFC
846              4512.  The slapd parser  extends  the  RFC  4512  definition  by
847              allowing string forms as well as numeric OIDs to be used for the
848              object class OID.  (See  the  olcObjectIdentifier  description.)
849              Object classes are "STRUCTURAL" by default.
850
851       olcObjectIdentifier: <name> { <oid> | <name>[:<suffix>] }
852              Define  a  string name that equates to the given OID. The string
853              can be used in place of  the  numeric  OID  in  objectclass  and
854              attribute  definitions.  The name can also be used with a suffix
855              of the form ":xx" in which case the value "oid.xx" will be used.
856
857

GENERAL BACKEND OPTIONS

859       Options in these entries only apply to the configuration  of  a  single
860       type  of  backend.  All backends may support this class of options, but
861       currently   only   back-mdb   does.    The   entry   must   be    named
862       olcBackend=<databasetype>,cn=config  and must have the olcBackendConfig
863       objectClass.   <databasetype>  should  be  one  of  asyncmeta,  config,
864       dnssrv,  ldap,  ldif,  mdb,  meta,  monitor, null, passwd, perl, relay,
865       sock, sql, or wt.  At present, only back-mdb implements any options  of
866       this type, so this entry should not be used for any other backends.
867
868

DATABASE OPTIONS

870       Database      options      are      set      in      entries      named
871       olcDatabase={x}<databasetype>,cn=config    and    must     have     the
872       olcDatabaseConfig objectClass. Normally the config engine generates the
873       "{x}" index in the  RDN  automatically,  so  it  can  be  omitted  when
874       initially loading these entries.
875
876       The  special frontend database is always numbered "{-1}" and the config
877       database is always numbered "{0}".
878
879

GLOBAL DATABASE OPTIONS

881       Options in this section may be set in the special  "frontend"  database
882       and  inherited in all the other databases. These options may be altered
883       by further settings in each specific database. The frontend entry  must
884       be    named    olcDatabase=frontend,cn=config   and   must   have   the
885       olcFrontendConfig objectClass.
886
887       olcAccess: to <what> [ by <who> <access> <control> ]+
888              Grant access (specified by <access>) to a set of entries  and/or
889              attributes  (specified  by  <what>)  by  one  or more requestors
890              (specified by <who>).  If no access controls  are  present,  the
891              default  policy  allows anyone and everyone to read anything but
892              restricts updates to rootdn.   (e.g.,  "olcAccess:  to  *  by  *
893              read").   See  slapd.access(5) and the "OpenLDAP Administrator's
894              Guide" for details.
895
896              Access controls set in the frontend are appended to  any  access
897              controls  set  on  the  specific  databases.   The  rootdn  of a
898              database can always read and write EVERYTHING in that database.
899
900              Extra special care must be taken with the access controls on the
901              config  database. Unlike other databases, the default policy for
902              the config database is to  only  allow  access  to  the  rootdn.
903              Regular  users  should  not  have  read access, and write access
904              should be granted very carefully to privileged administrators.
905
906
907       olcDefaultSearchBase: <dn>
908              Specify a default search base to use when client submits a  non-
909              base  search  request with an empty base DN.  Base scoped search
910              requests with an empty base DN are not affected.   This  setting
911              is only allowed in the frontend entry.
912
913       olcExtraAttrs: <attr>
914              Lists  what  attributes  need  to  be  added to search requests.
915              Local storage backends return the entire entry to the  frontend.
916              The   frontend  takes  care  of  only  returning  the  requested
917              attributes that are allowed by  ACLs.   However,  features  like
918              access checking and so may need specific attributes that are not
919              automatically returned by remote storage  backends,  like  proxy
920              backends  and  so on.  <attr> is an attribute that is needed for
921              internal purposes and thus always needs to  be  collected,  even
922              when  not  explicitly  requested  by clients.  This attribute is
923              multi-valued.
924
925       olcPasswordHash: <hash> [<hash>...]
926              This option  configures  one  or  more  hashes  to  be  used  in
927              generation   of   user  passwords  stored  in  the  userPassword
928              attribute during processing of  LDAP  Password  Modify  Extended
929              Operations (RFC 3062).  The <hash> must be one of {SSHA}, {SHA},
930              {SMD5}, {MD5}, {CRYPT}, and {CLEARTEXT}.  The default is {SSHA}.
931
932              {SHA} and {SSHA} use  the  SHA-1  algorithm  (FIPS  160-1),  the
933              latter with a seed.
934
935              {MD5}  and  {SMD5}  use the MD5 algorithm (RFC 1321), the latter
936              with a seed.
937
938              {CRYPT} uses the crypt(3).
939
940              {CLEARTEXT} indicates that the new password should be  added  to
941              userPassword as clear text.
942
943              Note   that   this   option  does  not  alter  the  normal  user
944              applications handling of userPassword during LDAP  Add,  Modify,
945              or  other  LDAP operations.  This setting is only allowed in the
946              frontend entry.
947
948       olcReadOnly: TRUE | FALSE
949              This option  puts  the  database  into  "read-only"  mode.   Any
950              attempts  to  modify  the  database will return an "unwilling to
951              perform" error.  By default, olcReadOnly  is  FALSE.  Note  that
952              when this option is set TRUE on the frontend, it cannot be reset
953              without restarting the  server,  since  further  writes  to  the
954              config database will be rejected.
955
956       olcRequires: <conditions>
957              Specify  a  set  of  conditions  to require (default none).  The
958              directive  may  be  specified  globally   and/or   per-database;
959              databases    inherit    global   conditions,   so   per-database
960              specifications are additive.  bind requires bind operation prior
961              to  directory  operations.   LDAPv3 requires session to be using
962              LDAP  version  3.   authc  requires  authentication   prior   to
963              directory  operations.   SASL requires SASL authentication prior
964              to directory operations.  strong requires strong  authentication
965              prior  to  directory  operations.   The  strong  keyword  allows
966              protected   "simple"   authentication   as    well    as    SASL
967              authentication.   none  may  be  used  to  require no conditions
968              (useful to clear out globally set conditions within a particular
969              database); it must occur first in the list of conditions.
970
971       olcRestrict: <oplist>
972              Specify  a list of operations that are restricted.  Restrictions
973              on  a  specific  database   override   any   frontend   setting.
974              Operations   can   be   any   of  add,  bind,  compare,  delete,
975              extended[=<OID>], modify, rename, search, or the special pseudo-
976              operations read and write, which respectively summarize read and
977              write operations.  The use of restrict write  is  equivalent  to
978              olcReadOnly:  TRUE (see above).  The extended keyword allows one
979              to indicate the OID of the specific operation to be restricted.
980
981       olcSchemaDN: <dn>
982              Specify the distinguished name for the subschema  subentry  that
983              controls   the   entries   on   this  server.   The  default  is
984              "cn=Subschema".
985
986       olcSecurity: <factors>
987              Specify a set of security strength factors (separated  by  white
988              space)  to  require  (see  olcSaslSecprops's minssf option for a
989              description of security strength factors).  The directive may be
990              specified  globally  and/or per-database.  ssf=<n> specifies the
991              overall security strength factor.  transport=<n>  specifies  the
992              transport  security  strength factor.  tls=<n> specifies the TLS
993              security strength factor.  sasl=<n> specifies the SASL  security
994              strength  factor.  update_ssf=<n> specifies the overall security
995              strength   factor   to   require    for    directory    updates.
996              update_transport=<n>  specifies  the transport security strength
997              factor  to  require  for  directory   updates.    update_tls=<n>
998              specifies  the  TLS  security  strength  factor  to  require for
999              directory updates.  update_sasl=<n> specifies the SASL  security
1000              strength    factor    to    require   for   directory   updates.
1001              simple_bind=<n> specifies the security strength factor  required
1002              for  simple  username/password  authentication.   Note  that the
1003              transport  factor  is  measure  of  security  provided  by   the
1004              underlying  transport, e.g. ldapi:// (and eventually IPSEC).  It
1005              is not normally used.
1006
1007       olcSizeLimit: {<integer>|unlimited}
1008
1009       olcSizeLimit: size[.{soft|hard}]=<integer> [...]
1010              Specify the maximum number of entries to return  from  a  search
1011              operation.   The  default  size  limit is 500.  Use unlimited to
1012              specify no limits.   The  second  format  allows  a  fine  grain
1013              setting  of  the  size  limits.   If  no  special qualifiers are
1014              specified, both soft and hard limits are set.  Extra args can be
1015              added  in  the same value.  Additional qualifiers are available;
1016              see olcLimits for an explanation of all of the different flags.
1017
1018       olcSortVals: <attr> [...]
1019              Specify a list of  multi-valued  attributes  whose  values  will
1020              always  be  maintained  in  sorted order. Using this option will
1021              allow  Modify,  Compare,  and  filter   evaluations   on   these
1022              attributes  to be performed more efficiently. The resulting sort
1023              order depends on the attributes' syntax and matching  rules  and
1024              may  not  correspond  to lexical order or any other recognizable
1025              order.  This setting is only allowed in the frontend entry.
1026
1027       olcTimeLimit: {<integer>|unlimited}
1028
1029       olcTimeLimit: time[.{soft|hard}]=<integer> [...]
1030              Specify the maximum number of seconds (in real time) slapd  will
1031              spend  answering  a  search  request.  The default time limit is
1032              3600.  Use unlimited to specify no limits.   The  second  format
1033              allows  a fine grain setting of the time limits.  Extra args can
1034              be added in the same value. See olcLimits for an explanation  of
1035              the different flags.
1036
1037

GENERAL DATABASE OPTIONS

1039       Options  in  this section only apply to the specific database for which
1040       they are defined.  They are supported by every type of backend. All  of
1041       the Global Database Options may also be used here.
1042
1043       olcAddContentAcl: TRUE | FALSE
1044              Controls  whether  Add operations will perform ACL checks on the
1045              content of the entry being added. This check is off by  default.
1046              See  the  slapd.access(5)  manual  page  for more details on ACL
1047              requirements for Add operations.
1048
1049       olcHidden: TRUE | FALSE
1050              Controls whether the database will be used to answer queries.  A
1051              database  that  is  hidden  will never be selected to answer any
1052              queries, and any suffix  configured  on  the  database  will  be
1053              ignored  in  checks  for  conflicts  with  other  databases.  By
1054              default, olcHidden is FALSE.
1055
1056       olcLastMod: TRUE | FALSE
1057              Controls  whether  slapd   will   automatically   maintain   the
1058              modifiersName,      modifyTimestamp,      creatorsName,      and
1059              createTimestamp attributes for entries.  It  also  controls  the
1060              entryCSN  and  entryUUID  attributes,  which  are  needed by the
1061              syncrepl provider. By default, olcLastMod is TRUE.
1062
1063       olcLastBind: TRUE | FALSE
1064              Controls  whether  slapd   will   automatically   maintain   the
1065              pwdLastSuccess attribute for entries. By default, olcLastBind is
1066              FALSE.
1067
1068       olcLastBindPrecision: <integer>
1069              If   olcLastBind   is   enabled,   specifies   how    frequently
1070              pwdLastSuccess  will  be updated. More than integer seconds must
1071              have passed since the last  successful  bind.  In  a  replicated
1072              environment  with frequent bind activity it may be useful to set
1073              this to a large value.
1074
1075       olcLimits: <selector> <limit> [<limit> [...]]
1076              Specify time and size limits based on the operation's  initiator
1077              or base DN.  The argument <selector> can be any of
1078
1079                     anonymous    |    users    |    [<dnspec>=]<pattern>    |
1080                     group[/oc[/at]]=<pattern>
1081
1082              with
1083
1084                     <dnspec> ::= dn[.<type>][.<style>]
1085
1086                     <type>  ::= self | this
1087
1088                     <style> ::= exact | base | onelevel | subtree |  children
1089                     | regex | anonymous
1090
1091              DN type self is the default and means the bound user, while this
1092              means the base DN of the operation.  The term anonymous  matches
1093              all   unauthenticated  clients.   The  term  users  matches  all
1094              authenticated clients; otherwise an exact dn pattern is  assumed
1095              unless  otherwise  specified  by  qualifying  the (optional) key
1096              string dn with exact or base (which are synonyms), to require an
1097              exact  match;  with  onelevel,  to  require exactly one level of
1098              depth match; with subtree, to allow any level  of  depth  match,
1099              including  the exact match; with children, to allow any level of
1100              depth match, not including the  exact  match;  regex  explicitly
1101              requires  the  (default)  match  based  on  POSIX (''extended'')
1102              regular expression pattern.  Finally, anonymous matches  unbound
1103              operations;  the pattern field is ignored.  The same behavior is
1104              obtained by using the anonymous form of the  <selector>  clause.
1105              The   term   group,   with   the  optional  objectClass  oc  and
1106              attributeType at fields, followed by pattern,  sets  the  limits
1107              for  any  DN  listed  in the values of the at attribute (default
1108              member) of the oc group objectClass (default groupOfNames) whose
1109              DN exactly matches pattern.
1110
1111              The currently supported limits are size and time.
1112
1113              The  syntax  for  time  limits  is time[.{soft|hard}]=<integer>,
1114              where  integer  is  the  number  of  seconds  slapd  will  spend
1115              answering  a  search  request.   If  no time limit is explicitly
1116              requested by  the  client,  the  soft  limit  is  used;  if  the
1117              requested  time  limit  exceeds the hard limit, the value of the
1118              limit is used instead.  If the hard limit is set to the  keyword
1119              soft, the soft limit is used in either case; if it is set to the
1120              keyword unlimited, no hard limit is enforced.  Explicit requests
1121              for  time limits smaller or equal to the hard limit are honored.
1122              If no limit specifier is set, the value is assigned to the  soft
1123              limit,  and  the  hard  limit  is  set  to soft, to preserve the
1124              original behavior.
1125
1126              The        syntax        for        size        limits        is
1127              size[.{soft|hard|unchecked}]=<integer>,  where  integer  is  the
1128              maximum number of entries slapd will return answering  a  search
1129              request.   If  no  size  limit  is  explicitly  requested by the
1130              client, the soft limit is used;  if  the  requested  size  limit
1131              exceeds  the hard limit, the value of the limit is used instead.
1132              If the hard limit is set to the keyword soft, the soft limit  is
1133              used  in  either case; if it is set to the keyword unlimited, no
1134              hard limit is  enforced.   Explicit  requests  for  size  limits
1135              smaller  or  equal to the hard limit are honored.  The unchecked
1136              specifier sets a limit on the  number  of  candidates  a  search
1137              request  is allowed to examine.  The rationale behind it is that
1138              searches for non-properly indexed attributes may result in large
1139              sets  of  candidates,  which  must  be  examined  by slapd(8) to
1140              determine whether they match the  search  filter  or  not.   The
1141              unchecked  limit provides a means to drop such operations before
1142              they are even started.  If the selected  candidates  exceed  the
1143              unchecked  limit,  the  search  will  abort  with  Unwilling  to
1144              perform.  If it is set to the keyword  unlimited,  no  limit  is
1145              applied  (the default).  If it is set to disabled, the search is
1146              not even performed; this can be used to disallow searches for  a
1147              specific  set of users.  If no limit specifier is set, the value
1148              is assigned to the soft limit, and the  hard  limit  is  set  to
1149              soft, to preserve the original behavior.
1150
1151              In  case  of  no match, the global limits are used.  The default
1152              values are the same as for  olcSizeLimit  and  olcTimeLimit;  no
1153              limit is set on unchecked.
1154
1155              If  pagedResults  control  is  requested, the hard size limit is
1156              used by default, because the request of a specific page size  is
1157              considered an explicit request for a limitation on the number of
1158              entries to be returned.  However, the size limit applies to  the
1159              total  count of entries returned within the search, and not to a
1160              single page.  Additional size limits may be enforced; the syntax
1161              is  size.pr={<integer>|noEstimate|unlimited},  where  integer is
1162              the max page size if no  explicit  limit  is  set;  the  keyword
1163              noEstimate inhibits the server from returning an estimate of the
1164              total number of  entries  that  might  be  returned  (note:  the
1165              current  implementation  does  not  return  any  estimate).  The
1166              keyword unlimited indicates that no  limit  is  applied  to  the
1167              pagedResults      control     page     size.      The     syntax
1168              size.prtotal={<integer>|hard|unlimited|disabled} allows  one  to
1169              set a limit on the total number of entries that the pagedResults
1170              control will return.  By default it is set  to  the  hard  limit
1171              which  will  use  the size.hard value.  When set, integer is the
1172              max number of entries that the whole  search  with  pagedResults
1173              control  can return.  Use unlimited to allow unlimited number of
1174              entries  to  be  returned,  e.g.  to  allow  the  use   of   the
1175              pagedResults  control  as a means to circumvent size limitations
1176              on regular searches; the keyword disabled disables the  control,
1177              i.e.  no  paged  results  can  be returned.  Note that the total
1178              number of entries returned  when  the  pagedResults  control  is
1179              requested  cannot exceed the hard size limit of regular searches
1180              unless extended by the prtotal switch.
1181
1182              The olcLimits statement is typically used to  let  an  unlimited
1183              number  of  entries  be  returned by searches performed with the
1184              identity used by the consumer for  synchronization  purposes  by
1185              means of the RFC 4533 LDAP Content Synchronization protocol (see
1186              olcSyncrepl for details).
1187
1188              When using subordinate databases, it is necessary for any limits
1189              that are to be applied across the parent and its subordinates to
1190              be defined in both the parent and  its  subordinates.  Otherwise
1191              the settings on the subordinate databases are not honored.
1192
1193       olcMaxDerefDepth: <depth>
1194              Specifies  the  maximum  number  of  aliases to dereference when
1195              trying to resolve an entry, used to avoid infinite alias  loops.
1196              The default is 15.
1197
1198       olcMultiProvider: TRUE | FALSE
1199              This  option  puts a consumer database into Multi-Provider mode.
1200              Update operations will be accepted from any user, not  just  the
1201              updatedn.  The database must already be configured as a syncrepl
1202              consumer before this keyword may be set. This mode also requires
1203              a  olcServerID  (see  above) to be configured.  By default, this
1204              setting is FALSE.
1205
1206       olcMonitoring: TRUE | FALSE
1207              This option enables database-specific monitoring  in  the  entry
1208              related to the current database in the "cn=Databases,cn=Monitor"
1209              subtree of the monitor database,  if  the  monitor  database  is
1210              enabled.   Currently,  only  the MDB database provides database-
1211              specific monitoring.  If monitoring is supported by the  backend
1212              it defaults to TRUE, otherwise FALSE.
1213
1214       olcPlugin: <plugin_type> <lib_path> <init_function> [<arguments>]
1215              Configure  a  SLAPI  plugin. See the slapd.plugin(5) manpage for
1216              more details.
1217
1218       olcRootDN: <dn>
1219              Specify the distinguished name that is  not  subject  to  access
1220              control  or  administrative limit restrictions for operations on
1221              this database.  This DN may or may not  be  associated  with  an
1222              entry.   An empty root DN (the default) specifies no root access
1223              is to be granted.  It is recommended that  the  rootdn  only  be
1224              specified  when  needed  (such  as  when  initially populating a
1225              database).  If the rootdn is within a namingContext (suffix)  of
1226              the  database, a simple bind password may also be provided using
1227              the  olcRootPW  directive.  Many  optional  features,  including
1228              syncrepl,  require  the  rootdn  to be defined for the database.
1229              The olcRootDN of the cn=config database  defaults  to  cn=config
1230              itself.
1231
1232       olcRootPW: <password>
1233              Specify  a  password  (or  hash of the password) for the rootdn.
1234              The password can only  be  set  if  the  rootdn  is  within  the
1235              namingContext (suffix) of the database.  This option accepts all
1236              RFC  2307  userPassword  formats  known  to  the   server   (see
1237              olcPasswordHash    description)    as    well    as   cleartext.
1238              slappasswd(8) may be used to generate  a  hash  of  a  password.
1239              Cleartext  and  {CRYPT} passwords are not recommended.  If empty
1240              (the default), authentication of the root DN is by  other  means
1241              (e.g. SASL).  Use of SASL is encouraged.
1242
1243       olcSubordinate: [TRUE | FALSE | advertise]
1244              Specify  that  the  current backend database is a subordinate of
1245              another backend database. A subordinate  database may have  only
1246              one  suffix.  This option may be used to glue multiple databases
1247              into a single namingContext.   If  the  suffix  of  the  current
1248              database  is  within  the  namingContext of a superior database,
1249              searches against the superior database will be propagated to the
1250              subordinate  as  well.  All  of  the databases associated with a
1251              single namingContext should have identical rootdns.  Behavior of
1252              other   LDAP  operations  is  unaffected  by  this  setting.  In
1253              particular, it is not possible to use moddn  to  move  an  entry
1254              from   one   subordinate   to  another  subordinate  within  the
1255              namingContext.
1256
1257              If the optional advertise flag is supplied, the  naming  context
1258              of  this  database is advertised in the root DSE. The default is
1259              to hide this database context, so that only the superior context
1260              is visible.
1261
1262              If  the  slap  tools  slapcat(8),  slapadd(8), slapmodify(8), or
1263              slapindex(8) are  used  on  the  superior  database,  any  glued
1264              subordinates that support these tools are opened as well.
1265
1266              Databases  that  are glued together should usually be configured
1267              with the same indices (assuming they support indexing), even for
1268              attributes  that  only  exist  in  some  of  these databases. In
1269              general, all of the glued  databases  should  be  configured  as
1270              similarly  as  possible,  since  the  intent  is  to provide the
1271              appearance of a single directory.
1272
1273              Note  that  the   subordinate   functionality   is   implemented
1274              internally  by  the  glue  overlay and as such its behavior will
1275              interact with other  overlays  in  use.  By  default,  the  glue
1276              overlay  is  automatically configured as the last overlay on the
1277              superior  database.  Its  position  on  the  database   can   be
1278              explicitly  configured  by  setting an overlay glue directive at
1279              the desired position. This explicit configuration  is  necessary
1280              e.g.   when  using  the  syncprov overlay, which needs to follow
1281              glue in order to work over all of the glued databases. E.g.
1282                   dn: olcDatabase={1}mdb,cn=config
1283                   olcSuffix: dc=example,dc=com
1284                   ...
1285
1286                   dn: olcOverlay={0}glue,olcDatabase={1}mdb,cn=config
1287                   ...
1288
1289                   dn: olcOverlay={1}syncprov,olcDatabase={1}mdb,cn=config
1290                   ...
1291       See the Overlays section below for more details.
1292
1293       olcSuffix: <dn suffix>
1294              Specify the DN suffix of queries that will  be  passed  to  this
1295              backend  database.   Multiple  suffix  lines can be given and at
1296              least one is required for each database definition.
1297
1298              If the suffix of one database is "inside" that of  another,  the
1299              database   with   the  inner  suffix  must  come  first  in  the
1300              configuration file.  You may also want to  glue  such  databases
1301              together with the olcSubordinate attribute.
1302
1303       olcSyncUseSubentry: TRUE | FALSE
1304              Store  the  syncrepl  contextCSN  in  a  subentry instead of the
1305              context entry of  the  database.  The  subentry's  RDN  will  be
1306              "cn=ldapsync".  The  default is FALSE, meaning the contextCSN is
1307              stored in the context entry.
1308
1309       olcSyncrepl:  rid=<replica   ID>   provider=ldap[s]://<hostname>[:port]
1310              searchbase=<base     DN>    [type=refreshOnly|refreshAndPersist]
1311              [interval=dd:hh:mm:ss]   [retry=[<retry    interval>    <#    of
1312              retries>]+]  [filter=<filter  str>]  [scope=sub|one|base|subord]
1313              [attrs=<attr   list>]    [exattrs=<attr    list>]    [attrsonly]
1314              [sizelimit=<limit>]  [timelimit=<limit>] [schemachecking=on|off]
1315              [network-timeout=<seconds>]                  [timeout=<seconds>]
1316              [tcp-user-timeout=<milliseconds>]       [bindmethod=simple|sasl]
1317              [binddn=<dn>]       [saslmech=<mech>]       [authcid=<identity>]
1318              [authzid=<identity>]    [credentials=<passwd>]   [realm=<realm>]
1319              [secprops=<properties>]   [keepalive=<idle>:<probes>:<interval>]
1320              [starttls=yes|critical]    [tls_cert=<file>]    [tls_key=<file>]
1321              [tls_cacert=<file>]                       [tls_cacertdir=<path>]
1322              [tls_reqcert=never|allow|try|demand]
1323              [tls_reqsan=never|allow|try|demand] [tls_cipher_suite=<ciphers>]
1324              [tls_ecname=<names>]                [tls_crlcheck=none|peer|all]
1325              [tls_protocol_min=<major>[.<minor>]]  [suffixmassage=<real  DN>]
1326              [logbase=<base        DN>]        [logfilter=<filter       str>]
1327              [syncdata=default|accesslog|changelog] [lazycommit]
1328              Specify the current database as a consumer which is kept  up-to-
1329              date  with  the  provider  content  by  establishing the current
1330              slapd(8) as a  replication  consumer  site  running  a  syncrepl
1331              replication  engine.   The consumer content is kept synchronized
1332              to the provider content using the LDAP  Content  Synchronization
1333              protocol.  Refer  to  the  "OpenLDAP  Administrator's Guide" for
1334              detailed information on setting up a replicated slapd  directory
1335              service using the syncrepl replication engine.
1336
1337              rid   identifies  the  current  syncrepl  directive  within  the
1338              replication consumer site.  It is  a  non-negative  integer  not
1339              greater than 999 (limited to three decimal digits).
1340
1341              provider  specifies the replication provider site containing the
1342              provider content as an LDAP URI. If <port>  is  not  given,  the
1343              standard LDAP port number (389 or 636) is used.
1344
1345              The  content  of the syncrepl consumer is defined using a search
1346              specification as its result set. The consumer  slapd  will  send
1347              search  requests  to  the provider slapd according to the search
1348              specification. The  search  specification  includes  searchbase,
1349              scope,   filter,  attrs,  attrsonly,  sizelimit,  and  timelimit
1350              parameters as in the normal search  specification.  The  exattrs
1351              option  may  also  be  used to specify attributes that should be
1352              omitted from incoming entries.  The scope defaults to  sub,  the
1353              filter  defaults  to  (objectclass=*),  and  there is no default
1354              searchbase. The attrs list defaults to "*,+" to return all  user
1355              and  operational attributes, and attrsonly and exattrs are unset
1356              by default.  The sizelimit and timelimit only accept "unlimited"
1357              and  positive  integers,  and  both default to "unlimited".  The
1358              sizelimit and timelimit parameters define a  consumer  requested
1359              limitation  on the number of entries that can be returned by the
1360              LDAP Content Synchronization operation;  these  should  be  left
1361              unchanged  from  the  default  otherwise  replication  may never
1362              succeed.  Note, however, that any provider-side limits  for  the
1363              replication identity will be enforced by the provider regardless
1364              of the limits requested  by  the  LDAP  Content  Synchronization
1365              operation, much like for any other search operation.
1366
1367              The  LDAP  Content  Synchronization  protocol  has two operation
1368              types.  In the refreshOnly operation, the  next  synchronization
1369              search operation is periodically rescheduled at an interval time
1370              (specified by interval parameter; 1 day by default)  after  each
1371              synchronization  operation  finishes.   In the refreshAndPersist
1372              operation, a synchronization search remains  persistent  in  the
1373              provider  slapd.   Further updates to the provider will generate
1374              searchResultEntry to the consumer slapd as the search  responses
1375              to  the persistent synchronization search. If the initial search
1376              fails due to an error, the next synchronization search operation
1377              is  periodically  rescheduled  at an interval time (specified by
1378              interval parameter; 1 day by default)
1379
1380              If an error occurs during replication, the consumer will attempt
1381              to reconnect according to the retry parameter which is a list of
1382              the <retry interval> and <# of  retries>  pairs.   For  example,
1383              retry="60 10 300 3" lets the consumer retry every 60 seconds for
1384              the first 10 times and then retry every 300 seconds for the next
1385              3  times  before  stop retrying. The `+' in <# of retries> means
1386              indefinite number of retries until  success.   If  no  retry  is
1387              specified, by default syncrepl retries every hour forever.
1388
1389              The  schema  checking  can be enforced at the LDAP Sync consumer
1390              site by turning on the schemachecking parameter. The default  is
1391              off.  Schema checking on means that replicated entries must have
1392              a structural objectClass, must obey to objectClass  requirements
1393              in   terms  of  required/allowed  attributes,  and  that  naming
1394              attributes and distinguished  values  must  be  present.   As  a
1395              consequence,   schema   checking  should  be  off  when  partial
1396              replication is used.
1397
1398              The network-timeout parameter sets how long  the  consumer  will
1399              wait  to  establish a network connection to the provider. Once a
1400              connection is established, the timeout parameter determines  how
1401              long  the  consumer  will  wait  for the initial Bind request to
1402              complete.  The  defaults  for   these   parameters   come   from
1403              ldap.conf(5).   The  tcp-user-timeout  parameter,  if  non-zero,
1404              corresponds  to  the  TCP_USER_TIMEOUT   set   on   the   target
1405              connections, overriding the operating system setting.  Only some
1406              systems support the  customization  of  this  parameter,  it  is
1407              ignored otherwise and system-wide settings are used.
1408
1409              A   bindmethod   of  simple  requires  the  options  binddn  and
1410              credentials and should  only  be  used  when  adequate  security
1411              services  (e.g.  TLS  or  IPSEC) are in place.  REMEMBER: simple
1412              bind credentials must be in cleartext!   A  bindmethod  of  sasl
1413              requires  the  option  saslmech.  Depending on the mechanism, an
1414              authentication identity  and/or  credentials  can  be  specified
1415              using  authcid  and  credentials.   The authzid parameter may be
1416              used to specify an authorization  identity.   Specific  security
1417              properties  (as with the sasl-secprops keyword above) for a SASL
1418              bind can be set with the secprops option.  A  non  default  SASL
1419              realm  can  be set with the realm option.  The identity used for
1420              synchronization by the consumer should be allowed to receive  an
1421              unlimited  number  of  entries  in response to a search request.
1422              The provider, other than allowing authentication of the syncrepl
1423              identity,   should   grant   that  identity  appropriate  access
1424              privileges  to  the  data  that  is  being  replicated   (access
1425              directive),  and  appropriate time and size limits.  This can be
1426              accomplished  by  either  allowing   unlimited   sizelimit   and
1427              timelimit,  or by setting an appropriate limits statement in the
1428              consumer's configuration (see sizelimit and limits for details).
1429
1430              The keepalive parameter sets the values  of  idle,  probes,  and
1431              interval  used  to  check whether a socket is alive; idle is the
1432              number of seconds a connection needs to remain idle  before  TCP
1433              starts sending keepalive probes; probes is the maximum number of
1434              keepalive probes TCP should send before dropping the connection;
1435              interval  is  interval  in  seconds between individual keepalive
1436              probes.  Only some systems support the  customization  of  these
1437              values;  the  keepalive  parameter  is  ignored  otherwise,  and
1438              system-wide settings are used.
1439
1440              The starttls parameter specifies use of  the  StartTLS  extended
1441              operation  to  establish  a  TLS  session  before Binding to the
1442              provider. If the critical argument is supplied, the session will
1443              be aborted if the StartTLS request fails. Otherwise the syncrepl
1444              session continues without TLS. The tls_reqcert setting  defaults
1445              to "demand", the tls_reqsan setting defaults to "allow", and the
1446              other TLS settings default to the same as  the  main  slapd  TLS
1447              settings.
1448
1449              The  suffixmassage parameter allows the consumer to pull entries
1450              from a remote directory whose DN suffix differs from  the  local
1451              directory.  The  portion of the remote entries' DNs that matches
1452              the searchbase will be replaced with the suffixmassage DN.
1453
1454              Rather than replicating whole entries, the  consumer  can  query
1455              logs  of  data modifications. This mode of operation is referred
1456              to as delta syncrepl. In addition to the above  parameters,  the
1457              logbase  and  logfilter parameters must be set appropriately for
1458              the log that will be used. The syncdata parameter must be set to
1459              either "accesslog" if the log conforms to the slapo-accesslog(5)
1460              log format, or "changelog" if the log conforms to  the  obsolete
1461              changelog format. If the syncdata parameter is omitted or set to
1462              "default" then the log parameters are ignored.
1463
1464              The lazycommit parameter tells the underlying database  that  it
1465              can  store  changes  without  performing a full flush after each
1466              change. This may improve performance  for  the  consumer,  while
1467              sacrificing safety or durability.
1468
1469       olcUpdateDN: <dn>
1470              This  option  is  only  applicable  in  a  replica database.  It
1471              specifies  the  DN  permitted  to  update  (subject  to   access
1472              controls)  the  replica.  It is only needed in certain push-mode
1473              replication scenarios.  Generally, this DN  should  not  be  the
1474              same as the rootdn used at the provider.
1475
1476       olcUpdateRef: <url>
1477              Specify  the  referral  to  pass  back when slapd(8) is asked to
1478              modify a replicated local  database.   If  multiple  values  are
1479              specified, each url is provided.
1480
1481

DATABASE-SPECIFIC OPTIONS

1483       Each  database  may  allow  specific  configuration  options;  they are
1484       documented  separately  in  the  backends'  manual   pages.   See   the
1485       slapd.backends(5) manual page for an overview of available backends.
1486

OVERLAYS

1488       An  overlay  is  a piece of code that intercepts database operations in
1489       order to extend or change them. Overlays are pushed onto a  stack  over
1490       the  database,  and so they will execute in the reverse of the order in
1491       which they were configured and the database itself will receive control
1492       last of all.
1493
1494       Overlays  must  be  configured as child entries of a specific database.
1495       The entry's RDN must be of the form olcOverlay={x}<overlaytype> and the
1496       entry  must  have the olcOverlayConfig objectClass. Normally the config
1497       engine generates the "{x}" index in the RDN automatically, so it can be
1498       omitted when initially loading these entries.
1499
1500       See  the  slapd.overlays(5)  manual  page  for an overview of available
1501       overlays.
1502

EXAMPLES

1504       Here is a short example of a configuration in  LDIF  suitable  for  use
1505       with slapadd(8) :
1506
1507              dn: cn=config
1508              objectClass: olcGlobal
1509              cn: config
1510              olcPidFile: /var/run/slapd.pid
1511              olcAttributeOptions: x-hidden lang-
1512
1513              dn: cn=schema,cn=config
1514              objectClass: olcSchemaConfig
1515              cn: schema
1516
1517              include: file:///etc/openldap/schema/core.ldif
1518
1519              dn: olcDatabase=frontend,cn=config
1520              objectClass: olcDatabaseConfig
1521              objectClass: olcFrontendConfig
1522              olcDatabase: frontend
1523              # Subtypes of "name" (e.g. "cn" and "ou") with the
1524              # option ";x-hidden" can be searched for/compared,
1525              # but are not shown.  See slapd.access(5).
1526              olcAccess: to attrs=name;x-hidden by * =cs
1527              # Protect passwords.  See slapd.access(5).
1528              olcAccess: to attrs=userPassword  by * auth
1529              # Read access to other attributes and entries.
1530              olcAccess: to * by * read
1531
1532              # set a rootpw for the config database so we can bind.
1533              # deny access to everyone else.
1534              dn: olcDatabase=config,cn=config
1535              objectClass: olcDatabaseConfig
1536              olcDatabase: config
1537              olcRootPW: {SSHA}XKYnrjvGT3wZFQrDD5040US592LxsdLy
1538              olcAccess: to * by * none
1539
1540              dn: olcDatabase=mdb,cn=config
1541              objectClass: olcDatabaseConfig
1542              objectClass: olcMdbConfig
1543              olcDatabase: mdb
1544              olcSuffix: "dc=our-domain,dc=com"
1545              # The database directory MUST exist prior to
1546              # running slapd AND should only be accessible
1547              # by the slapd/tools. Mode 0700 recommended.
1548              olcDbDirectory: /var/openldap-data
1549              # Indices to maintain
1550              olcDbIndex:     objectClass  eq
1551              olcDbIndex:     cn,sn,mail   pres,eq,approx,sub
1552
1553              # We serve small clients that do not handle referrals,
1554              # so handle remote lookups on their behalf.
1555              dn: olcDatabase=ldap,cn=config
1556              objectClass: olcDatabaseConfig
1557              objectClass: olcLdapConfig
1558              olcDatabase: ldap
1559              olcSuffix: ""
1560              olcDbUri: ldap://ldap.some-server.com/
1561
1562       Assuming the above data was saved in a file named "config.ldif" and the
1563       /etc/openldap/slapd.d directory has been  created,  this  command  will
1564       initialize the configuration:
1565              slapadd -F /etc/openldap/slapd.d -n 0 -l config.ldif
1566
1567
1568       "OpenLDAP Administrator's Guide" contains a longer annotated example of
1569       a slapd configuration.
1570
1571       Alternatively, an existing slapd.conf file can be converted to the  new
1572       format using slapd or any of the slap tools:
1573              slaptest -f /etc/openldap/slapd.conf -F /etc/openldap/slapd.d
1574
1575

FILES

1577       /etc/openldap/slapd.conf
1578              default slapd configuration file
1579
1580       /etc/openldap/slapd.d
1581              default slapd configuration directory
1582

SEE ALSO

1584       ldap(3),  ldif(5),  gnutls-cli(1),  slapd.access(5), slapd.backends(5),
1585       slapd.conf(5),    slapd.overlays(5),     slapd.plugin(5),     slapd(8),
1586       slapacl(8),    slapadd(8),    slapauth(8),    slapcat(8),    slapdn(8),
1587       slapindex(8), slapmodify(8), slappasswd(8), slaptest(8).
1588
1589       "OpenLDAP Administrator's Guide" (http://www.OpenLDAP.org/doc/admin/)
1590

ACKNOWLEDGEMENTS

1592       OpenLDAP Software is developed and maintained by The  OpenLDAP  Project
1593       <http://www.openldap.org/>.   OpenLDAP  Software  is  derived  from the
1594       University of Michigan LDAP 3.3 Release.
1595
1596
1597
1598OpenLDAP 2.6.2                    2022/05/04                   SLAPD-CONFIG(5)
Impressum