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), 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 there are no backends that implement settings of  this  nature,
58       so usually there will not be any olcBackend entries.
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.   The
183              second  form  is  a DN, with the optional style modifiers exact,
184              onelevel, children, and subtree for  exact,  onelevel,  children
185              and  subtree matches, which cause <pattern> to be normalized ac‐
186              cording to the DN normalization  rules,  or  the  special  regex
187              style,  which  causes  the  <pattern>  to  be treated as a POSIX
188              (''extended'') regular  expression,  as  discussed  in  regex(7)
189              and/or re_format(7).  A pattern of * means any non-anonymous DN.
190              The third form is a SASL id, with the optional fields <mech> and
191              <realm> that allow to specify a SASL mechanism, and eventually a
192              SASL realm, for those mechanisms that support one.  The need  to
193              allow  the  specification  of  a mechanism is still debated, and
194              users are strongly discouraged to rely on this possibility.  The
195              fourth  form is a group specification, consisting of the keyword
196              group, optionally followed by the specification of the group ob‐
197              jectClass and member attributeType.  The group with DN <pattern>
198              is searched with base scope, and in case of match, the values of
199              the  member attributeType are searched for the asserted DN.  For
200              backwards compatibility, if no identity type is  provided,  i.e.
201              only  <pattern>  is present, an exact DN is assumed; as a conse‐
202              quence, <pattern> is subjected to DN normalization.   Since  the
203              interpretation  of  authzFrom  and  authzTo can impact security,
204              users are strongly encouraged to  explicitly  set  the  type  of
205              identity  specification  that  is being used.  A subset of these
206              rules can be used as third arg in the  olcAuthzRegexp  statement
207              (see below); significantly, the URI and the dn.exact:<dn> forms.
208
209       olcAuthzRegexp: <match> <replace>
210              Used  by  the  authentication  framework  to convert simple user
211              names, such as provided by SASL subsystem, to an  LDAP  DN  used
212              for authorization purposes.  Note that the resultant DN need not
213              refer to an existing entry to be considered valid.  When an  au‐
214              thorization  request  is  received  from the SASL subsystem, the
215              SASL USERNAME, REALM, and MECHANISM are taken,  when  available,
216              and combined into a name of the form
217
218                     UID=<username>[[,CN=<realm>],CN=<mechanism>],CN=auth
219
220              This  name  is  then  compared  against  the  match POSIX (''ex‐
221              tended'') regular expression, and if the  match  is  successful,
222              the  name  is  replaced  with  the replace string.  If there are
223              wildcard strings in the match regular expression  that  are  en‐
224              closed in parenthesis, e.g.
225
226                     UID=([^,]*),CN=.*
227
228              then  the  portion of the name that matched the wildcard will be
229              stored in the numbered placeholder variable  $1.  If  there  are
230              other wildcard strings in parenthesis, the matching strings will
231              be in $2, $3, etc. up to $9. The placeholders can then  be  used
232              in the replace string, e.g.
233
234                     UID=$1,OU=Accounts,DC=example,DC=com
235
236              The  replaced name can be either a DN, i.e. a string prefixed by
237              "dn:", or an LDAP URI.  If the latter, the server will  use  the
238              URI to search its own database(s) and, if the search returns ex‐
239              actly one entry, the name is replaced by the DN of  that  entry.
240              The  LDAP URI must have no hostport, attrs, or extensions compo‐
241              nents, but the filter is mandatory, e.g.
242
243                     ldap:///OU=Accounts,DC=example,DC=com??one?(UID=$1)
244
245              The protocol portion of the URI must  be  strictly  ldap.   Note
246              that  this  search is subject to access controls.  Specifically,
247              the authentication identity must have "auth" access in the  sub‐
248              ject.
249
250              Multiple  olcAuthzRegexp  values  can  be specified to allow for
251              multiple matching and replacement patterns.  The  matching  pat‐
252              terns  are  checked  in  the order they appear in the attribute,
253              stopping at the first successful match.
254
255
256       olcConcurrency: <integer>
257              Specify a desired level of concurrency.  Provided to the  under‐
258              lying  thread  system  as a hint.  The default is not to provide
259              any hint. This setting is  only  meaningful  on  some  platforms
260              where  there  is  not  a  one to one correspondence between user
261              threads and kernel threads.
262
263       olcConnMaxPending: <integer>
264              Specify the maximum number of pending requests for an  anonymous
265              session.   If  requests are submitted faster than the server can
266              process them, they will be queued up to this limit. If the limit
267              is exceeded, the session is closed. The default is 100.
268
269       olcConnMaxPendingAuth: <integer>
270              Specify  the maximum number of pending requests for an authenti‐
271              cated session.  The default is 1000.
272
273       olcDisallows: <features>
274              Specify a set of features to disallow (default none).  bind_anon
275              disables  acceptance of anonymous bind requests.  Note that this
276              setting does not prohibit anonymous directory access  (See  "re‐
277              quire  authc").   bind_simple disables simple (bind) authentica‐
278              tion.  tls_2_anon disables forcing session to  anonymous  status
279              (see also tls_authc) upon StartTLS operation receipt.  tls_authc
280              disallows the StartTLS  operation  if  authenticated  (see  also
281              tls_2_anon).
282
283       olcGentleHUP: { TRUE | FALSE }
284              A  SIGHUP  signal  will  only cause a 'gentle' shutdown-attempt:
285              Slapd will stop listening for  new  connections,  but  will  not
286              close  the connections to the current clients.  Future write op‐
287              erations return unwilling-to-perform, though.  Slapd  terminates
288              when  all  clients  have  closed their connections (if they ever
289              do), or - as before - if it receives a SIGTERM signal.  This can
290              be  useful  if  you wish to terminate the server and start a new
291              slapd server with another database, without disrupting the  cur‐
292              rently  active  clients.  The default is FALSE.  You may wish to
293              use olcIdleTimeout along with this option.
294
295       olcIdleTimeout: <integer>
296              Specify the number of seconds to wait before forcibly closing an
297              idle  client  connection.  A setting of 0 disables this feature.
298              The default is 0. You may also want to set  the  olcWriteTimeout
299              option.
300
301       olcIndexIntLen: <integer>
302              Specify  the  key  length  for ordered integer indices. The most
303              significant bytes of the binary integer will be used  for  index
304              keys.  The default value is 4, which provides exact indexing for
305              31 bit values.  A floating point representation is used to index
306              too large values.
307
308       olcIndexSubstrIfMaxlen: <integer>
309              Specify  the maximum length for subinitial and subfinal indices.
310              Only this many characters of an attribute  value  will  be  pro‐
311              cessed  by the indexing functions; any excess characters are ig‐
312              nored. The default is 4.
313
314       olcIndexSubstrIfMinlen: <integer>
315              Specify the minimum length for subinitial and subfinal  indices.
316              An  attribute  value  must have at least this many characters in
317              order to be processed by the indexing functions. The default  is
318              2.
319
320       olcIndexSubstrAnyLen: <integer>
321              Specify  the  length used for subany indices. An attribute value
322              must have at least this many characters  in  order  to  be  pro‐
323              cessed.  Attribute  values  longer than this length will be pro‐
324              cessed in segments of this length. The default is 4. The  subany
325              index will also be used in subinitial and subfinal index lookups
326              when the filter string is longer than the olcIndexSubstrIfMaxlen
327              value.
328
329       olcIndexSubstrAnyStep: <integer>
330              Specify  the steps used in subany index lookups. This value sets
331              the offset for the segments of a filter  string  that  are  pro‐
332              cessed for a subany index lookup. The default is 2. For example,
333              with the default values, a search using this filter  "cn=*abcde‐
334              fgh*"  would  generate  index  lookups  for  "abcd", "cdef", and
335              "efgh".
336
337
338       Note: Indexing support depends on the particular backend in use.  Also,
339       changing  these  settings  will  generally require deleting any indices
340       that depend on these parameters and recreating them with slapindex(8).
341
342
343       olcListenerThreads: <integer>
344              Specify the number of threads to use for the connection manager.
345              The default is 1 and this is typically adequate for up to 16 CPU
346              cores.  The value should be set to a power of 2.
347
348       olcLocalSSF: <SSF>
349              Specifies the Security Strength Factor (SSF) to be  given  local
350              LDAP  sessions,  such  as those to the ldapi:// listener.  For a
351              description of SSF values, see olcSaslSecProps's  minssf  option
352              description.  The default is 71.
353
354       olcLogFile: <filename>
355              Specify  a  file  for  recording  debug log messages. By default
356              these messages only go to stderr and are not  recorded  anywhere
357              else.  Specifying  a  logfile copies messages to both stderr and
358              the logfile.
359
360       olcLogLevel: <integer> [...]
361              Specify the level at which debugging  statements  and  operation
362              statistics  should  be  syslogged  (currently logged to the sys‐
363              logd(8) LOG_LOCAL4 facility).  They must be  considered  subsys‐
364              tems rather than increasingly verbose log levels.  Some messages
365              with higher priority are logged  regardless  of  the  configured
366              loglevel  as  soon as any logging is configured.  Log levels are
367              additive, and available levels are:
368                     1      (0x1 trace) trace function calls
369                     2      (0x2 packets) debug packet handling
370                     4      (0x4 args) heavy trace debugging (function args)
371                     8      (0x8 conns) connection management
372                     16     (0x10 BER) print out packets sent and received
373                     32     (0x20 filter) search filter processing
374                     64     (0x40 config) configuration file processing
375                     128    (0x80 ACL) access control list processing
376                     256    (0x100 stats) stats log connections/operations/re‐
377                            sults
378                     512    (0x200 stats2) stats log entries sent
379                     1024   (0x400 shell) print communication with shell back‐
380                            ends
381                     2048   (0x800 parse) entry parsing
382
383
384
385
386
387
388
389
390                     16384  (0x4000 sync) LDAPSync replication
391                     32768  (0x8000 none) only messages that get logged  what‐
392                            ever log level is set
393              The desired log level can be input as a single integer that com‐
394              bines the (ORed) desired levels, both in decimal or in hexadeci‐
395              mal  notation, as a list of integers (that are ORed internally),
396              or as a list of the names that are  shown  between  parenthesis,
397              such that
398
399                  olcLogLevel: 129
400                  olcLogLevel: 0x81
401                  olcLogLevel: 128 1
402                  olcLogLevel: 0x80 0x1
403                  olcLogLevel: acl trace
404
405              are  equivalent.   The  keyword any can be used as a shortcut to
406              enable logging at all levels (equivalent to  -1).   The  keyword
407              none,  or  the  equivalent  integer representation, causes those
408              messages that  are  logged  regardless  of  the  configured  ol‐
409              cLogLevel  to  be  logged.   In  fact, if no olcLogLevel (or a 0
410              level) is defined, no logging occurs, so at least the none level
411              is required to have high priority messages logged.
412
413       olcPasswordCryptSaltFormat: <format>
414              Specify  the format of the salt passed to crypt(3) when generat‐
415              ing {CRYPT} passwords (see olcPasswordHash) during processing of
416              LDAP Password Modify Extended Operations (RFC 3062).
417
418              This string needs to be in sprintf(3) format and may include one
419              (and only one) %s conversion.  This conversion will  be  substi‐
420              tuted  with  a  string  of random characters from [A-Za-z0-9./].
421              For example, "%.2s" provides a two character salt and  "$1$%.8s"
422              tells some versions of crypt(3) to use an MD5 algorithm and pro‐
423              vides 8 random characters of salt.  The default is  "%s",  which
424              provides 31 characters of salt.
425
426       olcPidFile: <filename>
427              The  (absolute) name of a file that will hold the slapd server's
428              process ID (see getpid(2)).
429
430       olcPluginLogFile: <filename>
431              The ( absolute ) name of a file that will contain  log  messages
432              from SLAPI plugins. See slapd.plugin(5) for details.
433
434       olcReferral: <url>
435              Specify  the  referral  to pass back when slapd(8) cannot find a
436              local database to handle a  request.   If  multiple  values  are
437              specified, each url is provided.
438
439       olcReverseLookup: TRUE | FALSE
440              Enable/disable client name unverified reverse lookup (default is
441              FALSE if compiled with --enable-rlookups).
442
443       olcRootDSE: <file>
444              Specify the name of an LDIF(5) file containing user defined  at‐
445              tributes for the root DSE.  These attributes are returned in ad‐
446              dition to the attributes normally produced by slapd.
447
448              The root DSE is an entry with information about the  server  and
449              its  capabilities,  in operational attributes.  It has the empty
450              DN, and can be read with e.g.:
451                  ldapsearch -x -b "" -s base "+"
452              See RFC 4512 section 5.1 for details.
453
454       olcSaslAuxprops: <plugin> [...]
455              Specify which auxprop plugins to use for authentication lookups.
456              The  default is empty, which just uses slapd's internal support.
457              Usually no other auxprop plugins are needed.
458
459       olcSaslHost: <fqdn>
460              Used to specify the fully qualified domain name  used  for  SASL
461              processing.
462
463       olcSaslRealm: <realm>
464              Specify SASL realm.  Default is empty.
465
466       olcSaslCbinding: none | tls-unique | tls-endpoint
467              Specify      the      channel-binding     type,     see     also
468              LDAP_OPT_X_SASL_CBINDING.  Default is none.
469
470       olcSaslSecProps: <properties>
471              Used to specify Cyrus SASL security properties.  The  none  flag
472              (without  any  other  properties) causes the flag properties de‐
473              fault, "noanonymous,noplain", to be cleared.  The  noplain  flag
474              disables  mechanisms susceptible to simple passive attacks.  The
475              noactive flag disables mechanisms susceptible to active attacks.
476              The  nodict flag disables mechanisms susceptible to passive dic‐
477              tionary attacks.  The noanonymous flag disables mechanisms which
478              support  anonymous  login.   The forwardsec flag require forward
479              secrecy between sessions.  The passcred require mechanisms which
480              pass  client  credentials  (and  allow mechanisms which can pass
481              credentials to do so).  The minssf=<factor>  property  specifies
482              the  minimum  acceptable  security strength factor as an integer
483              approximate to effective key  length  used  for  encryption.   0
484              (zero)  implies  no  protection,  1 implies integrity protection
485              only, 56 allows DES or other weak ciphers, 112 allows triple DES
486              and  other  strong  ciphers,  128 allows RC4, Blowfish and other
487              modern strong ciphers.  The default is 0.   The  maxssf=<factor>
488              property specifies the maximum acceptable security strength fac‐
489              tor as an integer (see  minssf  description).   The  default  is
490              INT_MAX.   The  maxbufsize=<size> property specifies the maximum
491              security layer receive buffer size allowed.  0 disables security
492              layers.  The default is 65536.
493
494       olcServerID: <integer> [<URL>]
495              Specify an integer ID from 0 to 4095 for this server (limited to
496              3 hexadecimal digits).  The ID may also be specified as a  hexa‐
497              decimal  ID  by prefixing the value with "0x".  Non-zero IDs are
498              required when using multi-provider replication and each provider
499              must  have a unique non-zero ID. Note that this requirement also
500              applies to separate providers contributing to  a  glued  set  of
501              databases.  If the URL is provided, this directive may be speci‐
502              fied multiple times, providing a complete list of  participating
503              servers  and  their  IDs.  The  fully qualified hostname of each
504              server should be used in the supplied URLs. The IDs are used  in
505              the  "replica  id"  field of all CSNs generated by the specified
506              server. The default value is zero, which is only valid for  sin‐
507              gle provider replication.  Example:
508
509            olcServerID: 1 ldap://ldap1.example.com
510            olcServerID: 2 ldap://ldap2.example.com
511
512       olcSockbufMaxIncoming: <integer>
513              Specify  the  maximum  incoming LDAP PDU size for anonymous ses‐
514              sions.  The default is 262143.
515
516       olcSockbufMaxIncomingAuth: <integer>
517              Specify the maximum incoming LDAP  PDU  size  for  authenticated
518              sessions.  The default is 4194303.
519
520       olcTCPBuffer [listener=<URL>] [{read|write}=]<size>
521              Specify  the  size  of  the TCP buffer.  A global value for both
522              read and write TCP buffers related to any listener  is  defined,
523              unless  the listener is explicitly specified, or either the read
524              or write qualifiers are used.  See  tcp(7)  for  details.   Note
525              that some OS-es implement automatic TCP buffer tuning.
526
527       olcThreads: <integer>
528              Specify  the  maximum  size of the primary thread pool.  The de‐
529              fault is 16; the minimum value is 2.
530
531       olcToolThreads: <integer>
532              Specify the maximum number of threads to use in tool mode.  This
533              should  not  be  greater  than the number of CPUs in the system.
534              The default is 1.
535
536       olcWriteTimeout: <integer>
537              Specify the number of seconds to wait before forcibly closing  a
538              connection with an outstanding write.  This allows recovery from
539              various network hang conditions.  A setting of 0  disables  this
540              feature.  The default is 0.
541

TLS OPTIONS

543       If  slapd is built with support for Transport Layer Security, there are
544       more options you can specify.
545
546       When using OpenSSL, if neither  olcTLSCACertificateFile nor  olcTLSCAC‐
547       ertificatePath  is  set, the system-wide default set of CA certificates
548       is used.
549
550       olcTLSCipherSuite: <cipher-suite-spec>
551              Permits configuring what ciphers will be accepted and the  pref‐
552              erence order.  <cipher-suite-spec> should be a cipher specifica‐
553              tion for the TLS library in use  (OpenSSL,  GnuTLS,  or  Mozilla
554              NSS).  Example:
555
556                     OpenSSL:
557                            olcTLSCipherSuite: HIGH:MEDIUM:+SSLv2
558
559                     GnuTLS:
560                            olcTLSCiphersuite: SECURE256:!AES-128-CBC
561
562              To check what ciphers a given spec selects in OpenSSL, use:
563
564                   openssl ciphers -v <cipher-suite-spec>
565
566              With  GnuTLS the available specs can be found in the manual page
567              of gnutls-cli(1) (see the description of the option --priority).
568
569              In older versions of GnuTLS, where gnutls-cli does  not  support
570              the  option --priority, you can obtain the — more limited — list
571              of ciphers by calling:
572
573                   gnutls-cli -l
574
575              When using Mozilla NSS, the OpenSSL cipher suite  specifications
576              are  used  and  translated  into  the  format used internally by
577              Mozilla NSS.  There isn't an easy way to list the cipher  suites
578              from  the command line.  The authoritative list is in the source
579              code for Mozilla NSS in the file sslinfo.c in the structure
580                      static const SSLCipherSuiteInfo suiteInfo[]
581
582       olcTLSCACertificateFile: <filename>
583              Specifies the file that contains certificates  for  all  of  the
584              Certificate Authorities that slapd will recognize.
585
586       olcTLSCACertificatePath: <path>
587              Specifies  the path of a directory that contains Certificate Au‐
588              thority certificates in separate individual files. Usually  only
589              one  of  this or the olcTLSCACertificateFile is defined. If both
590              are specified, both locations will be used.  This  directive  is
591              not supported when using GnuTLS.
592
593              When  using  Mozilla  NSS,  <path>  may  contain  a  Mozilla NSS
594              cert/key database.  If <path> contains a  Mozilla  NSS  cert/key
595              database and CA cert files, OpenLDAP will use the cert/key data‐
596              base and will ignore the CA cert files.
597
598       olcTLSCertificateFile: <filename>
599              Specifies the file that contains the slapd server certificate.
600
601              When using Mozilla NSS, if using a cert/key database  (specified
602              with  olcTLSCACertificatePath),  olcTLSCertificateFile specifies
603              the name of the certificate to use:
604                   olcTLSCertificateFile: Server-Cert
605              If using a token other than the internal built in token, specify
606              the token name first, followed by a colon:
607                   olcTLSCertificateFile: my hardware device:Server-Cert
608              Use certutil -L to list the certificates by name:
609                   certutil -d /path/to/certdbdir -L
610
611       olcTLSCertificateKeyFile: <filename>
612              Specifies  the  file  that contains the slapd server private key
613              that matches the certificate stored in the olcTLSCertificateFile
614              file. If the private key is protected with a password, the pass‐
615              word must be manually typed in when slapd starts.   Usually  the
616              private  key is not protected with a password, to allow slapd to
617              start without manual intervention, so it is of  critical  impor‐
618              tance that the file is protected carefully.
619
620              When  using  Mozilla NSS, olcTLSCertificateKeyFile specifies the
621              name of a file that contains the password for the  key  for  the
622              certificate  specified  with olcTLSCertificateFile.  The modutil
623              command can be used to turn  off  password  protection  for  the
624              cert/key  database.   For  example,  if  olcTLSCACertificatePath
625              specifes /etc/openldap/certdb as the location  of  the  cert/key
626              database,  use  modutil  to  change  the  password  to the empty
627              string:
628                   modutil -dbdir /etc/openldap/certdb -changepw 'NSS Certificate DB'
629              You must have the old password,  if  any.   Ignore  the  WARNING
630              about the running browser.  Press 'Enter' for the new password.
631
632
633       olcTLSDHParamFile: <filename>
634              This  directive  specifies the file that contains parameters for
635              Diffie-Hellman ephemeral key exchange.  This is required in  or‐
636              der  to  use a DSA certificate on the server, or an RSA certifi‐
637              cate missing the "key encipherment" key usage.  Note  that  set‐
638              ting  this  option  may also enable Anonymous Diffie-Hellman key
639              exchanges in certain non-default cipher suites.   Anonymous  key
640              exchanges  should generally be avoided since they provide no ac‐
641              tual client or server authentication and provide  no  protection
642              against  man-in-the-middle attacks.  You should append "!ADH" to
643              your cipher suites to ensure that these  suites  are  not  used.
644              When  using  Mozilla  NSS  these parameters are always generated
645              randomly so this directive is ignored.
646
647       olcTLSECName: <name>
648              Specify the name of the  curve(s)  to  use  for  Elliptic  curve
649              Diffie-Hellman ephemeral key exchange.  This option is only used
650              for OpenSSL.  This option is not used with  GnuTLS;  the  curves
651              may  be chosen in the GnuTLS ciphersuite specification. This op‐
652              tion is also ignored for Mozilla NSS.
653
654       olcTLSProtocolMin: <major>[.<minor>]
655              Specifies minimum SSL/TLS protocol version that will be  negoti‐
656              ated.   If the server doesn't support at least that version, the
657              SSL handshake will fail.  To require TLS 1.x or higher, set this
658              option to 3.(x+1), e.g.,
659
660                   olcTLSProtocolMin: 3.2
661
662              would require TLS 1.1.  Specifying a minimum that is higher than
663              that supported by the OpenLDAP implementation will result in  it
664              requiring  the  highest level that it does support.  This direc‐
665              tive is ignored with GnuTLS.
666
667       olcTLSRandFile: <filename>
668              Specifies the file to obtain random bits from when  /dev/[u]ran‐
669              dom  is  not  available.   Generally  set  to  the  name  of the
670              EGD/PRNGD socket.  The environment variable RANDFILE can also be
671              used  to  specify  the filename.  This directive is ignored with
672              GnuTLS and Mozilla NSS.
673
674       olcTLSVerifyClient: <level>
675              Specifies what checks to perform on client  certificates  in  an
676              incoming  TLS  session, if any.  The <level> can be specified as
677              one of the following keywords:
678
679              never  This is the default.  slapd will not ask the client for a
680                     certificate.
681
682              allow  The  client  certificate is requested.  If no certificate
683                     is provided, the session proceeds  normally.   If  a  bad
684                     certificate  is provided, it will be ignored and the ses‐
685                     sion proceeds normally.
686
687              try    The client certificate is requested.  If  no  certificate
688                     is  provided,  the  session  proceeds normally.  If a bad
689                     certificate is provided, the session is immediately  ter‐
690                     minated.
691
692              demand | hard | true
693                     These keywords are all equivalent, for compatibility rea‐
694                     sons.  The client certificate is requested.  If  no  cer‐
695                     tificate  is  provided, or a bad certificate is provided,
696                     the session is immediately terminated.
697
698                     Note that a valid client certificate is required in order
699                     to  use the SASL EXTERNAL authentication mechanism with a
700                     TLS session.  As such, a  non-default  olcTLSVerifyClient
701                     setting  must be chosen to enable SASL EXTERNAL authenti‐
702                     cation.
703
704       olcTLSCRLCheck: <level>
705              Specifies if the Certificate Revocation List  (CRL)  of  the  CA
706              should  be  used  to  verify if the client certificates have not
707              been revoked. This requires olcTLSCACertificatePath parameter to
708              be  set.  This parameter is ignored with GnuTLS and Mozilla NSS.
709              <level> can be specified as one of the following keywords:
710
711              none   No CRL checks are performed
712
713              peer   Check the CRL of the peer certificate
714
715              all    Check the CRL for a whole certificate chain
716
717       olcTLSCRLFile: <filename>
718              Specifies a file containing a Certificate Revocation List to  be
719              used for verifying that certificates have not been revoked. This
720              parameter is only valid when using GnuTLS or Mozilla NSS.
721

DYNAMIC MODULE OPTIONS

723       If slapd is compiled with --enable-modules then the module-related  en‐
724       tries will be available. These entries are named cn=module{x},cn=config
725       and must have the olcModuleList objectClass. One entry should  be  cre‐
726       ated per olcModulePath.  Normally the config engine generates the "{x}"
727       index in the RDN automatically, so it can  be  omitted  when  initially
728       loading these entries.
729
730       olcModuleLoad: <filename>
731              Specify  the  name of a dynamically loadable module to load. The
732              filename may be an absolute path name or a simple filename. Non-
733              absolute  names are searched for in the directories specified by
734              the olcModulePath option.
735
736       olcModulePath: <pathspec>
737              Specify a list of directories to search  for  loadable  modules.
738              Typically  the  path  is colon-separated but this depends on the
739              operating system.  The default is /usr/lib64/openldap, which  is
740              where the standard OpenLDAP install will place its modules.
741

SCHEMA OPTIONS

743       Schema  definitions  are  created as entries in the cn=schema,cn=config
744       subtree. These entries must have the olcSchemaConfig  objectClass.   As
745       noted above, the actual cn=schema,cn=config entry is predefined and any
746       values specified for it are ignored.
747
748
749       olcAttributetypes:    ( <oid>    [NAME <name>]     [DESC <description>]
750              [OBSOLETE]    [SUP <oid>]    [EQUALITY <oid>]   [ORDERING <oid>]
751              [SUBSTR <oid>]  [SYNTAX <oidlen>]  [SINGLE-VALUE]   [COLLECTIVE]
752              [NO-USER-MODIFICATION] [USAGE <attributeUsage>] )
753              Specify an attribute type using the LDAPv3 syntax defined in RFC
754              4512.  The slapd parser  extends  the  RFC  4512  definition  by
755              allowing string forms as well as numeric OIDs to be used for the
756              attribute   OID   and   attribute   syntax   OID.    (See    the
757              olcObjectIdentifier description.)
758
759
760       olcDitContentRules:    ( <oid>    [NAME <name>]    [DESC <description>]
761              [OBSOLETE]     [AUX <oids>]      [MUST <oids>]      [MAY <oids>]
762              [NOT <oids>] )
763              Specify  an  DIT Content Rule using the LDAPv3 syntax defined in
764              RFC 4512.  The slapd parser extends the RFC 4512  definition  by
765              allowing string forms as well as numeric OIDs to be used for the
766              attribute   OID   and   attribute   syntax   OID.    (See    the
767              olcObjectIdentifier description.)
768
769
770       olcObjectClasses: ( <oid> [NAME <name>] [DESC <description>] [OBSOLETE]
771              [SUP <oids>]  [{  ABSTRACT   |   STRUCTURAL   |   AUXILIARY   }]
772              [MUST <oids>] [MAY <oids>] )
773              Specify  an  objectclass  using the LDAPv3 syntax defined in RFC
774              4512.  The slapd parser  extends  the  RFC  4512  definition  by
775              allowing string forms as well as numeric OIDs to be used for the
776              object class OID.  (See  the  olcObjectIdentifier  description.)
777              Object classes are "STRUCTURAL" by default.
778
779       olcObjectIdentifier: <name> { <oid> | <name>[:<suffix>] }
780              Define  a  string name that equates to the given OID. The string
781              can be used in place of  the  numeric  OID  in  objectclass  and
782              attribute  definitions.  The name can also be used with a suffix
783              of the form ":xx" in which case the value "oid.xx" will be used.
784
785

GENERAL BACKEND OPTIONS

787       Options in these entries only apply to the configuration  of  a  single
788       type  of  backend.  All backends may support this class of options, but
789       currently     none     do.      The     entry     must     be     named
790       olcBackend=<databasetype>,cn=config  and must have the olcBackendConfig
791       objectClass.  <databasetype> should be one of bdb, config, dnssrv, hdb,
792       ldap,  ldif, mdb, meta, monitor, ndb, null, passwd, perl, relay, shell,
793       or sql.  At present, no backend implements any options of this type, so
794       this entry should not be used.
795
796

DATABASE OPTIONS

798       Database      options      are      set      in      entries      named
799       olcDatabase={x}<databasetype>,cn=config    and    must     have     the
800       olcDatabaseConfig objectClass. Normally the config engine generates the
801       "{x}" index in the  RDN  automatically,  so  it  can  be  omitted  when
802       initially loading these entries.
803
804       The  special frontend database is always numbered "{-1}" and the config
805       database is always numbered "{0}".
806
807

GLOBAL DATABASE OPTIONS

809       Options in this section may be set in the special  "frontend"  database
810       and  inherited in all the other databases. These options may be altered
811       by further settings in each specific database. The frontend entry  must
812       be    named    olcDatabase=frontend,cn=config   and   must   have   the
813       olcFrontendConfig objectClass.
814
815       olcAccess: to <what> [ by <who> <access> <control> ]+
816              Grant access (specified by <access>) to a set of entries  and/or
817              attributes  (specified  by  <what>)  by  one  or more requestors
818              (specified by <who>).  If no access controls  are  present,  the
819              default  policy  allows anyone and everyone to read anything but
820              restricts updates to rootdn.   (e.g.,  "olcAccess:  to  *  by  *
821              read").   See  slapd.access(5) and the "OpenLDAP Administrator's
822              Guide" for details.
823
824              Access controls set in the frontend are appended to  any  access
825              controls  set  on  the  specific  databases.   The  rootdn  of a
826              database can always read and write EVERYTHING in that database.
827
828              Extra special care must be taken with the access controls on the
829              config  database. Unlike other databases, the default policy for
830              the config database is to  only  allow  access  to  the  rootdn.
831              Regular  users  should  not  have  read access, and write access
832              should be granted very carefully to privileged administrators.
833
834
835       olcDefaultSearchBase: <dn>
836              Specify a default search base to use when client submits a  non-
837              base  search  request with an empty base DN.  Base scoped search
838              requests with an empty base DN are not affected.   This  setting
839              is only allowed in the frontend entry.
840
841       olcExtraAttrs: <attr>
842              Lists  what  attributes  need  to  be  added to search requests.
843              Local storage backends return the entire entry to the  frontend.
844              The   frontend  takes  care  of  only  returning  the  requested
845              attributes that are allowed by  ACLs.   However,  features  like
846              access checking and so may need specific attributes that are not
847              automatically returned by remote storage  backends,  like  proxy
848              backends  and  so on.  <attr> is an attribute that is needed for
849              internal purposes and thus always needs to  be  collected,  even
850              when  not  explicitly  requested  by clients.  This attribute is
851              multi-valued.
852
853       olcPasswordHash: <hash> [<hash>...]
854              This option  configures  one  or  more  hashes  to  be  used  in
855              generation   of   user  passwords  stored  in  the  userPassword
856              attribute during processing of  LDAP  Password  Modify  Extended
857              Operations (RFC 3062).  The <hash> must be one of {SSHA}, {SHA},
858              {SMD5}, {MD5}, {CRYPT}, and {CLEARTEXT}.  The default is {SSHA}.
859
860              {SHA} and {SSHA} use  the  SHA-1  algorithm  (FIPS  160-1),  the
861              latter with a seed.
862
863              {MD5}  and  {SMD5}  use the MD5 algorithm (RFC 1321), the latter
864              with a seed.
865
866              {CRYPT} uses the crypt(3).
867
868              {CLEARTEXT} indicates that the new password should be  added  to
869              userPassword as clear text.
870
871              Note   that   this   option  does  not  alter  the  normal  user
872              applications handling of userPassword during LDAP  Add,  Modify,
873              or  other  LDAP operations.  This setting is only allowed in the
874              frontend entry.
875
876       olcReadOnly: TRUE | FALSE
877              This option  puts  the  database  into  "read-only"  mode.   Any
878              attempts  to  modify  the  database will return an "unwilling to
879              perform" error.  By default, olcReadOnly  is  FALSE.  Note  that
880              when this option is set TRUE on the frontend, it cannot be reset
881              without restarting the  server,  since  further  writes  to  the
882              config database will be rejected.
883
884       olcRequires: <conditions>
885              Specify  a  set  of  conditions  to require (default none).  The
886              directive  may  be  specified  globally   and/or   per-database;
887              databases    inherit    global   conditions,   so   per-database
888              specifications are additive.  bind requires bind operation prior
889              to  directory  operations.   LDAPv3 requires session to be using
890              LDAP  version  3.   authc  requires  authentication   prior   to
891              directory  operations.   SASL requires SASL authentication prior
892              to directory operations.  strong requires strong  authentication
893              prior  to  directory  operations.   The  strong  keyword  allows
894              protected   "simple"   authentication   as    well    as    SASL
895              authentication.   none  may  be  used  to  require no conditions
896              (useful to clear out globally set conditions within a particular
897              database); it must occur first in the list of conditions.
898
899       olcRestrict: <oplist>
900              Specify  a list of operations that are restricted.  Restrictions
901              on  a  specific  database   override   any   frontend   setting.
902              Operations   can   be   any   of  add,  bind,  compare,  delete,
903              extended[=<OID>], modify, rename, search, or the special pseudo-
904              operations read and write, which respectively summarize read and
905              write operations.  The use of restrict write  is  equivalent  to
906              olcReadOnly:  TRUE (see above).  The extended keyword allows one
907              to indicate the OID of the specific operation to be restricted.
908
909       olcSchemaDN: <dn>
910              Specify the distinguished name for the subschema  subentry  that
911              controls   the   entries   on   this  server.   The  default  is
912              "cn=Subschema".
913
914       olcSecurity: <factors>
915              Specify a set of security strength factors (separated  by  white
916              space)  to  require  (see  olcSaslSecprops's minssf option for a
917              description of security strength factors).  The directive may be
918              specified  globally  and/or per-database.  ssf=<n> specifies the
919              overall security strength factor.  transport=<n>  specifies  the
920              transport  security  strength factor.  tls=<n> specifies the TLS
921              security strength factor.  sasl=<n> specifies the SASL  security
922              strength  factor.  update_ssf=<n> specifies the overall security
923              strength   factor   to   require    for    directory    updates.
924              update_transport=<n>  specifies  the transport security strength
925              factor  to  require  for  directory   updates.    update_tls=<n>
926              specifies  the  TLS  security  strength  factor  to  require for
927              directory updates.  update_sasl=<n> specifies the SASL  security
928              strength    factor    to    require   for   directory   updates.
929              simple_bind=<n> specifies the security strength factor  required
930              for  simple  username/password  authentication.   Note  that the
931              transport  factor  is  measure  of  security  provided  by   the
932              underlying  transport, e.g. ldapi:// (and eventually IPSEC).  It
933              is not normally used.
934
935       olcSizeLimit: {<integer>|unlimited}
936
937       olcSizeLimit: size[.{soft|hard|unchecked}]=<integer> [...]
938              Specify the maximum number of entries to return  from  a  search
939              operation.   The  default  size  limit is 500.  Use unlimited to
940              specify no limits.   The  second  format  allows  a  fine  grain
941              setting of the size limits.  Extra args can be added in the same
942              value or as additional values.  See olcLimits for an explanation
943              of the different flags.
944
945       olcSortVals: <attr> [...]
946              Specify  a  list  of  multi-valued  attributes whose values will
947              always be maintained in sorted order.  Using  this  option  will
948              allow   Modify,   Compare,   and  filter  evaluations  on  these
949              attributes to be performed more efficiently. The resulting  sort
950              order  depends  on the attributes' syntax and matching rules and
951              may not correspond to lexical order or  any  other  recognizable
952              order.  This setting is only allowed in the frontend entry.
953
954       olcTimeLimit: {<integer>|unlimited}
955
956       olcTimeLimit: time[.{soft|hard}]=<integer> [...]
957              Specify  the maximum number of seconds (in real time) slapd will
958              spend answering a search request.  The  default  time  limit  is
959              3600.   Use  unlimited  to specify no limits.  The second format
960              allows a fine grain setting of the time limits.  Extra args  can
961              be  added  in  the  same  value  or  as  additional values.  See
962              olcLimits for an explanation of the different flags.
963
964

GENERAL DATABASE OPTIONS

966       Options in this section only apply to the specific database  for  which
967       they  are defined.  They are supported by every type of backend. All of
968       the Global Database Options may also be used here.
969
970       olcAddContentAcl: TRUE | FALSE
971              Controls whether Add operations will perform ACL checks  on  the
972              content  of the entry being added. This check is off by default.
973              See the slapd.access(5) manual page  for  more  details  on  ACL
974              requirements for Add operations.
975
976       olcHidden: TRUE | FALSE
977              Controls  whether the database will be used to answer queries. A
978              database that is hidden will never be  selected  to  answer  any
979              queries,  and  any  suffix  configured  on  the database will be
980              ignored  in  checks  for  conflicts  with  other  databases.  By
981              default, olcHidden is FALSE.
982
983       olcLastMod: TRUE | FALSE
984              Controls   whether   slapd   will   automatically  maintain  the
985              modifiersName,      modifyTimestamp,      creatorsName,      and
986              createTimestamp  attributes  for  entries.  It also controls the
987              entryCSN and entryUUID  attributes,  which  are  needed  by  the
988              syncrepl provider. By default, olcLastMod is TRUE.
989
990       olcLimits: <selector> <limit> [<limit> [...]]
991              Specify  time and size limits based on the operation's initiator
992              or base DN.  The argument <selector> can be any of
993
994                     anonymous    |    users    |    [<dnspec>=]<pattern>    |
995                     group[/oc[/at]]=<pattern>
996
997              with
998
999                     <dnspec> ::= dn[.<type>][.<style>]
1000
1001                     <type>  ::= self | this
1002
1003                     <style>  ::= exact | base | onelevel | subtree | children
1004                     | regex | anonymous
1005
1006              DN type self is the default and means the bound user, while this
1007              means  the base DN of the operation.  The term anonymous matches
1008              all  unauthenticated  clients.   The  term  users  matches   all
1009              authenticated  clients; otherwise an exact dn pattern is assumed
1010              unless otherwise specified  by  qualifying  the  (optional)  key
1011              string dn with exact or base (which are synonyms), to require an
1012              exact match; with onelevel, to  require  exactly  one  level  of
1013              depth  match;  with  subtree, to allow any level of depth match,
1014              including the exact match; with children, to allow any level  of
1015              depth  match,  not  including  the exact match; regex explicitly
1016              requires the  (default)  match  based  on  POSIX  (''extended'')
1017              regular  expression pattern.  Finally, anonymous matches unbound
1018              operations; the pattern field is ignored.  The same behavior  is
1019              obtained  by  using the anonymous form of the <selector> clause.
1020              The  term  group,  with  the   optional   objectClass   oc   and
1021              attributeType  at  fields,  followed by pattern, sets the limits
1022              for any DN listed in the values of  the  at  attribute  (default
1023              member) of the oc group objectClass (default groupOfNames) whose
1024              DN exactly matches pattern.
1025
1026              The currently supported limits are size and time.
1027
1028              The syntax  for  time  limits  is  time[.{soft|hard}]=<integer>,
1029              where  integer  is  the  number  of  seconds  slapd  will  spend
1030              answering a search request.  If  no  time  limit  is  explicitly
1031              requested  by  the  client,  the  soft  limit  is  used;  if the
1032              requested time limit exceeds the hard limit, the  value  of  the
1033              limit  is used instead.  If the hard limit is set to the keyword
1034              soft, the soft limit is used in either case; if it is set to the
1035              keyword unlimited, no hard limit is enforced.  Explicit requests
1036              for time limits smaller or equal to the hard limit are  honored.
1037              If  no limit specifier is set, the value is assigned to the soft
1038              limit, and the hard limit  is  set  to  soft,  to  preserve  the
1039              original behavior.
1040
1041              The        syntax        for        size        limits        is
1042              size[.{soft|hard|unchecked}]=<integer>,  where  integer  is  the
1043              maximum  number  of entries slapd will return answering a search
1044              request.  If no  size  limit  is  explicitly  requested  by  the
1045              client,  the  soft  limit  is  used; if the requested size limit
1046              exceeds the hard limit, the value of the limit is used  instead.
1047              If  the hard limit is set to the keyword soft, the soft limit is
1048              used in either case; if it is set to the keyword  unlimited,  no
1049              hard  limit  is  enforced.   Explicit  requests  for size limits
1050              smaller or equal to the hard limit are honored.   The  unchecked
1051              specifier  sets  a  limit  on  the number of candidates a search
1052              request is allowed to examine.  The rationale behind it is  that
1053              searches for non-properly indexed attributes may result in large
1054              sets of candidates,  which  must  be  examined  by  slapd(8)  to
1055              determine  whether  they  match  the  search filter or not.  The
1056              unchecked limit provides a means to drop such operations  before
1057              they  are  even  started.  If the selected candidates exceed the
1058              unchecked  limit,  the  search  will  abort  with  Unwilling  to
1059              perform.   If  it  is  set to the keyword unlimited, no limit is
1060              applied (the default).  If it is set to disable, the  search  is
1061              not  even performed; this can be used to disallow searches for a
1062              specific set of users.  If no limit specifier is set, the  value
1063              is  assigned  to  the  soft  limit, and the hard limit is set to
1064              soft, to preserve the original behavior.
1065
1066              In case of no match, the global limits are  used.   The  default
1067              values  are  the  same  as for olcSizeLimit and olcTimeLimit; no
1068              limit is set on unchecked.
1069
1070              If pagedResults control is requested, the  hard  size  limit  is
1071              used  by default, because the request of a specific page size is
1072              considered an explicit request for a limitation on the number of
1073              entries  to be returned.  However, the size limit applies to the
1074              total count of entries returned within the search, and not to  a
1075              single page.  Additional size limits may be enforced; the syntax
1076              is size.pr={<integer>|noEstimate|unlimited},  where  integer  is
1077              the  max  page  size  if  no  explicit limit is set; the keyword
1078              noEstimate inhibits the server from returning an estimate of the
1079              total  number  of  entries  that  might  be  returned (note: the
1080              current implementation  does  not  return  any  estimate).   The
1081              keyword  unlimited  indicates  that  no  limit is applied to the
1082              pagedResults     control     page     size.      The      syntax
1083              size.prtotal={<integer>|unlimited|disabled}  allows one to set a
1084              limit on the total  number  of  entries  that  the  pagedResults
1085              control  will  return.   By default it is set to the hard limit.
1086              When set, integer is the max number of entries  that  the  whole
1087              search  with  pagedResults control can return.  Use unlimited to
1088              allow unlimited number of entries to be returned, e.g. to  allow
1089              the  use  of  the  pagedResults control as a means to circumvent
1090              size limitations  on  regular  searches;  the  keyword  disabled
1091              disables  the  control,  i.e.  no paged results can be returned.
1092              Note  that  the  total  number  of  entries  returned  when  the
1093              pagedResults  control  is  requested cannot exceed the hard size
1094              limit of regular searches unless extended by the prtotal switch.
1095
1096       olcMaxDerefDepth: <depth>
1097              Specifies the maximum number  of  aliases  to  dereference  when
1098              trying  to resolve an entry, used to avoid infinite alias loops.
1099              The default is 15.
1100
1101       olcMirrorMode: TRUE | FALSE
1102              This option puts a consumer database into "mirror" mode.  Update
1103              operations  will  be  accepted  from  any  user,  not  just  the
1104              updatedn.  The database must already be configured  as  syncrepl
1105              consumer  before  this  keyword  may  be  set.   This  mode also
1106              requires  a  olcServerID  (see  above)  to  be  configured.   By
1107              default, this setting is FALSE.
1108
1109       olcPlugin: <plugin_type> <lib_path> <init_function> [<arguments>]
1110              Configure  a  SLAPI  plugin. See the slapd.plugin(5) manpage for
1111              more details.
1112
1113       olcRootDN: <dn>
1114              Specify the distinguished name that is  not  subject  to  access
1115              control  or  administrative limit restrictions for operations on
1116              this database.  This DN may or may not  be  associated  with  an
1117              entry.   An empty root DN (the default) specifies no root access
1118              is to be granted.  It is recommended that  the  rootdn  only  be
1119              specified  when  needed  (such  as  when  initially populating a
1120              database).  If the rootdn is within a namingContext (suffix)  of
1121              the  database, a simple bind password may also be provided using
1122              the olcRootPW directive. Note that the rootdn is  always  needed
1123              when  using  syncrepl.   The olcRootDN of the cn=config database
1124              defaults to cn=config itself.
1125
1126       olcRootPW: <password>
1127              Specify a password (or hash of the  password)  for  the  rootdn.
1128              The  password  can  only  be  set  if  the  rootdn is within the
1129              namingContext (suffix) of the database.  This option accepts all
1130              RFC   2307   userPassword  formats  known  to  the  server  (see
1131              olcPasswordHash   description)    as    well    as    cleartext.
1132              slappasswd(8)  may  be  used  to  generate a hash of a password.
1133              Cleartext and {CRYPT} passwords are not recommended.   If  empty
1134              (the  default),  authentication of the root DN is by other means
1135              (e.g. SASL).  Use of SASL is encouraged.
1136
1137       olcSubordinate: [TRUE | FALSE | advertise]
1138              Specify that the current backend database is  a  subordinate  of
1139              another  backend database. A subordinate  database may have only
1140              one suffix. This option may be used to glue  multiple  databases
1141              into  a  single  namingContext.   If  the  suffix of the current
1142              database is within the namingContext  of  a  superior  database,
1143              searches against the superior database will be propagated to the
1144              subordinate as well. All of  the  databases  associated  with  a
1145              single namingContext should have identical rootdns.  Behavior of
1146              other  LDAP  operations  is  unaffected  by  this  setting.   In
1147              particular,  it  is  not  possible to use moddn to move an entry
1148              from  one  subordinate  to  another   subordinate   within   the
1149              namingContext.
1150
1151              If  the  optional advertise flag is supplied, the naming context
1152              of this database is advertised in the root DSE. The  default  is
1153              to hide this database context, so that only the superior context
1154              is visible.
1155
1156              If the slap tools slapcat(8), slapadd(8),  or  slapindex(8)  are
1157              used  on  the  superior  database,  any  glued subordinates that
1158              support these tools are opened as well.
1159
1160              Databases that are glued together should usually  be  configured
1161              with the same indices (assuming they support indexing), even for
1162              attributes that only  exist  in  some  of  these  databases.  In
1163              general,  all  of  the  glued  databases should be configured as
1164              similarly as possible,  since  the  intent  is  to  provide  the
1165              appearance of a single directory.
1166
1167              Note   that   the   subordinate   functionality  is  implemented
1168              internally by the glue overlay and as  such  its  behavior  will
1169              interact  with  other  overlays  in  use.  By  default, the glue
1170              overlay is automatically configured as the last overlay  on  the
1171              superior   database.   Its  position  on  the  database  can  be
1172              explicitly configured by setting an overlay  glue  directive  at
1173              the  desired  position. This explicit configuration is necessary
1174              e.g.  when using the syncprov overlay,  which  needs  to  follow
1175              glue in order to work over all of the glued databases. E.g.
1176                   dn: olcDatabase={1}mdb,cn=config
1177                   olcSuffix: dc=example,dc=com
1178                   ...
1179
1180                   dn: olcOverlay={0}glue,olcDatabase={1}mdb,cn=config
1181                   ...
1182
1183                   dn: olcOverlay={1}syncprov,olcDatabase={1}mdb,cn=config
1184                   ...
1185       See the Overlays section below for more details.
1186
1187       olcSuffix: <dn suffix>
1188              Specify  the  DN  suffix  of queries that will be passed to this
1189              backend database.  Multiple suffix lines can  be  given  and  at
1190              least one is required for each database definition.
1191
1192              If  the  suffix of one database is "inside" that of another, the
1193              database  with  the  inner  suffix  must  come  first   in   the
1194              configuration  file.   You  may also want to glue such databases
1195              together with the olcSubordinate attribute.
1196
1197       olcSyncUseSubentry: TRUE | FALSE
1198              Store the syncrepl contextCSN  in  a  subentry  instead  of  the
1199              context  entry  of  the  database.  The  subentry's  RDN will be
1200              "cn=ldapsync". The default is FALSE, meaning the  contextCSN  is
1201              stored in the context entry.
1202
1203       olcSyncrepl:   rid=<replica   ID>  provider=ldap[s]://<hostname>[:port]
1204              searchbase=<base    DN>     [type=refreshOnly|refreshAndPersist]
1205              [interval=dd:hh:mm:ss]    [retry=[<retry    interval>    <#   of
1206              retries>]+]  [filter=<filter  str>]  [scope=sub|one|base|subord]
1207              [attrs=<attr    list>]    [exattrs=<attr    list>]   [attrsonly]
1208              [sizelimit=<limit>] [timelimit=<limit>]  [schemachecking=on|off]
1209              [network-timeout=<seconds>]                  [timeout=<seconds>]
1210              [bindmethod=simple|sasl]     [binddn=<dn>]     [saslmech=<mech>]
1211              [authcid=<identity>] [authzid=<identity>] [credentials=<passwd>]
1212              [realm=<realm>]                          [secprops=<properties>]
1213              [keepalive=<idle>:<probes>:<interval>]   [starttls=yes|critical]
1214              [tls_cert=<file>]      [tls_key=<file>]      [tls_cacert=<file>]
1215              [tls_cacertdir=<path>]      [tls_reqcert=never|allow|try|demand]
1216              [tls_reqsan=never|allow|try|demand] [tls_cipher_suite=<ciphers>]
1217              [tls_ecname=<names>]                [tls_crlcheck=none|peer|all]
1218              [tls_protocol_min=<major>[.<minor>]]  [suffixmassage=<real  DN>]
1219              [logbase=<base        DN>]        [logfilter=<filter       str>]
1220              [syncdata=default|accesslog|changelog]
1221              Specify the current database as a consumer which is kept  up-to-
1222              date  with  the  provider  content  by  establishing the current
1223              slapd(8) as a  replication  consumer  site  running  a  syncrepl
1224              replication  engine.   The consumer content is kept synchronized
1225              to the provider content using the LDAP  Content  Synchronization
1226              protocol.  Refer  to  the  "OpenLDAP  Administrator's Guide" for
1227              detailed information on setting up a replicated slapd  directory
1228              service using the syncrepl replication engine.
1229
1230              rid   identifies  the  current  syncrepl  directive  within  the
1231              replication consumer site.  It is a non-negative integer  having
1232              no more than three decimal digits.
1233
1234              provider  specifies the replication provider site containing the
1235              provider content as an LDAP URI. If <port>  is  not  given,  the
1236              standard LDAP port number (389 or 636) is used.
1237
1238              The  content  of the syncrepl consumer is defined using a search
1239              specification as its result set. The consumer  slapd  will  send
1240              search  requests  to  the provider slapd according to the search
1241              specification. The  search  specification  includes  searchbase,
1242              scope,   filter,  attrs,  attrsonly,  sizelimit,  and  timelimit
1243              parameters as in the normal search  specification.  The  exattrs
1244              option  may  also  be  used to specify attributes that should be
1245              omitted from incoming entries.  The scope defaults to  sub,  the
1246              filter  defaults  to  (objectclass=*),  and  there is no default
1247              searchbase. The attrs list defaults to "*,+" to return all  user
1248              and  operational attributes, and attrsonly and exattrs are unset
1249              by default.  The sizelimit and timelimit only accept "unlimited"
1250              and  positive  integers, and both default to "unlimited".  Note,
1251              however, that  any  provider-side  limits  for  the  replication
1252              identity  will  be  enforced  by  the provider regardless of the
1253              limits requested by the LDAP Content Synchronization  operation,
1254              much like for any other search operation.
1255
1256              The  LDAP  Content  Synchronization  protocol  has two operation
1257              types.  In the refreshOnly operation, the  next  synchronization
1258              search operation is periodically rescheduled at an interval time
1259              (specified by interval parameter; 1 day by default)  after  each
1260              synchronization  operation  finishes.   In the refreshAndPersist
1261              operation, a synchronization search remains  persistent  in  the
1262              provider  slapd.   Further updates to the provider will generate
1263              searchResultEntry to the consumer slapd as the search  responses
1264              to  the persistent synchronization search. If the initial search
1265              fails due to an error, the next synchronization search operation
1266              is  periodically  rescheduled  at an interval time (specified by
1267              interval parameter; 1 day by default)
1268
1269              If an error occurs during replication, the consumer will attempt
1270              to reconnect according to the retry parameter which is a list of
1271              the <retry interval> and <# of  retries>  pairs.   For  example,
1272              retry="60 10 300 3" lets the consumer retry every 60 seconds for
1273              the first 10 times and then retry every 300 seconds for the next
1274              3  times  before  stop retrying. The `+' in <# of retries> means
1275              indefinite number of retries until success.
1276
1277              The schema checking can be enforced at the  LDAP  Sync  consumer
1278              site  by turning on the schemachecking parameter. The default is
1279              off.
1280
1281              The network-timeout parameter sets how long  the  consumer  will
1282              wait  to  establish a network connection to the provider. Once a
1283              connection is established, the timeout parameter determines  how
1284              long  the  consumer  will  wait  for the initial Bind request to
1285              complete.  The  defaults  for   these   parameters   come   from
1286              ldap.conf(5).
1287
1288              A   bindmethod   of  simple  requires  the  options  binddn  and
1289              credentials and should  only  be  used  when  adequate  security
1290              services (e.g. TLS or IPSEC) are in place.  A bindmethod of sasl
1291              requires the option saslmech.  Depending on  the  mechanism,  an
1292              authentication  identity  and/or  credentials  can  be specified
1293              using authcid and credentials.  The  authzid  parameter  may  be
1294              used  to  specify  an authorization identity.  Specific security
1295              properties (as with the sasl-secprops keyword above) for a  SASL
1296              bind  can  be  set  with the secprops option. A non default SASL
1297              realm can be set with the realm  option.   The  provider,  other
1298              than allow authentication of the syncrepl identity, should grant
1299              that identity appropriate access privileges to the data that  is
1300              being  replicated  (access  directive), and appropriate time and
1301              size limits (limits directive).
1302
1303              The keepalive parameter sets the values  of  idle,  probes,  and
1304              interval  used  to  check whether a socket is alive; idle is the
1305              number of seconds a connection needs to remain idle  before  TCP
1306              starts sending keepalive probes; probes is the maximum number of
1307              keepalive probes TCP should send before dropping the connection;
1308              interval  is  interval  in  seconds between individual keepalive
1309              probes.  Only some systems support the  customization  of  these
1310              values;  the  keepalive  parameter  is  ignored  otherwise,  and
1311              system-wide settings are used.
1312
1313              The starttls parameter specifies use of  the  StartTLS  extended
1314              operation  to  establish  a  TLS  session  before Binding to the
1315              provider. If the critical argument is supplied, the session will
1316              be aborted if the StartTLS request fails. Otherwise the syncrepl
1317              session continues without TLS. The tls_reqcert setting  defaults
1318              to "demand", the tls_reqsan setting defaults to "allow", and the
1319              other TLS settings default to the same as  the  main  slapd  TLS
1320              settings.
1321
1322              The  suffixmassage parameter allows the consumer to pull entries
1323              from a remote directory whose DN suffix differs from  the  local
1324              directory.  The  portion of the remote entries' DNs that matches
1325              the searchbase will be replaced with the suffixmassage DN.
1326
1327              Rather than replicating whole entries, the  consumer  can  query
1328              logs  of  data modifications. This mode of operation is referred
1329              to as delta syncrepl. In addition to the above  parameters,  the
1330              logbase  and  logfilter parameters must be set appropriately for
1331              the log that will be used. The syncdata parameter must be set to
1332              either "accesslog" if the log conforms to the slapo-accesslog(5)
1333              log format, or "changelog" if the log conforms to  the  obsolete
1334              changelog format. If the syncdata parameter is omitted or set to
1335              "default" then the log parameters are ignored.
1336
1337       olcUpdateDN: <dn>
1338              This option is  only  applicable  in  a  replica  database.   It
1339              specifies   the  DN  permitted  to  update  (subject  to  access
1340              controls) the replica.  It is only needed in  certain  push-mode
1341              replication  scenarios.   Generally,  this  DN should not be the
1342              same as the rootdn used at the provider.
1343
1344       olcUpdateRef: <url>
1345              Specify the referral to pass back  when  slapd(8)  is  asked  to
1346              modify  a  replicated  local  database.   If multiple values are
1347              specified, each url is provided.
1348
1349

DATABASE-SPECIFIC OPTIONS

1351       Each database  may  allow  specific  configuration  options;  they  are
1352       documented   separately   in   the  backends'  manual  pages.  See  the
1353       slapd.backends(5) manual page for an overview of available backends.
1354

OVERLAYS

1356       An overlay is a piece of code that intercepts  database  operations  in
1357       order  to  extend or change them. Overlays are pushed onto a stack over
1358       the database, and so they will execute in the reverse of the  order  in
1359       which they were configured and the database itself will receive control
1360       last of all.
1361
1362       Overlays must be configured as child entries of  a  specific  database.
1363       The entry's RDN must be of the form olcOverlay={x}<overlaytype> and the
1364       entry must have the olcOverlayConfig objectClass. Normally  the  config
1365       engine generates the "{x}" index in the RDN automatically, so it can be
1366       omitted when initially loading these entries.
1367
1368       See the slapd.overlays(5) manual page  for  an  overview  of  available
1369       overlays.
1370

EXAMPLES

1372       Here  is  a  short  example of a configuration in LDIF suitable for use
1373       with slapadd(8) :
1374
1375              dn: cn=config
1376              objectClass: olcGlobal
1377              cn: config
1378              olcPidFile: /var/run/slapd.pid
1379              olcAttributeOptions: x-hidden lang-
1380
1381              dn: cn=schema,cn=config
1382              objectClass: olcSchemaConfig
1383              cn: schema
1384
1385              include: file:///etc/openldap/schema/core.ldif
1386
1387              dn: olcDatabase=frontend,cn=config
1388              objectClass: olcDatabaseConfig
1389              objectClass: olcFrontendConfig
1390              olcDatabase: frontend
1391              # Subtypes of "name" (e.g. "cn" and "ou") with the
1392              # option ";x-hidden" can be searched for/compared,
1393              # but are not shown.  See slapd.access(5).
1394              olcAccess: to attrs=name;x-hidden by * =cs
1395              # Protect passwords.  See slapd.access(5).
1396              olcAccess: to attrs=userPassword  by * auth
1397              # Read access to other attributes and entries.
1398              olcAccess: to * by * read
1399
1400              # set a rootpw for the config database so we can bind.
1401              # deny access to everyone else.
1402              dn: olcDatabase=config,cn=config
1403              objectClass: olcDatabaseConfig
1404              olcDatabase: config
1405              olcRootPW: {SSHA}XKYnrjvGT3wZFQrDD5040US592LxsdLy
1406              olcAccess: to * by * none
1407
1408              dn: olcDatabase=bdb,cn=config
1409              objectClass: olcDatabaseConfig
1410              objectClass: olcBdbConfig
1411              olcDatabase: bdb
1412              olcSuffix: "dc=our-domain,dc=com"
1413              # The database directory MUST exist prior to
1414              # running slapd AND should only be accessible
1415              # by the slapd/tools. Mode 0700 recommended.
1416              olcDbDirectory: /var/openldap-data
1417              # Indices to maintain
1418              olcDbIndex:     objectClass  eq
1419              olcDbIndex:     cn,sn,mail   pres,eq,approx,sub
1420
1421              # We serve small clients that do not handle referrals,
1422              # so handle remote lookups on their behalf.
1423              dn: olcDatabase=ldap,cn=config
1424              objectClass: olcDatabaseConfig
1425              objectClass: olcLdapConfig
1426              olcDatabase: ldap
1427              olcSuffix: ""
1428              olcDbUri: ldap://ldap.some-server.com/
1429
1430       Assuming the above data was saved in a file named "config.ldif" and the
1431       /etc/openldap/slapd.d  directory  has  been  created, this command will
1432       initialize the configuration:
1433              slapadd -F /etc/openldap/slapd.d -n 0 -l config.ldif
1434
1435
1436       "OpenLDAP Administrator's Guide" contains a longer annotated example of
1437       a slapd configuration.
1438
1439       Alternatively,  an existing slapd.conf file can be converted to the new
1440       format using slapd or any of the slap tools:
1441              slaptest -f /etc/openldap/slapd.conf -F /etc/openldap/slapd.d
1442
1443

FILES

1445       /etc/openldap/slapd.conf
1446              default slapd configuration file
1447
1448       /etc/openldap/slapd.d
1449              default slapd configuration directory
1450

SEE ALSO

1452       ldap(3), ldif(5),  gnutls-cli(1),  slapd.access(5),  slapd.backends(5),
1453       slapd.conf(5),     slapd.overlays(5),     slapd.plugin(5),    slapd(8),
1454       slapacl(8),    slapadd(8),    slapauth(8),    slapcat(8),    slapdn(8),
1455       slapindex(8), slappasswd(8), slaptest(8).
1456
1457       "OpenLDAP Administrator's Guide" (http://www.OpenLDAP.org/doc/admin/)
1458

ACKNOWLEDGEMENTS

1460       OpenLDAP  Software  is developed and maintained by The OpenLDAP Project
1461       <http://www.openldap.org/>.  OpenLDAP  Software  is  derived  from  the
1462       University of Michigan LDAP 3.3 Release.
1463
1464
1465
1466OpenLDAP 2.4.57                   2021/01/18                   SLAPD-CONFIG(5)
Impressum