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 three types of configuration
22 information: global, backend specific, 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 a backend and/or database directives, 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 definition (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 {{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 to directives 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. Access
111 levels implies all lesser access levels (e.g., read access
112 implies search and compare but no 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 connections. A 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 H3: General Database Directives
234 Directives in this section only apply to the database in which
235 they are defined. They are supported by every type of database.
237 H4: database <databasetype>
239 This directive marks the beginning of a new database instance
240 definition. <databasetype> should be one of ldbm, shell, or
241 passwd, depending on which backend will serve the
248 This marks the beginning of a new LDBM backend database
252 H4: readonly { on | off }
254 This directive puts the database into "read-only" mode. Any
255 attempts to modify the database will return an "unwilling to
264 > replica host=<hostname>[:<port>]
265 > [bindmethod={ simple | kerberos | sasl }]
268 > [authcid=<identity>]
269 > [authzid=<identity>]
270 > [credentials=<password>]
271 > [srvtab=<filename>]
273 This directive specifies a replication site for this database. The
274 {{EX:host=}} parameter specifies a host and optionally a port where
275 the slave slapd instance can be found. Either a domain name
276 or IP address may be used for <hostname>. If <port> is not
277 given, the standard LDAP port number (389) is used.
279 The {{EX:binddn=}} parameter gives the DN to bind as for updates to
280 the slave slapd. It should be a DN which has read/write
281 access to the slave slapd's database, typically given as a
282 {{EX:rootdn}} in the slave's config file. It must also match the
283 {{EX:updatedn}} directive in the slave slapd's config file. Since DNs are
284 likely to contain embedded spaces, the entire {{EX:"binddn=<DN>"}}
285 string should be enclosed in double quotes.
287 The {{EX:bindmethod}} is {{EX:simple}} or {{EX:kerberos}} or {{EX:sasl}},
288 depending on whether simple password-based authentication or Kerberos
289 authentication or {{TERM:SASL}} authentication is to be used when connecting
292 Simple authentication should not be used unless adequate integrity
293 and privacy protections are in place (e.g. TLS or IPSEC). Simple
294 authentication requires specification of {{EX:binddn}} and
295 {{EX:credentials}} parameters.
297 Kerberos authentication is deprecated in favor of SASL authentication
298 mechanisms, in particular the {EX:KERBEROS_V4}} and {{EX:GSSAPI}}
299 mechanisms. Kerberos authentication requires {{EX:binddn}} and
300 {{EX:srvtab}} parameters.
302 SASL authentication is generally recommended. SASL authentication
303 requires specification of a mechanism using the {{EX:mech}} parameter.
304 Depending on the mechanism, an authentication identity and/or
305 credentials can be specified using {{EX:authcid}} and {{EX:credentials}}
306 respectively. The {{EX:authzid}} parameter may be used to specify
307 an authorization identity.
309 See the {{SECT:Replication}} chapter for more information on how to
313 H4: replogfile <filename>
315 This directive specifies the name of the replication log file to
316 which slapd will log changes. The replication log is typically
317 written by slapd and read by slurpd. Normally, this directive is
318 only used if slurpd is being used to replicate the database.
319 However, you can also use it to generate a transaction log, if
320 slurpd is not running. In this case, you will need to periodically
321 truncate the file, since it will grow indefinitely otherwise.
323 See the {{SECT:Replication}} chapter for more information on how 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 the directory. The DN may refer to a SASL
337 > rootdn "cn=Manager, dc=example, dc=com"
341 > rootdn "uid=root@EXAMPLE.COM"
344 H4: rootpw <password>
346 This directive specifies a password for the DN given above that
347 will always work, regardless of whether an entry with the given
348 DN exists or has a password.
349 This directive is deprecated in favor of SASL based authentication.
356 H4: suffix <dn suffix>
358 This directive specifies the DN suffix of queries that will be
359 passed to this backend database. Multiple suffix lines can be
360 given, and at least one is required for each database
365 > suffix "dc=example, dc=com"
367 Queries with a DN ending in "dc=example, dc=com"
368 will be passed to this backend.
370 Note: when the backend to pass a query to is selected, slapd
371 looks at the suffix line(s) in each database definition in the
372 order they appear in the file. Thus, if one database suffix is a
373 prefix of another, it must appear after it in the config file.
377 This directive is only applicable in a slave slapd. It specifies the
378 DN allowed to make changes to the replica. This may be the
379 the DN slurpd binds as when making changes to the replica or
380 the DN associated with a SASL identity.
384 > updatedn "cn=Update Daemon, dc=example, dc=com"
388 > updatedn "uid=slurpd@EXAMPLE.COM"
390 See the {{SECT:Replication}} chapter for more information on how to
395 This directive is only applicable in a slave slapd. It
396 specifies the URL to return to clients which submit update
397 requests upon the replica.
398 If specified multiple times, each {{TERM:URL}} is provided.
402 > update ldap://master.example.net
405 H3: LDBM Backend-Specific Directives
407 Directives in this category only apply to the LDBM backend
408 database. That is, they must follow a "database ldbm" line and
409 come before any other "database" line.
411 H4: cachesize <integer>
413 This directive specifies the size in entries of the in-memory
414 cache maintained by the LDBM backend database instance.
421 H4: dbcachesize <integer>
423 This directive specifies the size in bytes of the in-memory cache
424 associated with each open index file. If not supported by the
425 underlying database method, this directive is ignored without
426 comment. Increasing this number uses more memory but can
427 cause a dramatic performance increase, especially during
428 modifies or when building indexes.
437 This option, if present, disables database locking.
438 Enabling this option may improve performance at the expense
444 This option causes on-disk database contents not be immediately
445 synchronized with in memory changes upon change. Enabling this option
446 may improve performance at the expense of data security.
449 H4: directory <directory>
451 This directive specifies the directory where the LDBM files
452 containing the database and associated indexes live.
456 > directory /usr/local/var/openldap-ldbm
459 H4: index {<attrlist> | default} [pres,eq,approx,sub,none]
461 This directive specifies the indexes to maintain for the given
462 attribute. If only an {{EX:<attrlist>}} is given, the default
463 indexes are maintained.
468 > index default pres,eq
469 > index objectClass,uid
470 > index cn,sn eq,sub,approx
472 The first line sets the default to indices to maintain to present
473 and equality. The second line causes the default (pres,eq) set
474 of indices to be maintained for {{EX:objectClass}} and {{EX:uid}} attribute
475 types. The third line causes equality, substring, and approximate
476 filters to be maintained for {{EX:cn}} and {{EX:sn}} attribute types.
480 This directive specifies the file protection mode that newly
481 created database index files should have.
489 H3: Other Backend and Databases
491 {{slapd}}(8) supports a number of other backend database types.
493 !block table; align=Center; coltags="EX,N"; \
494 title="Table 5.2: Backend Database Types"
496 passwd Provides read-only access to {{F:/etc/passwd}}
497 shell Shell (extern program) backend
498 sql SQL Programmable backend
501 See {{slapd.conf}}(5) for details.
507 Access to slapd entries and attributes is controlled by the
508 access configuration file directive. The general form of an
511 > <access directive> ::= access to <what>
512 > [by <who> <access> <control>]+
513 > <what> ::= * | [ dn[.<target style>]=<regex>]
514 > [filter=<ldapfilter>] [attrs=<attrlist>]
515 > <target style> ::= regex | base | one | subtree | children
516 > <attrlist> ::= <attr> | <attr> , <attrlist>
517 > <attr> ::= <attrname> | entry | children
518 > <who> ::= [* | anonymous | users | self |
519 > dn[.<subject style>]=<regex>]
520 > [dnattr=<attrname> ]
521 > [group[/<objectclass>[/<attrname>][.<basic style>]]=<regex> ]
522 > [peername[.<basic style>]=<regex>]
523 > [sockname[.<basic style>]=<regex>]
524 > [domain[.<basic style>]=<regex>]
525 > [sockurl[.<basic style>]=<regex>]
528 > <subject style> ::= regex | exact | base | one | subtree | children
529 > <basic style> ::= regex | exact
530 > <access> ::= [self]{<level>|<priv>}
531 > <level> ::= none | auth | compare | search | read | write
532 > <priv> ::= {=|+|-}{w|r|s|c|x}+
533 > <control> ::= [stop | continue | break]
535 where the <what> part selects the entries and/or attributes to
536 which the access applies, the {{EX:<who>}} part specifies which
537 entities are granted access, and the {{EX:<access>}} part specifies
538 the access granted. Multiple {{EX:<who> <access> <control>}} triplets
539 are supported, allowing many entities to be granted different
540 access to the same set of entries and attributes.
543 H3: What to control access to
545 The <what> part of an access specification determines the
546 entries and attributes to which the access control applies.
547 Entries can be selected in two ways: by a regular expression
548 matching the entry's distinguished name:
550 > dn=<regular expression>
552 Note: The DN pattern specified should be "normalized",
553 meaning that there should be no extra spaces, and commas
554 should be used to separate components. An example
555 normalized DN is "cn=Babs Jensen,dc=example,dc=com".
556 An example of a non-normalized DN is
557 "cn=Babs Jensen; dc=example, dc=com".
559 Or, entries may be selected by a filter matching some
560 attribute(s) in the entry:
562 > filter=<ldap filter>
564 where <ldap filter> is a string representation of an LDAP
565 search filter, as described in {{REF:RFC2254}}.
567 Attributes within an entry are selected by including a
568 comma-separated list of attribute names in the <what>
571 > attrs=<attribute list>
573 Access to the entry itself must be granted or denied using the
574 special attribute name "{{EX:entry}}". Note that giving access to an
575 attribute is not enough; access to the entry itself through the
576 {{EX:entry}} attribute is also required. The complete examples at
577 the end of this section should help clear things up.
579 Lastly, there is a special entry selector {{EX:"*"}} is used to
580 select any entry. It is used when no other {{EX:<what>}}
581 selector has been provided. It's equivalent to "{{EX:dn=.*}}"
584 H3: Who to grant access to
586 The <who> part identifies the entity or entities being granted
587 access. Note that access is granted to "entities" not "entries."
588 The follow table summaries entity specifiers:
590 !block table; align=Center; coltags="EX,N"; \
591 title="Table 5.3: Access Entity Specifiers"
593 * All, including anonymous and authenticated users
594 anonymous Anonymous (non-authenticated) users
595 users Authenticated users
596 self User associated with target entry
597 dn=<regex> Users matching regular expression
600 The DN specifier takes a regular expression which is used
601 to match against the "normalized" DN of the current entity.
603 > dn=<regular expression>
605 By "normalized", we mean that all extra spaces have been
606 removed from the entities DN and commas are used to
607 separate RDN components.
609 Other control factors forms are also supported.
610 For example, a {{EX:<what>}} can be restricted by a
611 regular expression matching the client's IP address or domain name:
613 > addr=<regular expression>
614 > domain=<regular expression>
616 or by an entry listed in a DN-valued attribute in the entry to
617 which the access applies:
619 > dnattr=<dn-valued attribute name>
621 The dnattr specification is used to give access to an entry
622 whose DN is listed in an attribute of the entry (e.g., give
623 access to a group entry to whoever is listed as the owner of
627 H3: The access to grant
630 The kind of <access> granted can be one of the following:
633 !block table; colaligns="LRL"; coltags="EX,EX,N"; align=Center; \
634 title="Table 5.4: Access Levels"
635 Level Privledges Description
637 auth =x needed to bind
638 compare =cx needed to compare
639 search =scx needed to apply search filters
640 read =rscx needed to read search results
641 write =wrscx needed to modify/rename
644 Each level implies all lower levels of access. So, for
645 example, granting someone write access to an entry also
646 grants them read, search, compare, and auth access. However,
647 one may use the privledges specify to grant specific permissions.
650 H3: Access Control Evaluation
652 When evaluating whether some requester should be given
653 access to an entry and/or attribute, slapd compares the entry
654 and/or attribute to the {{EX:<what>}} selectors given in the
655 configuration file. Access directives local to the current
656 database are examined first, followed by global access
657 directives. Within this priority, access directives are
658 examined in the order in which they appear in the config file.
659 Slapd stops with the first {{EX:<what>}} selector that matches the
660 entry and/or attribute. The corresponding access directive is
661 the one slapd will use to evaluate access.
663 Next, slapd compares the entity requesting access to the
664 {{EX:<who>}} selectors within the access directive selected above,
665 in the order in which they appear. It stops with the first {{EX:<who>}}
666 selector that matches the requester. This determines the
667 access the entity requesting access has to the entry and/or
670 Finally, slapd compares the access granted in the selected
671 {{EX:<access>}} clause to the access requested by the client. If it
672 allows greater or equal access, access is granted. Otherwise,
675 The order of evaluation of access directives makes their
676 placement in the configuration file important. If one access
677 directive is more specific than another in terms of the entries
678 it selects, it should appear first in the config file. Similarly, if
679 one {{EX:<who>}} selector is more specific than another it should
680 come first in the access directive. The access control
681 examples given below should help make this clear.
685 H3: Access Control Examples
687 The access control facility described above is quite powerful.
688 This section shows some examples of its use. First, some
691 > access to * by * read
693 This access directive grants read access to everyone.
700 This directive allows users to modify their own entries,
701 allows authenticate, and allows authenticated users to read.
702 Note that only the first {{EX:by <who>}} clause which matches applies.
703 Hence, the anonymous users are granted {{EX:auth}}, not {{EX:read}}.
704 The last clause just as well have been "{{EX:by users read}}".
706 The following example shows the use of a regular expression
707 to select the entries by DN in two access directives where
708 ordering is significant.
710 > access to dn=".*,dc=example,dc=com"
712 > access to dn=".*,dc=com"
715 Read access is granted to entries under the {{EX:dc=com}}
716 subtree, except for those entries under the {{EX:dc=example,dc=com}}
717 subtree, to which search access is granted. No access is granted to
718 {{EX:dc=com}} as neither access directive matches this DN.
719 If the order of these access directives was reversed, the
720 trailing directive would never be reached, since all
721 {{EX:dc=example,dc=com}} entries are also {{EX:dc=com}} entries.
723 Also note that if no {{EX:access to}} directive matches or
724 no {{EX:by <who>}} clause, {{B:access is denied}}. That is, every
725 {{EX:access to}} directive ends with a implicit {{EX:by * none}}
726 clause and access list itself ends with {{EX:access to * by * none}}
727 directive. Only if no access controls are specified, is the
728 {{EX:defaultaccess}} granted.
730 The next example again shows the importance of ordering,
731 both of the access directives and the {{EX:by <who>}} clauses.
732 It also shows the use of an attribute selector to grant access
733 to a specific attribute and various {{EX:<who>}} selectors.
735 > access to dn="(.*,)?dc=example,dc=com" attr=homePhone
737 > by dn="(.*,)?dc=example,dc=com" search
738 > by domain=.*\.example\.com read
739 > access to dn="(.*,)?dc=example,dc=com"
741 > by dn=".*,dc=example,dc=com" search
744 This example applies to entries in the "{{EX:dc=example, dc=com}}"
745 subtree. To all attributes except {{EX:homePhone}}, the entry itself
746 can write them, other {{EX:example.com}} entries can search by them,
747 anybody else has no access ((implicit {{EX:by * none}}) excepting for
748 authentication/authorization (which is always done anonymously).
749 The {{EX:homePhone}} attribute is writable by the entry, searchable
750 by other {{EX:example.com}} entries, readable by clients connecting
751 from somewhere in the {{EX:example.com}} domain, and otherwise not
752 readable (implicit {{EX:by * none}}). All other access
753 is denied by the implicit {{EX:access to * by * none}}.
755 Sometimes it is useful to permit a particular DN to add or
756 remove itself from an attribute. For example, if you would like to
757 create a group and allow people to add and remove only
758 their own DN from the member attribute, you could accomplish
759 it with an access directive like this:
761 > access to attr=member,entry
762 > by dnattr=member selfwrite
764 The dnattr {{EX:<who>}} selector says that the access applies to
765 entries listed in the {{EX:member}} attribute. The {{EX:selfwrite}} access
766 selector says that such members can only add or delete their
767 own DN from the attribute, not other values. The addition of
768 the entry attribute is required because access to the entry is
769 required to access any of the entry's attributes.
772 For more details on how to use the {{EX:access}} directive,
773 consult the {{Advanced Access Control}} chapter.
777 H2: Configuration File Example
779 The following is an example configuration file, interspersed
780 with explanatory text. It defines two databases to handle
781 different parts of the {{TERM:X.500}} tree; both are {{TERM:LDBM}}
782 database instances. The line numbers shown are provided for
783 reference only and are not included in the actual file. First, the
784 global configuration section:
786 E: 1. # example config file - global configuration section
787 E: 2. include /usr/local/etc/schema/core.schema
788 E: 3. referral ldap://root.openldap.org
789 E: 4. access to * by * read
791 Line 1 is a comment. Lines 2 include another config file
792 which containing {{core}} schema definitions.
793 The {{EX:referral}} directive on line 3
794 means that queries not local to one of the databases defined
795 below will be referred to the LDAP server running on the
796 standard port (389) at the host {{EX:root.openldap.org}}.
798 Line 4 is a global access control. It is used only if
799 no database access controls match or when the target
800 objects are not under the control of any database (such as
803 The next section of the configuration file defines an LDBM
804 backend that will handle queries for things in the
805 "dc=example,dc=com" portion of the tree. The
806 database is to be replicated to two slave slapds, one on
807 truelies, the other on judgmentday. Indexes are to be
808 maintained for several attributes, and the {{EX:userPassword}}
809 attribute is to be protected from unauthorized access.
811 E: 5. # ldbm definition for the example.com
813 E: 7. suffix "dc=example, dc=com"
814 E: 8. directory /usr/local/var/openldap
815 E: 9. rootdn "cn=Manager, dc=example, dc=com"
817 E: 11. # replication directives
818 E: 12. replogfile /usr/local/var/openldap/slapd.replog
819 E: 13. replica host=slave1.example.com:389
820 E: 14. binddn="cn=Replicator, dc=example, dc=com"
821 E: 15. bindmethod=simple credentials=secret
822 E: 16. replica host=slave2.example.com
823 E: 17. binddn="cn=Replicator, dc=example, dc=com"
824 E: 18. bindmethod=simple credentials=secret
825 E: 19. # indexed attribute definitions
826 E: 20. index uid pres,eq
827 E: 21. index cn,sn,uid pres,eq,approx,sub
828 E: 22. index objectClass eq
829 E: 23. # ldbm access control definitions
830 E: 24. access to attr=userPassword
832 E: 26. by anonymous auth
833 E: 27. by dn="cn=Admin,dc=example,dc=com" write
837 E: 31. by anonymous auth
838 E: 32. by dn="cn=Admin,dc=example,dc=com" write
841 Line 5 is a comment. The start of the database definition is
842 marked by the database keyword on line 6. Line 7 specifies
843 the DN suffix for queries to pass to this database. Line 8
844 specifies the directory in which the database files will live.
846 Lines 9 and 10 identify the database "super user" entry and
847 associated password. This entry is not subject to access
848 control or size or time limit restrictions.
850 Lines 11 through 18 are for replication. Line 11 specifies the
851 replication log file (where changes to the database are logged
852 \- this file is written by slapd and read by slurpd). Lines 12
853 through 14 specify the hostname and port for a replicated
854 host, the DN to bind as when performing updates, the bind
855 method (simple) and the credentials (password) for the
856 binddn. Lines 15 through 18 specify a second replication site.
857 See the {{SECT:Replication with slurpd}} chapter for more
858 information on these directives.
860 Lines 20 through 22 indicate the indexes to maintain for
863 Lines 24 through 33 specify access control for entries in the
864 database. For all entries, the {{EX:userPassword}} attribute is
865 writable by the entry and the "admin" entry, may be used for
866 authentication/authorization purposes, but is otherwise not
867 readable. All other attributes by writable by the entry and
868 the "admin" entry, may be used for authentication/authorization
869 purposes, but may be read by authenticated users.
871 The next section of the example configuration file defines
872 another LDBM database. This one handles queries involving
873 the {{EX:dc=example,dc=net}} subtree. Note that without
874 line 38, the read access would be allowed due to the
875 global access rule at line 4.
877 E: 33. # ldbm definition for example.net
879 E: 35. suffix "dc=example, dc=net"
880 E: 36. directory /usr/local/var/ldbm-example-net
881 E: 37. rootdn "cn=Manager, dc=example, dc=com"
882 E: 38. access to * by users read