2 # Copyright 1999-2000, 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 can be specified via a
14 command-line option to {{slapd}}(8) or {{slurpd}}(8). This chapter
15 describes the general format of the config file, followed by a
16 detailed 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 white space, it is considered a
31 continuation of the previous line. The general format of slapd.conf is
34 > # global configuration directives
35 > <global config directives>
37 > # backend definition
39 > <backend-specific directives>
41 > # first database definition & config directives
43 > <database-specific directives>
45 > # second database definition & config directives
47 > <database-specific directives>
49 > # second database definition & config directives
51 > <database-specific directives>
53 > # subsequent backend & database definitions & config directives
56 A configuration directive may take arguments. If so, they are
57 separated by white space. If an argument contains white space,
58 the argument should be enclosed in double quotes {{EX:"like this"}}. If
59 an argument contains a double quote or a backslash character `{{EX:\}}',
60 the character should be preceded by a backslash character `{{EX:\}}'.
62 The distribution contains an example configuration file that will
63 be installed in the {{F: /usr/local/etc/openldap}} directory.
64 A number of files containing schema definitions (attribute types
65 and object classes) are also provided in the
66 {{F: /usr/local/etc/openldap/schema}} directory.
69 H2: Configuration File Directives
71 This section details commonly used configuration directives. For
72 a complete list, see the {{slapd.conf}}(5) manual page. This section
73 separates the configuration file directives into global,
74 backend-specific and data-specific categories, describing each
75 directive and its default value (if any), and giving an example of
82 Directives described in this section apply to all backends
83 and databases unless specifically overridden in a backend or
84 database definition. Arguments that should be replaced
85 by actual text are shown in brackets {{EX:<>}}.
88 H4: access to <what> [ by <who> <accesslevel> <control> ]+
90 This directive grants access (specified by <accesslevel>) to a
91 set of entries and/or attributes (specified by <what>) by one or
92 more requesters (specified by <who>).
93 See the {{SECT:Access Control}} section of this chapter for a
94 summary of basic usage.
96 More details discussion of this directive can be found in the
97 {{SECT:Advanced Access Control}} chapter.
101 H4: attributetype <{{REF:RFC2252}} Attribute Type Description>
103 This directive defines an attribute type.
104 Please see the {{SECT:Schema Specification}} chapter
105 for information regarding how to use this directive.
107 H4: defaultaccess { none | compare | search | read | write }
109 This directive specifies the default access to grant requesters
110 when no {{EX:access}} directives have been specified. Any given
111 access level implies all lesser access levels (e.g., read access
112 implies search and compare but not write).
114 Note: It is recommend that the {{EX:access}} directive be used
115 to specify access control. See the {{SECT:Access Control}}
116 section of this chapter for information regarding the {{EX:access}}
121 E: defaultaccess read
124 H4: idletimeout <integer>
126 Specify the number of seconds to wait before forcibly closing
127 an idle client connection. An idletimeout of 0, the default,
128 disables this feature.
131 H4: include <filename>
133 This directive specifies that slapd should read additional
134 configuration information from the given file before continuing
135 with the next line of the current file. The included file should
136 follow the normal slapd config file format. The file is commonly
137 used to include files containing schema specifications.
139 Note: You should be careful when using this directive - there is
140 no small limit on the number of nested include directives, and no
141 loop detection is done.
143 H4: loglevel <integer>
145 This directive specifies the level at which debugging statements
146 and operation statistics should be syslogged (currently logged to
147 the {{syslogd}}(8) {{EX:LOG_LOCAL4}} facility). You must have
148 configured OpenLDAP {{EX:--enable-debug}} (the default) for this
149 to work (except for the two statistics levels, which are always
150 enabled). Log levels are additive. To display what numbers
151 correspond to what kind of debugging, invoke slapd with {{EX:-?}}
152 or consult the table below. The possible values for <integer> are:
154 !block table; colaligns="RL"; align=Center; \
155 title="Table 5.1: Debugging Levels"
157 -1 enable all debugging
159 1 trace function calls
160 2 debug packet handling
161 4 heavy trace debugging
162 8 connection management
163 16 print out packets sent and received
164 32 search filter processing
165 64 configuration file processing
166 128 access control list processing
167 256 stats log connections/operations/results
168 512 stats log entries sent
169 1024 print communication with shell backends
170 2048 print entry parsing debugging
177 This will cause lots and lots of debugging information to be
185 H4: objectclass <{{REF:RFC2252}} Object Class Description>
187 This directive defines an object class.
188 Please see the {{SECT:Schema Specification}} chapter for
189 information regarding how to use this directive.
194 This directive specifies the referral to pass back when slapd
195 cannot find a local database to handle a request.
199 > referral ldap://root.openldap.org
201 This will refer non-local queries to the global root LDAP server
202 at the OpenLDAP Project. Smart LDAP clients can re-ask their
203 query at that server, but note that most of these clients are
204 only going to know how to handle simple LDAP URLs that
205 contain a host part and optionally a distinguished name part.
208 H4: sizelimit <integer>
210 This directive specifies the maximum number of entries to return
211 from a search operation.
218 H4: timelimit <integer>
220 This directive specifies the maximum number of seconds (in real
221 time) slapd will spend answering a search request. If a
222 request is not finished in this time, a result indicating an
223 exceeded timelimit will be returned.
230 H3: General Backend Directives
232 Directives in this section apply only to the backend in which
233 they are defined. They are supported by every type of backend.
234 Backend directives apply to all databases instances of the
235 same type and, depending on the directive, may be overridden
236 by database directives.
240 This directive marks the beginning of a backend declaration.
241 {{EX:<type>}} should be one of the
242 supported backend types listed in Table 5.2.
244 !block table; align=Center; coltags="EX,N"; \
245 title="Table 5.2: Database Backends"
247 bdb Berkeley DB transactional backend
248 dnssrv DNS SRV backend
249 ldbm Lightweight DBM backend
250 ldap Lightweight Directory Access Protocol (Proxy) backend
251 meta Meta Directory backend
252 monitor Monitor backend
253 passwd Provides read-only access to {{passwd}}(5)
254 perl Perl Programmable backend
255 shell Shell (extern program) backend
256 sql SQL Programmable backend
257 tcl TCL Programmable backend
264 This marks the beginning of a new {{TERM:BDB}} backend
268 H3: General Database Directives
270 Directives in this section apply only to the database in which
271 they are defined. They are supported by every type of database.
275 This directive marks the beginning of a database instance
277 {{EX:<type>}} should be one of the
278 supported backend types listed in Table 5.2.
284 This marks the beginning of a new {{TERM:BDB}} database instance
288 H4: readonly { on | off }
290 This directive puts the database into "read-only" mode. Any
291 attempts to modify the database will return an "unwilling to
300 > replica host=<hostname>[:<port>]
301 > [bindmethod={ simple | kerberos | sasl }]
304 > [authcid=<identity>]
305 > [authzid=<identity>]
306 > [credentials=<password>]
307 > [srvtab=<filename>]
309 This directive specifies a replication site for this database. The
310 {{EX:host=}} parameter specifies a host and optionally a port where
311 the slave slapd instance can be found. Either a domain name
312 or IP address may be used for <hostname>. If <port> is not
313 given, the standard LDAP port number (389) is used.
315 The {{EX:binddn=}} parameter gives the DN to bind as for updates to
316 the slave slapd. It should be a DN which has read/write
317 access to the slave slapd's database, typically given as a
318 {{EX:rootdn}} in the slave's config file. It must also match the
319 {{EX:updatedn}} directive in the slave slapd's config file. Since DNs are
320 likely to contain embedded spaces, the entire {{EX:"binddn=<DN>"}}
321 string should be enclosed in double quotes.
323 The {{EX:bindmethod}} is {{EX:simple}} or {{EX:kerberos}} or {{EX:sasl}},
324 depending on whether simple password-based authentication or Kerberos
325 authentication or {{TERM:SASL}} authentication is to be used when connecting
328 Simple authentication should not be used unless adequate integrity
329 and privacy protections are in place (e.g. TLS or IPSEC). Simple
330 authentication requires specification of {{EX:binddn}} and
331 {{EX:credentials}} parameters.
333 Kerberos authentication is deprecated in favor of SASL authentication
334 mechanisms, in particular the {{EX:KERBEROS_V4}} and {{EX:GSSAPI}}
335 mechanisms. Kerberos authentication requires {{EX:binddn}} and
336 {{EX:srvtab}} parameters.
338 SASL authentication is generally recommended. SASL authentication
339 requires specification of a mechanism using the {{EX:mech}} parameter.
340 Depending on the mechanism, an authentication identity and/or
341 credentials can be specified using {{EX:authcid}} and {{EX:credentials}}
342 respectively. The {{EX:authzid}} parameter may be used to specify
343 an authorization identity.
345 See the chapter entitled {{SECT:Replication with slurpd}} for more
346 information on how to use this directive.
349 H4: replogfile <filename>
351 This directive specifies the name of the replication log file to
352 which slapd will log changes. The replication log is typically
353 written by slapd and read by slurpd. Normally, this directive is
354 only used if slurpd is being used to replicate the database.
355 However, you can also use it to generate a transaction log, if
356 slurpd is not running. In this case, you will need to periodically
357 truncate the file, since it will grow indefinitely otherwise.
359 See the chapter entitled {{SECT:Replication with slurpd}} for more
360 information on how to use this directive.
365 This directive specifies the DN that is not subject to
366 access control or administrative limit restrictions for
367 operations on this database. The DN need not refer to
368 an entry in the directory. The DN may refer to a SASL
373 > rootdn "cn=Manager,dc=example,dc=com"
377 > rootdn "uid=root,cn=example.com,cn=digest-md5,cn=auth"
380 H4: rootpw <password>
382 This directive specifies a password for the DN given above that
383 will always work, regardless of whether an entry with the given
384 DN exists or has a password.
385 This directive is deprecated in favor of SASL based authentication.
392 H4: suffix <dn suffix>
394 This directive specifies the DN suffix of queries that will be
395 passed to this backend database. Multiple suffix lines can be
396 given, and at least one is required for each database
401 > suffix "dc=example,dc=com"
403 Queries with a DN ending in "dc=example,dc=com"
404 will be passed to this backend.
406 Note: When the backend to pass a query to is selected, slapd
407 looks at the suffix line(s) in each database definition in the
408 order they appear in the file. Thus, if one database suffix is a
409 prefix of another, it must appear after it in the config file.
413 This directive is only applicable in a slave slapd. It specifies
414 the DN allowed to make changes to the replica. This may be the DN
415 {{slurpd}}(8) binds as when making changes to the replica or the DN
416 associated with a SASL identity.
420 > updatedn "cn=Update Daemon,dc=example,dc=com"
424 > updatedn "uid=slurpd,cn=example.com,cn=digest-md5,cn=auth"
426 See the {{SECT:Replication with slurpd}} chapter for more information
427 on how to use this directive.
431 This directive is only applicable in a slave slapd. It
432 specifies the URL to return to clients which submit update
433 requests upon the replica.
434 If specified multiple times, each {{TERM:URL}} is provided.
438 > updateref ldap://master.example.net
441 H3: BDB Database Directives
443 Directives in this category only apply to a BDB database. That is,
444 they must follow a "database bdb" line and come before any
445 subsequent "backend" or "database" line.
447 H4: directory <directory>
449 This directive specifies the directory where the BDB files
450 containing the database and associated indices live.
454 > directory /usr/local/var/openldap-data
457 H3: LDBM Database Directives
459 Directives in this category only apply to a LDBM database. That is,
460 they must follow a "database ldbm" line and come before any
461 subsequent "backend" or "database" line.
463 H4: cachesize <integer>
465 This directive specifies the size in entries of the in-memory
466 cache maintained by the LDBM backend database instance.
473 H4: dbcachesize <integer>
475 This directive specifies the size in bytes of the in-memory cache
476 associated with each open index file. If not supported by the
477 underlying database method, this directive is ignored without
478 comment. Increasing this number uses more memory but can
479 cause a dramatic performance increase, especially during
480 modifies or when building indices.
489 This option, if present, disables database locking.
490 Enabling this option may improve performance at the expense
496 This option causes on-disk database contents to not be immediately
497 synchronized with in memory changes upon change. Enabling this option
498 may improve performance at the expense of data integrity.
501 H4: directory <directory>
503 This directive specifies the directory where the LDBM files
504 containing the database and associated indices live.
508 > directory /usr/local/var/openldap-data
511 H4: index {<attrlist> | default} [pres,eq,approx,sub,none]
513 This directive specifies the indices to maintain for the given
514 attribute. If only an {{EX:<attrlist>}} is given, the default
515 indices are maintained.
519 > index default pres,eq
521 > index cn,sn pres,eq,sub
522 > index objectClass eq
524 The first line sets the default set of indices to maintain to
525 present and equality. The second line causes the default (pres,eq)
526 set of indices to be maintained for the {{EX:uid}} attribute type.
527 The third line causes present, equality, and substring indices to
528 be maintained for {{EX:cn}} and {{EX:sn}} attribute types. The
529 fourth line causes an equality index for the {{EX:objectClass}}
532 By default, no indices are maintained. It is generally advised
533 that minimally an equality index upon objectClass be maintained.
535 > index objectClass eq
541 This directive specifies the file protection mode that newly
542 created database index files should have.
551 Access to slapd entries and attributes is controlled by the
552 access configuration file directive. The general form of an
555 > <access directive> ::= access to <what>
556 > [by <who> <access> <control>]+
557 > <what> ::= * | [ dn[.<dn style>]=<regex>]
558 > [filter=<ldapfilter>] [attrs=<attrlist>]
559 > <dn style> ::= regex | exact | base | one | subtree | children
560 > <attrlist> ::= <attr> | <attr> , <attrlist>
561 > <attr> ::= <attrname> | entry | children
562 > <who> ::= [* | anonymous | users | self |
563 > dn[.<dn style>]=<regex>]
564 > [dnattr=<attrname> ]
565 > [group[/<objectclass>[/<attrname>][.<basic style>]]=<regex> ]
566 > [peername[.<basic style>]=<regex>]
567 > [sockname[.<basic style>]=<regex>]
568 > [domain[.<basic style>]=<regex>]
569 > [sockurl[.<basic style>]=<regex>]
572 > <basic style> ::= regex | exact
573 > <access> ::= [self]{<level>|<priv>}
574 > <level> ::= none | auth | compare | search | read | write
575 > <priv> ::= {=|+|-}{w|r|s|c|x}+
576 > <control> ::= [stop | continue | break]
578 where the <what> part selects the entries and/or attributes to
579 which the access applies, the {{EX:<who>}} part specifies which
580 entities are granted access, and the {{EX:<access>}} part specifies
581 the access granted. Multiple {{EX:<who> <access> <control>}} triplets
582 are supported, allowing many entities to be granted different
583 access to the same set of entries and attributes. Not all of these
584 access control options are described here; for more details see
585 the {{slapd.access}}(5) man page.
588 H3: What to control access to
590 The <what> part of an access specification determines the
591 entries and attributes to which the access control applies.
592 Entries can be selected in two ways: by a regular expression
593 matching the entry's distinguished name:
595 > dn=<regular expression>
597 Note: The DN pattern specified should be "normalized" to the RFC2253
598 restricted DN form. In particular, there should be no extra spaces
599 and commas should be used to separate components. An example
600 normalized DN is "{{EX:cn=Babs Jensen,dc=example,dc=com}}". An
601 example of a non-normalized DN is "{{EX:cn=Babs Jensen; dc=example;
604 Or, entries may be selected by a filter matching some
605 attribute(s) in the entry:
607 > filter=<ldap filter>
609 where <ldap filter> is a string representation of an LDAP
610 search filter, as described in {{REF:RFC2254}}.
612 Attributes within an entry are selected by including a
613 comma-separated list of attribute names in the <what>
616 > attrs=<attribute list>
618 Access to the entry itself must be granted or denied using the
619 special attribute name "{{EX:entry}}". Note that giving access to an
620 attribute is not enough; access to the entry itself through the
621 {{EX:entry}} attribute is also required. The complete examples at
622 the end of this section should help clear things up.
624 Lastly, there is a special entry selector {{EX:"*"}} that is used to
625 select any entry. It is used when no other {{EX:<what>}}
626 selector has been provided. It's equivalent to "{{EX:dn=.*}}"
629 H3: Who to grant access to
631 The <who> part identifies the entity or entities being granted
632 access. Note that access is granted to "entities" not "entries."
633 The following table summarizes entity specifiers:
635 !block table; align=Center; coltags="EX,N"; \
636 title="Table 5.3: Access Entity Specifiers"
638 * All, including anonymous and authenticated users
639 anonymous Anonymous (non-authenticated) users
640 users Authenticated users
641 self User associated with target entry
642 dn=<regex> Users matching regular expression
645 The DN specifier takes a regular expression which is used
646 to match against the "normalized" DN of the current entity.
648 > dn=<regular expression>
650 By "normalized", we mean that all extra spaces have been
651 removed from the entity's DN and commas are used to
652 separate RDN components.
654 Other control factors are also supported.
655 For example, a {{EX:<what>}} can be restricted by a
656 regular expression matching the client's domain name:
658 > domain=<regular expression>
660 or by an entry listed in a DN-valued attribute in the entry to
661 which the access applies:
663 > dnattr=<dn-valued attribute name>
665 The dnattr specification is used to give access to an entry
666 whose DN is listed in an attribute of the entry (e.g., give
667 access to a group entry to whoever is listed as the owner of
671 H3: The access to grant
674 The kind of <access> granted can be one of the following:
677 !block table; colaligns="LRL"; coltags="EX,EX,N"; align=Center; \
678 title="Table 5.4: Access Levels"
679 Level Privileges Description
681 auth =x needed to bind
682 compare =cx needed to compare
683 search =scx needed to apply search filters
684 read =rscx needed to read search results
685 write =wrscx needed to modify/rename
688 Each level implies all lower levels of access. So, for
689 example, granting someone {{EX:write}} access to an entry also
690 grants them {{EX:read}}, {{EX:search}}, {{EX:compare}}, and
691 {{EX:auth}} access. However, one may use the privileges specifier
692 to grant specific permissions.
695 H3: Access Control Evaluation
697 When evaluating whether some requester should be given access to
698 an entry and/or attribute, slapd compares the entry and/or attribute
699 to the {{EX:<what>}} selectors given in the configuration file.
700 For each entry, access controls provided in the database which holds
701 the entry (or the first database if not held in any database) apply
702 first, followed by the global access directives. Within this
703 priority, access directives are examined in the order in which they
704 appear in the config file. Slapd stops with the first {{EX:<what>}}
705 selector that matches the entry and/or attribute. The corresponding
706 access directive is the one slapd will use to evaluate access.
708 Next, slapd compares the entity requesting access to the {{EX:<who>}}
709 selectors within the access directive selected above in the order
710 in which they appear. It stops with the first {{EX:<who>}} selector
711 that matches the requester. This determines the access the entity
712 requesting access has to the entry and/or attribute.
714 Finally, slapd compares the access granted in the selected
715 {{EX:<access>}} clause to the access requested by the client. If
716 it allows greater or equal access, access is granted. Otherwise,
719 The order of evaluation of access directives makes their placement
720 in the configuration file important. If one access directive is
721 more specific than another in terms of the entries it selects, it
722 should appear first in the config file. Similarly, if one {{EX:<who>}}
723 selector is more specific than another it should come first in the
724 access directive. The access control examples given below should
725 help make this clear.
729 H3: Access Control Examples
731 The access control facility described above is quite powerful.
732 This section shows some examples of its use. First, some
735 > access to * by * read
737 This access directive grants read access to everyone.
744 This directive allows users to modify their own entries,
745 allows authenticate, and allows all others to read.
746 Note that only the first {{EX:by <who>}} clause which matches applies.
747 Hence, the anonymous users are granted {{EX:auth}}, not {{EX:read}}.
748 The last clause could just as well have been "{{EX:by users read}}".
750 The following example shows the use of a regular expression
751 to select the entries by DN in two access directives where
752 ordering is significant.
754 > access to dn=".*,dc=example,dc=com"
756 > access to dn=".*,dc=com"
759 Read access is granted to entries under the {{EX:dc=com}}
760 subtree, except for those entries under the {{EX:dc=example,dc=com}}
761 subtree, to which search access is granted. No access is granted to
762 {{EX:dc=com}} as neither access directive matches this DN.
763 If the order of these access directives was reversed, the
764 trailing directive would never be reached, since all
765 {{EX:dc=example,dc=com}} entries are also {{EX:dc=com}} entries.
767 Also note that if no {{EX:access to}} directive matches or
768 no {{EX:by <who>}} clause, {{B:access is denied}}. That is, every
769 {{EX:access to}} directive ends with an implicit {{EX:by * none}}
770 clause and every access list ends with an implicit
771 {{EX:access to * by * none}} directive. Only if no access controls
772 are specified is the {{EX:defaultaccess}} granted.
774 The next example again shows the importance of ordering,
775 both of the access directives and the {{EX:by <who>}} clauses.
776 It also shows the use of an attribute selector to grant access
777 to a specific attribute and various {{EX:<who>}} selectors.
779 > access to dn="(.*,)?dc=example,dc=com" attr=homePhone
781 > by dn="(.*,)?dc=example,dc=com" search
782 > by domain=.*\.example\.com read
783 > access to dn="(.*,)?dc=example,dc=com"
785 > by dn=".*,dc=example,dc=com" search
788 This example applies to entries in the "{{EX:dc=example,dc=com}}"
789 subtree. To all attributes except {{EX:homePhone}}, the entry itself
790 can write them, other {{EX:example.com}} entries can search by them,
791 anybody else has no access (implicit {{EX:by * none}}) excepting for
792 authentication/authorization (which is always done anonymously).
793 The {{EX:homePhone}} attribute is writable by the entry, searchable
794 by other {{EX:example.com}} entries, readable by clients connecting
795 from somewhere in the {{EX:example.com}} domain, and otherwise not
796 readable (implicit {{EX:by * none}}). All other access
797 is denied by the implicit {{EX:access to * by * none}}.
799 Sometimes it is useful to permit a particular DN to add or
800 remove itself from an attribute. For example, if you would like to
801 create a group and allow people to add and remove only
802 their own DN from the member attribute, you could accomplish
803 it with an access directive like this:
805 > access to attr=member,entry
806 > by dnattr=member selfwrite
808 The dnattr {{EX:<who>}} selector says that the access applies to
809 entries listed in the {{EX:member}} attribute. The {{EX:selfwrite}} access
810 selector says that such members can only add or delete their
811 own DN from the attribute, not other values. The addition of
812 the entry attribute is required because access to the entry is
813 required to access any of the entry's attributes.
816 For more details on how to use the {{EX:access}} directive,
817 consult the {{Advanced Access Control}} chapter.
821 H2: Configuration File Example
823 The following is an example configuration file, interspersed
824 with explanatory text. It defines two databases to handle
825 different parts of the {{TERM:X.500}} tree; both are {{TERM:BDB}}
826 database instances. The line numbers shown are provided for
827 reference only and are not included in the actual file. First, the
828 global configuration section:
830 E: 1. # example config file - global configuration section
831 E: 2. include /usr/local/etc/schema/core.schema
832 E: 3. referral ldap://root.openldap.org
833 E: 4. access to * by * read
835 Line 1 is a comment. Line 2 includes another config file
836 which contains {{core}} schema definitions.
837 The {{EX:referral}} directive on line 3
838 means that queries not local to one of the databases defined
839 below will be referred to the LDAP server running on the
840 standard port (389) at the host {{EX:root.openldap.org}}.
842 Line 4 is a global access control. It applies to all
843 entries (after any applicable database-specific access
846 The next section of the configuration file defines a BDB
847 backend that will handle queries for things in the
848 "dc=example,dc=com" portion of the tree. The
849 database is to be replicated to two slave slapds, one on
850 truelies, the other on judgmentday. Indices are to be
851 maintained for several attributes, and the {{EX:userPassword}}
852 attribute is to be protected from unauthorized access.
854 E: 5. # BDB definition for the example.com
856 E: 7. suffix "dc=example,dc=com"
857 E: 8. directory /usr/local/var/openldap-data
858 E: 9. rootdn "cn=Manager,dc=example,dc=com"
860 E: 11. # replication directives
861 E: 12. replogfile /usr/local/var/openldap/slapd.replog
862 E: 13. replica host=slave1.example.com:389
863 E: 14. binddn="cn=Replicator,dc=example,dc=com"
864 E: 15. bindmethod=simple credentials=secret
865 E: 16. replica host=slave2.example.com
866 E: 17. binddn="cn=Replicator,dc=example,dc=com"
867 E: 18. bindmethod=simple credentials=secret
868 E: 19. # indexed attribute definitions
869 E: 20. index uid pres,eq
870 E: 21. index cn,sn,uid pres,eq,approx,sub
871 E: 22. index objectClass eq
872 E: 23. # database access control definitions
873 E: 24. access to attr=userPassword
875 E: 26. by anonymous auth
876 E: 27. by dn="cn=Admin,dc=example,dc=com" write
880 E: 31. by dn="cn=Admin,dc=example,dc=com" write
883 Line 5 is a comment. The start of the database definition is marked
884 by the database keyword on line 6. Line 7 specifies the DN suffix
885 for queries to pass to this database. Line 8 specifies the directory
886 in which the database files will live.
888 Lines 9 and 10 identify the database {{super-user}} entry and associated
889 password. This entry is not subject to access control or size or
890 time limit restrictions.
892 Lines 11 through 18 are for replication. Line 12 specifies the
893 replication log file (where changes to the database are logged -
894 this file is written by slapd and read by slurpd). Lines 13 through
895 15 specify the hostname and port for a replicated host, the DN to
896 bind as when performing updates, the bind method (simple) and the
897 credentials (password) for the binddn. Lines 16 through 18 specify
898 a second replication site. See the {{SECT:Replication with slurpd}}
899 chapter for more information on these directives.
901 Lines 20 through 22 indicate the indices to maintain for various
904 Lines 24 through 32 specify access control for entries in this
905 database. As this is the first database, the controls also apply
906 to entries not held in any database (such as the Root DSE). For
907 all applicable entries, the {{EX:userPassword}} attribute is writable
908 by the entry itself and by the "admin" entry. It may be used for
909 authentication/authorization purposes, but is otherwise not readable.
910 All other attributes are writable by the entry and the "admin"
911 entry, but may be read by all users (authenticated or not).
913 The next section of the example configuration file defines another
914 BDB database. This one handles queries involving the
915 {{EX:dc=example,dc=net}} subtree but is managed by the same entity
916 as the first database. Note that without line 39, the read access
917 would be allowed due to the global access rule at line 4.
919 E: 33. # BDB definition for example.net
921 E: 35. suffix "dc=example,dc=net"
922 E: 36. directory /usr/local/var/openldap-data-net
923 E: 37. rootdn "cn=Manager,dc=example,dc=com"
924 E: 38. index objectClass eq
925 E: 39. access to * by users read