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

TLS OPTIONS

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

DYNAMIC MODULE OPTIONS

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

SCHEMA OPTIONS

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

GENERAL BACKEND OPTIONS

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

DATABASE OPTIONS

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

GLOBAL DATABASE OPTIONS

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

GENERAL DATABASE OPTIONS

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

DATABASE-SPECIFIC OPTIONS

1347       Each  database  may  allow  specific  configuration  options;  they are
1348       documented  separately  in  the  backends'  manual   pages.   See   the
1349       slapd.backends(5) manual page for an overview of available backends.
1350

OVERLAYS

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

EXAMPLES

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

FILES

1441       /etc/openldap/slapd.conf
1442              default slapd configuration file
1443
1444       /etc/openldap/slapd.d
1445              default slapd configuration directory
1446

SEE ALSO

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

ACKNOWLEDGEMENTS

1456       OpenLDAP Software is developed and maintained by The  OpenLDAP  Project
1457       <http://www.openldap.org/>.   OpenLDAP  Software  is  derived  from the
1458       University of Michigan LDAP 3.3 Release.
1459
1460
1461
1462OpenLDAP 2.4.50                   2020/04/28                   SLAPD-CONFIG(5)
Impressum