2 # Copyright 1999-2009 The OpenLDAP Foundation, All Rights Reserved.
3 # COPYING RESTRICTIONS APPLY, see COPYRIGHT.
5 H1: The slapd Configuration File
7 Once the software has been built and installed, you are ready
8 to configure {{slapd}}(8) for use at your site. The slapd
9 runtime configuration is primarily accomplished through the
10 {{slapd.conf}}(5) file, normally installed in the
11 {{EX:/usr/local/etc/openldap}} directory.
13 An alternate configuration file location can be specified via a command-line
14 option to {{slapd}}(8). This chapter describes the general format
15 of the {{slapd.conf}}(5) configuration file, followed by a detailed
16 description of commonly used config file directives.
19 H2: Configuration File Format
21 The {{slapd.conf}}(5) file consists of three types of configuration
22 information: global, backend specific, and database specific. Global
23 information is specified first, followed by information associated
24 with a particular backend type, which is then followed by information
25 associated with a particular database instance. Global directives can
26 be overridden in backend and/or database directives, and backend directives
27 can be overridden by database directives.
29 Blank lines and comment lines beginning with a '{{EX:#}}' character
30 are ignored. If a line begins with whitespace, it is considered a
31 continuation of the previous line (even if the previous line is a
34 The general format of slapd.conf is as follows:
36 > # global configuration directives
37 > <global config directives>
39 > # backend definition
41 > <backend-specific directives>
43 > # first database definition & config directives
45 > <database-specific directives>
47 > # second database definition & config directives
49 > <database-specific directives>
51 > # second database definition & config directives
53 > <database-specific directives>
55 > # subsequent backend & database definitions & config directives
58 A configuration directive may take arguments. If so, they are
59 separated by whitespace. If an argument contains whitespace,
60 the argument should be enclosed in double quotes {{EX:"like this"}}. If
61 an argument contains a double quote or a backslash character `{{EX:\}}',
62 the character should be preceded by a backslash character `{{EX:\}}'.
64 The distribution contains an example configuration file that will
65 be installed in the {{F: /usr/local/etc/openldap}} directory.
66 A number of files containing schema definitions (attribute types
67 and object classes) are also provided in the
68 {{F: /usr/local/etc/openldap/schema}} directory.
71 H2: Configuration File Directives
73 This section details commonly used configuration directives. For
74 a complete list, see the {{slapd.conf}}(5) manual page. This section
75 separates the configuration file directives into global,
76 backend-specific and data-specific categories, describing each
77 directive and its default value (if any), and giving an example of
84 Directives described in this section apply to all backends
85 and databases unless specifically overridden in a backend or
86 database definition. Arguments that should be replaced
87 by actual text are shown in brackets {{EX:<>}}.
90 H4: access to <what> [ by <who> [<accesslevel>] [<control>] ]+
92 This directive grants access (specified by <accesslevel>) to a set
93 of entries and/or attributes (specified by <what>) by one or more
94 requestors (specified by <who>). See the {{SECT:Access Control}} section of
95 this guide for basic usage.
98 More details discussion of this directive can be found in the
99 {{SECT:Advanced Access Control}} chapter.
102 Note: If no {{EX:access}} directives are specified, the default
103 access control policy, {{EX:access to * by * read}}, allows all
104 both authenticated and anonymous users read access.
107 H4: attributetype <{{REF:RFC4512}} Attribute Type Description>
109 This directive defines an attribute type.
110 Please see the {{SECT:Schema Specification}} chapter
111 for information regarding how to use this directive.
113 H4: idletimeout <integer>
115 Specify the number of seconds to wait before forcibly closing
116 an idle client connection. An idletimeout of 0, the default,
117 disables this feature.
120 H4: include <filename>
122 This directive specifies that slapd should read additional
123 configuration information from the given file before continuing
124 with the next line of the current file. The included file should
125 follow the normal slapd config file format. The file is commonly
126 used to include files containing schema specifications.
128 Note: You should be careful when using this directive - there is
129 no small limit on the number of nested include directives, and no
130 loop detection is done.
132 H4: loglevel <integer>
134 This directive specifies the level at which debugging statements
135 and operation statistics should be syslogged (currently logged to
136 the {{syslogd}}(8) {{EX:LOG_LOCAL4}} facility). You must have
137 configured OpenLDAP {{EX:--enable-debug}} (the default) for this
138 to work (except for the two statistics levels, which are always
139 enabled). Log levels may be specified as integers or by keyword.
140 Multiple log levels may be used and the levels are additive. To display what
141 numbers correspond to what kind of debugging, invoke slapd with {{EX:-d?}}
142 or consult the table below. The possible values for <integer> are:
144 !block table; colaligns="RL"; align=Center; \
145 title="Table 6.1: Debugging Levels"
146 Level Keyword Description
147 -1 any enable all debugging
149 1 (0x1 trace) trace function calls
150 2 (0x2 packets) debug packet handling
151 4 (0x4 args) heavy trace debugging
152 8 (0x8 conns) connection management
153 16 (0x10 BER) print out packets sent and received
154 32 (0x20 filter) search filter processing
155 64 (0x40 config) configuration processing
156 128 (0x80 ACL) access control list processing
157 256 (0x100 stats) stats log connections/operations/results
158 512 (0x200 stats2) stats log entries sent
159 1024 (0x400 shell) print communication with shell backends
160 2048 (0x800 parse) print entry parsing debugging
161 16384 (0x4000 sync) syncrepl consumer processing
162 32768 (0x8000 none) only messages that get logged whatever log level is set
165 The desired log level can be input as a single integer that
166 combines the (ORed) desired levels, both in decimal or in hexadecimal
167 notation, as a list of integers (that are ORed internally), or as a list of the names that are shown between brackets, such that
181 This will cause lots and lots of debugging information to be
184 E: loglevel conns filter
186 Just log the connection and search filter processing.
190 Log those messages that are logged regardless of the configured loglevel. This
191 differs from setting the log level to 0, when no logging occurs. At least the
192 {{EX:None}} level is required to have high priority messages logged.
198 Basic stats logging is configured by default. However, if no loglevel is
199 defined, no logging occurs (equivalent to a 0 level).
201 H4: objectclass <{{REF:RFC4512}} Object Class Description>
203 This directive defines an object class.
204 Please see the {{SECT:Schema Specification}} chapter for
205 information regarding how to use this directive.
210 This directive specifies the referral to pass back when slapd
211 cannot find a local database to handle a request.
215 > referral ldap://root.openldap.org
217 This will refer non-local queries to the global root LDAP server
218 at the OpenLDAP Project. Smart LDAP clients can re-ask their
219 query at that server, but note that most of these clients are
220 only going to know how to handle simple LDAP URLs that
221 contain a host part and optionally a distinguished name part.
224 H4: sizelimit <integer>
226 This directive specifies the maximum number of entries to return
227 from a search operation.
233 See the {{SECT:Limits}} section of this guide and slapd.conf(5)
236 H4: timelimit <integer>
238 This directive specifies the maximum number of seconds (in real
239 time) slapd will spend answering a search request. If a
240 request is not finished in this time, a result indicating an
241 exceeded timelimit will be returned.
247 See the {{SECT:Limits}} section of this guide and slapd.conf(5)
251 H3: General Backend Directives
253 Directives in this section apply only to the backend in which
254 they are defined. They are supported by every type of backend.
255 Backend directives apply to all databases instances of the
256 same type and, depending on the directive, may be overridden
257 by database directives.
261 This directive marks the beginning of a backend declaration.
262 {{EX:<type>}} should be one of the
263 supported backend types listed in Table 6.2.
265 !block table; align=Center; coltags="EX,N"; \
266 title="Table 5.2: Database Backends"
268 bdb Berkeley DB transactional backend
269 dnssrv DNS SRV backend
270 hdb Hierarchical variant of bdb backend
271 ldap Lightweight Directory Access Protocol (Proxy) backend
272 meta Meta Directory backend
273 monitor Monitor backend
274 passwd Provides read-only access to {{passwd}}(5)
275 perl Perl Programmable backend
276 shell Shell (extern program) backend
277 sql SQL Programmable backend
284 This marks the beginning of a new {{TERM:BDB}} backend
288 H3: General Database Directives
290 Directives in this section apply only to the database in which
291 they are defined. They are supported by every type of database.
295 This directive marks the beginning of a database instance
297 {{EX:<type>}} should be one of the
298 supported backend types listed in Table 6.2.
304 This marks the beginning of a new {{TERM:BDB}} database instance
308 H4: limits <who> <limit> [<limit> [...]]
310 Specify time and size limits based on who initiated an operation.
312 See the {{SECT:Limits}} section of this guide and slapd.conf(5)
316 H4: readonly { on | off }
318 This directive puts the database into "read-only" mode. Any
319 attempts to modify the database will return an "unwilling to
329 This directive specifies the DN that is not subject to
330 access control or administrative limit restrictions for
331 operations on this database. The DN need not refer to
332 an entry in this database or even in the directory. The
333 DN may refer to a SASL identity.
337 > rootdn "cn=Manager,dc=example,dc=com"
341 > rootdn "uid=root,cn=example.com,cn=digest-md5,cn=auth"
343 See the {{SECT:SASL Authentication}} section for information on
344 SASL authentication identities.
347 H4: rootpw <password>
349 This directive can be used to specifies a password for the DN for
350 the rootdn (when the rootdn is set to a DN within the database).
356 It is also permissible to provide hash of the password in {{REF:RFC2307}}
357 form. {{slappasswd}}(8) may be used to generate the password hash.
361 > rootpw {SSHA}ZKKuqbEKJfKSXhUbHG3fG8MDn9j1v4QN
363 The hash was generated using the command {{EX:slappasswd -s secret}}.
366 H4: suffix <dn suffix>
368 This directive specifies the DN suffix of queries that will be
369 passed to this backend database. Multiple suffix lines can be
370 given, and at least one is required for each database
375 > suffix "dc=example,dc=com"
377 Queries with a DN ending in "dc=example,dc=com"
378 will be passed to this backend.
380 Note: When the backend to pass a query to is selected, slapd
381 looks at the suffix line(s) in each database definition in the
382 order they appear in the file. Thus, if one database suffix is a
383 prefix of another, it must appear after it in the config file.
388 > syncrepl rid=<replica ID>
389 > provider=ldap[s]://<hostname>[:port]
390 > [type=refreshOnly|refreshAndPersist]
391 > [interval=dd:hh:mm:ss]
392 > [retry=[<retry interval> <# of retries>]+]
393 > searchbase=<base DN>
394 > [filter=<filter str>]
395 > [scope=sub|one|base]
396 > [attrs=<attr list>]
398 > [sizelimit=<limit>]
399 > [timelimit=<limit>]
400 > [schemachecking=on|off]
401 > [bindmethod=simple|sasl]
404 > [authcid=<identity>]
405 > [authzid=<identity>]
406 > [credentials=<passwd>]
408 > [secprops=<properties>]
409 > [starttls=yes|critical]
412 > [tls_cacert=<file>]
413 > [tls_cacertdir=<path>]
414 > [tls_reqcert=never|allow|try|demand]
415 > [tls_ciphersuite=<ciphers>]
416 > [tls_crlcheck=none|peer|all]
417 > [logbase=<base DN>]
418 > [logfilter=<filter str>]
419 > [syncdata=default|accesslog|changelog]
422 This directive specifies the current database as a replica of the
423 master content by establishing the current {{slapd}}(8) as a
424 replication consumer site running a syncrepl replication engine.
425 The master database is located at the replication provider site
426 specified by the {{EX:provider}} parameter. The replica database is
427 kept up-to-date with the master content using the LDAP Content
428 Synchronization protocol. See {{REF:RFC4533}}
429 for more information on the protocol.
431 The {{EX:rid}} parameter is used for identification of the current
432 {{EX:syncrepl}} directive within the replication consumer server,
433 where {{EX:<replica ID>}} uniquely identifies the syncrepl specification
434 described by the current {{EX:syncrepl}} directive. {{EX:<replica ID>}}
435 is non-negative and is no more than three decimal digits in length.
437 The {{EX:provider}} parameter specifies the replication provider site
438 containing the master content as an LDAP URI. The {{EX:provider}}
439 parameter specifies a scheme, a host and optionally a port where the
440 provider slapd instance can be found. Either a domain name or IP
441 address may be used for <hostname>. Examples are
442 {{EX:ldap://provider.example.com:389}} or {{EX:ldaps://192.168.1.1:636}}.
443 If <port> is not given, the standard LDAP port number (389 or 636) is used.
444 Note that the syncrepl uses a consumer-initiated protocol, and hence its
445 specification is located at the consumer site, whereas the {{EX:replica}}
446 specification is located at the provider site. {{EX:syncrepl}} and
447 {{EX:replica}} directives define two independent replication
448 mechanisms. They do not represent the replication peers of each other.
450 The content of the syncrepl replica is defined using a search
451 specification as its result set. The consumer slapd will
452 send search requests to the provider slapd according to the search
453 specification. The search specification includes {{EX:searchbase}},
454 {{EX:scope}}, {{EX:filter}}, {{EX:attrs}}, {{EX:attrsonly}},
455 {{EX:sizelimit}}, and {{EX:timelimit}} parameters as in the normal
456 search specification. The {{EX:searchbase}} parameter has no
457 default value and must always be specified. The {{EX:scope}} defaults
458 to {{EX:sub}}, the {{EX:filter}} defaults to {{EX:(objectclass=*)}},
459 {{EX:attrs}} defaults to {{EX:"*,+"}} to replicate all user and operational
460 attributes, and {{EX:attrsonly}} is unset by default. Both {{EX:sizelimit}}
461 and {{EX:timelimit}} default to "unlimited", and only positive integers
462 or "unlimited" may be specified.
464 The {{TERM[expand]LDAP Sync}} protocol has two operation
465 types: {{EX:refreshOnly}} and {{EX:refreshAndPersist}}.
466 The operation type is specified by the {{EX:type}} parameter.
467 In the {{EX:refreshOnly}} operation, the next synchronization search operation
468 is periodically rescheduled at an interval time after each
469 synchronization operation finishes. The interval is specified
470 by the {{EX:interval}} parameter. It is set to one day by default.
471 In the {{EX:refreshAndPersist}} operation, a synchronization search
472 remains persistent in the provider {{slapd}} instance. Further updates to the
473 master replica will generate {{EX:searchResultEntry}} to the consumer slapd
474 as the search responses to the persistent synchronization search.
476 If an error occurs during replication, the consumer will attempt to reconnect
477 according to the retry parameter which is a list of the <retry interval>
478 and <# of retries> pairs. For example, retry="60 10 300 3" lets the consumer
479 retry every 60 seconds for the first 10 times and then retry every 300 seconds
480 for the next three times before stop retrying. + in <# of retries> means
481 indefinite number of retries until success.
483 The schema checking can be enforced at the LDAP Sync consumer site
484 by turning on the {{EX:schemachecking}} parameter.
485 If it is turned on, every replicated entry will be checked for its
486 schema as the entry is stored into the replica content.
487 Every entry in the replica should contain those attributes
488 required by the schema definition.
489 If it is turned off, entries will be stored without checking
490 schema conformance. The default is off.
492 The {{EX:binddn}} parameter gives the DN to bind as for the
493 syncrepl searches to the provider slapd. It should be a DN
494 which has read access to the replication content in the
497 The {{EX:bindmethod}} is {{EX:simple}} or {{EX:sasl}},
498 depending on whether simple password-based authentication or
499 {{TERM:SASL}} authentication is to be used when connecting
500 to the provider {{slapd}} instance.
502 Simple authentication should not be used unless adequate data
503 integrity and confidentiality protections are in place (e.g. TLS
504 or IPsec). Simple authentication requires specification of {{EX:binddn}}
505 and {{EX:credentials}} parameters.
507 SASL authentication is generally recommended. SASL authentication
508 requires specification of a mechanism using the {{EX:saslmech}} parameter.
509 Depending on the mechanism, an authentication identity and/or
510 credentials can be specified using {{EX:authcid}} and {{EX:credentials}},
511 respectively. The {{EX:authzid}} parameter may be used to specify
512 an authorization identity.
514 The {{EX:realm}} parameter specifies a realm which a certain
515 mechanisms authenticate the identity within. The {{EX:secprops}}
516 parameter specifies Cyrus SASL security properties.
518 The {{EX:starttls}} parameter specifies use of the StartTLS extended
519 operation to establish a TLS session before authenticating to the provider.
520 If the {{EX:critical}} argument is supplied, the session will be aborted
521 if the StartTLS request fails. Otherwise the syncrepl session continues
522 without TLS. Note that the main slapd TLS settings are not used by the
523 syncrepl engine; by default the TLS parameters from a {{ldap.conf}}(5)
524 configuration file will be used. TLS settings may be specified here,
525 in which case any {{ldap.conf}}(5) settings will be completely ignored.
527 Rather than replicating whole entries, the consumer can query logs
528 of data modifications. This mode of operation is referred to as
529 {{delta syncrepl}}. In addition to the above parameters, the
530 {{EX:logbase}} and {{EX:logfilter}} parameters must be set appropriately
531 for the log that will be used. The {{EX:syncdata}} parameter must
532 be set to either {{EX:"accesslog"}} if the log conforms to the
533 {{slapo-accesslog}}(5) log format, or {{EX:"changelog"}} if the log
534 conforms to the obsolete {{changelog}} format. If the {{EX:syncdata}}
535 parameter is omitted or set to {{EX:"default"}} then the log
536 parameters are ignored.
538 The {{syncrepl}} replication mechanism is supported by the {{bdb}} and
541 See the {{SECT:LDAP Sync Replication}} chapter of this guide for
542 more information on how to use this directive.
547 This directive is only applicable in a {{slave}} (or {{shadow}})
548 {{slapd}}(8) instance. It
549 specifies the URL to return to clients which submit update
550 requests upon the replica.
551 If specified multiple times, each {{TERM:URL}} is provided.
555 > updateref ldap://master.example.net
558 H3: BDB and HDB Database Directives
560 Directives in this category only apply to both the {{TERM:BDB}}
561 and the {{TERM:HDB}} database.
562 That is, they must follow a "database bdb" or "database hdb" line
564 subsequent "backend" or "database" line. For a complete reference
565 of BDB/HDB configuration directives, see {{slapd-bdb}}(5).
568 H4: directory <directory>
570 This directive specifies the directory where the BDB files
571 containing the database and associated indices live.
575 > directory /usr/local/var/openldap-data