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 to configure it
8 for use at your site. All slapd runtime configuration is accomplished through
9 the {{I:slapd.conf}}(5) file, normally installed in the
10 {{EX:/usr/local/etc/openldap}} directory.
12 An alternate configuration file can be specified via a
13 command-line option to slapd or slurpd (see Sections 5 and 8,
14 respectively). This section describes the general format of the config file,
15 followed by a detailed description of each config file option.
19 H2: Configuration File Format
21 The {{EX: slapd.conf}} file consists of a series of global configuration options
22 that apply to slapd as a whole (including all backends), followed by
23 zero or more database backend definitions that contain information
24 specific to a backend instance.
26 Global options can be overridden in a backend (for options that
27 appear more than once, the last appearance in the slapd.conf file is
28 used). Blank lines and comment lines beginning with a `#' character
29 are ignored. If a line begins with white space, it is considered a
30 continuation of the previous line. The general format of slapd.conf is
33 E: # comment - these options apply to every database
34 E: <global config options>
36 E: # first database definition & config options
37 E: database <backend 1 type>
38 E: <config options specific to backend 1>
40 E: # second database definition & config options
41 E: database <backend 2 type>
42 E: <config options specific to backend 2>
44 E: # subsequent database definitions & config options
47 Configuration line arguments are separated by white space. If
48 an argument contains white space, the argument should be
49 enclosed in double quotes "like this". If an argument contains
50 a double quote or a backslash character `\', the character
51 should be preceded by a backslash character `\'.
53 The distribution contains an example configuration file that will
54 be installed in the {{EX: ETCDIR}} directory. Also provided are
55 {{EX: slapd.at.conf}}, which contains many commonly used attribute
56 definitions, and {{EX: slapd.oc.conf}}, which contains many commonly
57 used object class definitions. These files can be included from
58 the slapd configuration file (see below).
62 H2: Configuration File Options
64 This section separates the configuration file options into
65 global and backend-specific categories, describing each
66 option and its default value (if any), and giving an example of
73 Options described in this section apply to all backends,
74 unless specifically overridden in a backend definition. Option
75 arguments that should be replaced by actual text are shown
79 H4: access to <what> [ by <who> <accesslevel> <control> ]+
81 This option grants access (specified by <accesslevel>) to a
82 set of entries and/or attributes (specified by <what>) by one or
83 more requesters (specified by <who>). See Section 5.3 on
84 access control for more details and examples.
87 H4: attribute <name> [<name2>] { bin | ces | cis | tel | dn }
89 This option associates a syntax with an attribute name. By
90 default, an attribute is assumed to have syntax cis. An
91 optional alternate name can be given for an attribute. The
92 possible syntaxes and their meanings are
95 * {{EX: ces}} case exact string (case must match during comparisons)
96 * {{EX: cis}} case ignore string (case is ignored during comparisons)
97 * {{EX: tel}} telephone number string (like cis but blanks and dashes ` '
98 are ignored during comparisons)
99 * {{EX: dn}} distinguished name
102 H4: defaultaccess { none | compare | search | read | write }
104 This option specifies the default access to grant requesters
105 not matched by any other access line (see Section 5.3). Note
106 that an access level implies all lesser access levels (e.g.,
107 write access implies read, search and compare).
111 E: defaultaccess read
113 H4: include <filename>
115 This option specifies that slapd should read additional
116 configuration information from the given file before continuing
117 with the next line of the current file. The included file should
118 follow the normal slapd config file format.
120 Note: You should be careful when using this option - there is
121 no small limit on the number of nested include options, and no
122 loop detection is done.
124 H4: loglevel <integer>
126 This option specifies the level at which debugging statements
127 and operation statistics should be syslogged (currently
128 logged to the syslogd(8) LOG_LOCAL4 facility). You must
129 have compiled slapd with DLDAP_DEBUG for this to work
130 (except for the two stats levels, which are always enabled).
131 Log levels are additive. To display what numbers correspond
132 to what kind of debugging, invoke slapd with the ? flag or
133 consult the table below. The possible values for <integer> are:
135 *1 trace function calls
136 *2 debug packet handling
137 *4 heavy trace debugging
138 *8 connection management
139 *16 print out packets sent and received
140 *32 search filter processing
141 *64 configuration file processing
142 *128 access control list processing
143 *256 stats log connections/operations/results
144 *512 stats log entries sent
145 *1024 print communication with shell backends
146 *2048 print entry parsing debugging
152 This will cause lots and lots of debugging information to be
159 H4: objectclass <name> [ requires <attrs> ] [ allows <attrs> ]
161 This option defines the schema rules for the given object
162 class. Used in conjunction with the schemacheck option. See
163 Section 5.4 for more details.
167 This option specifies the referral to pass back when slapd
168 cannot find a local database to handle a request.
172 E: referral ldap://ldap.openldap.org
174 This will refer non-local queries to the LDAP server at the
175 OpenLDAP Project. Smart LDAP clients can re-ask their
176 query at that server, but note that most of these clients are
177 only going to know how to handle simple LDAP URLs that
178 contain a host part and optionally a distinguished name part.
180 H4: schemacheck { on | off }
182 This option turns schema checking on or off. If schema
183 checking is on, entries added or modified through LDAP operations
184 will be checked to ensure they obey the schema rules implied
185 by their object class(es) as defined by the corresponding objectclass
186 option(s). If schema checking is off this check is not done.
192 H4: sizelimit <integer>
194 This option specifies the maximum number of entries to return
195 from a search operation.
202 H4: srvtab <filename>
204 This option specifies the srvtab file in which slapd can find the
205 kerberos keys necessary for authenticating clients using
206 kerberos. This option is only meaningful if you are using
207 kerberos authentication, which must be enabled at compile
208 time by including the appropriate definitions in the
209 {{EX: Make-common}} file.
213 E: srvtab /etc/srvtab
215 H4: timelimit <integer>
217 This option specifies the maximum number of seconds (in real
218 time) slapd will spend answering a search request. If a
219 request is not finished in this time, a result indicating an
220 exceeded timelimit will be returned.
228 H3: General Backend Options
230 Options in this section only apply to the backend in which
231 they are defined. They are supported by every type of
234 H4: database <databasetype>
236 This option marks the beginning of a new database instance
237 definition. <databasetype> should be one of ldbm, shell, or
238 passwd, depending on which backend will serve the
245 This marks the beginning of a new LDBM backend database
248 H4: lastmod { on | off }
250 This option controls whether slapd will automatically maintain
251 the modifiersName, modifyTimestamp, creatorsName, and
252 createTimestamp attributes for entries.
258 H4: readonly { on | off }
260 This option puts the database into "read-only" mode. Any
261 attempts to modify the database will return an "unwilling to
269 E: replica host=<hostname>[:<port>]
271 E: bindmethod={ simple | kerberos }
272 E: \[credentials=<password>]
273 E: \[srvtab=<filename>]
275 This option specifies a replication site for this database. The
276 {{EX: host=}} parameter specifies a host and optionally a port where
277 the slave slapd instance can be found. Either a domain name
278 or IP address may be used for <hostname>. If <port> is not
279 given, the standard LDAP port number (389) is used.
281 The {{EX: binddn=}} parameter gives the DN to bind as for updates to
282 the slave slapd. It should be a DN which has read/write
283 access to the slave slapd's database, typically given as a
284 "rootdn" in the slave's config file. It must also match the
285 updatedn option in the slave slapd's config file. Since DNs are
286 likely to contain embedded spaces, the entire "{{EX: binddn=<DN>}}"
287 string should be enclosed in quotes.
289 {{EX: bindmethod}} is either simple or kerberos, depending on
290 whether simple password-based authentication or kerberos
291 authentication is to be used when connecting to the slave
292 slapd. Simple authentication requires a valid password be
293 given. Kerberos authentication requires a valid srvtab file.
295 The {{EX: credentials=}} parameter, which is only required if using
296 simple authentication, gives the password for binddn on the
299 The {{EX: srvtab=}} parameter, which is only required if using
300 kerberos, specifies the filename which holds the kerberos key
301 for the slave slapd. If omitted, {{EX: /etc/srvtab}} is used.
303 See Section 10 for more details on replication.
305 H4: replogfile <filename>
307 This option specifies the name of the replication log file to
308 which slapd will log changes. The replication log is typically
309 written by slapd and read by slurpd. Normally, this option is
310 only used if slurpd is being used to replicate the database.
311 However, you can also use it to generate a transaction log, if
312 slurpd is not running. In this case, you will need to periodically
313 truncate the file, since it will grow indefinitely otherwise.
315 See Section 10 for more details on replication.
319 This option specifies the DN of an entry that is not subject to
320 access control or administrative limit restrictions for
321 operations on this database.
325 E: rootdn "cn=Manager, o=OpenLDAP Project, c=US"
327 H4: rootkrbname <kerberosname>
329 This option specifies a kerberos name for the DN given above
330 that will always work, regardless of whether an entry with the
331 given DN exists or has a {{EX: krbName}} attribute. This option is
332 useful when creating a database and also when using slurpd
333 to provide replication service (see Section 10).
337 E: rootkrbname admin@openldap.org
339 H4: rootpw <password>
341 This option specifies a password for the DN given above that
342 will always work, regardless of whether an entry with the given
343 DN exists or has a password. This option is useful when
344 creating a database and also when using slurpd to provide
345 replication service (see Section 10).
351 H4: suffix <dn suffix>
353 This option specifies the DN suffix of queries that will be
354 passed to this backend database. Multiple suffix lines can be
355 given, and at least one is required for each database
360 E: suffix "o=OpenLDAP Project, c=US"
362 Queries with a DN ending in "o=OpenLDAP Project, c=US"
363 will be passed to this backend.
365 Note: when the backend to pass a query to is selected, slapd
366 looks at the suffix line(s) in each database definition in the
367 order they appear in the file. Thus, if one database suffix is a
368 prefix of another, it must appear after it in the config file.
372 This option is only applicable in a slave slapd. It specifies the
373 DN allowed to make changes to the replica (typically, this is
374 the DN slurpd binds as when making changes to the replica).
378 H3: LDBM Backend-Specific Options
380 Options in this category only apply to the LDBM backend
381 database. That is, they must follow a "database ldbm" line and
382 come before any other "database" line.
384 H4: cachesize <integer>
386 This option specifies the size in entries of the in-memory
387 cache maintained by the LDBM backend database instance.
394 H4: dbcachesize <integer>
396 This option specifies the size in bytes of the in-memory cache
397 associated with each open index file. If not supported by the
398 underlying database method, this option is ignored without
399 comment. Increasing this number uses more memory but can
400 cause a dramatic performance increase, especially during
401 modifies or when building indexes.
405 E: dbcachesize 100000
408 H4: directory <directory>
410 This option specifies the directory where the LDBM files
411 containing the database and associated indexes live.
415 E: directory /usr/tmp
418 H4: index {<attrlist> | default} [pres,eq,approx,sub,none]
420 This option specifies the indexes to maintain for the given
421 attribute. If only an <attrlist> is given, all possible indexes are
428 E: index sn,uid eq,sub,approx
430 E: index default none
432 This example causes all indexes to be maintained for the cn
433 attribute; equality, substring, and approximate indexes for the
434 sn and uid attributes; and no indexes for all other attributes.
439 This option specifies the file protection mode that newly
440 created database index files should have.
448 H3: Shell Backend-Specific Options
456 E: compare <pathname>
466 E: abandon <pathname>
468 These options specify the pathname of the command to
469 execute in response to the given LDAP operation. The
470 command given should understand and follow the input/output
471 conventions described in Appendix B.
475 E: search /usr/local/bin/search.sh
477 Note that you need only supply those commands you want the
478 backend to handle. Operations for which a command is not
479 supplied will be refused with an "unwilling to perform" error.
483 H3: Password Backend-Specific Options
485 Options in this category only apply to the PASSWD backend
486 database. That is, they must follow a "database passwd" line
487 and come before any other "database" line.
491 This option specifies an alternate passwd file to use.
499 H3: Tcl Backend-Specific Options
501 H4: scriptpath <pathname>
503 This is the full path to a file containing the tcl command(s) to handle
526 These options specify the name of the proc (function) in the tcl script
527 specified in 'scriptpath' to execute in response to the given LDAP
532 E: search proc_search
534 Note that you need only supply those commands you want the
535 tcl backend to handle. Operations for which a command is not
536 supplied will be refused with an "unwilling to perform" error.
540 This is one of the biggest pluses of using the tcl backend.
541 The realm let's you group several databases to the same interpretor.
542 This basically means they share the same global variables and proc
543 space. So global variables, as well as all the procs are callable
544 between databases. If no tclrealm is specified, it is put into the
551 Access to slapd entries and attributes is controlled by the
552 access configuration file directive. The general form of an
555 E: <access directive> ::= access to <what>
556 E: [ by <who> <access> <control> ]+
557 E: <what> ::= * | [ dn[.<target style>]=<regex> ] [ filter=<ldapfilter> ]
558 E: [ attrs=<attrlist> ]
559 E: <target style> ::= regex | base | one | subtree | children
560 E: <attrlist> ::= <attr> | <attr> , <attrlist>
561 E: <attr> ::= <attrname> | entry | children
562 E: <who> ::= [ * | anonymous | users | self | dn[.<subject style>]=<regex> ]
563 E: [ dnattr=<attrname> ]
564 E: [ group[/<objectclass>[/<attrname>][.<basic style>]]=<regex> ]
565 E: [ peername[.<basic style>]=<regex> ] [ sockname[.<basic style>]=<regex> ]
566 E: [ domain[.<basic style>]=<regex> ] [ sockurl[.<basic style>]=<regex> ]
568 E: [ aci=<attrname> ]
569 E: <subject style> ::= regex | exact | base | one | subtree | children
570 E: <basic style> ::= regex | exact
571 E: <access> ::= [self]{<level>|<priv>}
572 E: <level> ::= none | auth | compare | search | read | write
573 E: <priv> ::= {=|+|-}{w|r|s|c|x}+
574 E: <control> ::= [ stop | continue | break ]
576 where the <what> part selects the entries and/or attributes to
577 which the access applies, the <who> part specifies which
578 entities are granted access, and the <access> part specifies
579 the access granted. Multiple <who> <access> <control> triplets are
580 supported, allowing many entities to be granted different
581 access to the same set of entries and attributes.
584 H3: What to control access to
586 The <what> part of an access specification determines the
587 entries and attributes to which the access control applies.
588 Entries can be selected in two ways: by a regular expression
589 matching the entry's distinguished name:
591 E: dn=<regular expression>
593 Note: The DN pattern specified should be "normalized",
594 meaning that there should be no extra spaces, and commas
595 should be used to separate components. An example
596 normalized DN is "cn=Babs Jensen,o=OpenLDAP Project,c=US".
597 An example of a non-normalized DN is
598 "cn=Babs Jensen; o=OpenLDAP Project, c=US".
600 Or, entries may be selected by a filter matching some
601 attribute(s) in the entry:
603 E: filter=<ldap filter>
605 where <ldap filter> is a string representation of an LDAP
606 search filter, as described in RFC 1588. The special entry
607 selector "*" is used to select any entry, and is a convenient
608 shorthand for the equivalent "dn=.*" selector.
610 Attributes within an entry are selected by including a
611 comma-separated list of attribute names in the <what>
614 E: attrs=<attribute list>
616 Access to the entry itself must be granted or denied using the
617 special attribute name "entry". Note that giving access to an
618 attribute is not enough; access to the entry itself through the
619 "entry" attribute is also required. The complete examples at
620 the end of this section should help clear things up.
624 H2: Who to grant access to
626 The <who> part identifies the entity or entities being granted
627 access. Note that access is granted to "entities" not "entries."
628 Entities can be specified by the special "*" identifier, matching
629 any entry, the keyword "self" matching the entry protected by
630 the access, or by a regular expression matching an entry's
633 E: dn=<regular expression>
635 Note: The DN pattern specified should be "normalized",
636 meaning that there should be no extra spaces, and commas
637 should be used to separate components.
639 Or entities can be specified by a regular expression matching
640 the client's IP address or domain name:
642 E: addr=<regular expression>
643 E: domain=<regular expression>
645 or by an entry listed in a DN-valued attribute in the entry to
646 which the access applies:
648 E: dnattr=<dn-valued attribute name>
650 The dnattr specification is used to give access to an entry
651 whose DN is listed in an attribute of the entry (e.g., give
652 access to a group entry to whoever is listed as the owner of
657 H3: The access to grant
660 The kind of <access> granted can be one of the following:
662 E: none | compare | search | read | write
664 Note that each level implies all lower levels of access. So, for
665 example, granting someone write access to an entry also
666 grants them read, search, and compare access.
670 H3: Access Control Evaluation
672 When evaluating whether some requester should be given
673 access to an entry and/or attribute, slapd compares the entry
674 and/or attribute to the {{EX: <what>}} selectors given in the
675 configuration file. Access directives local to the current
676 database are examined first, followed by global access
677 directives. Within this priority, access directives are
678 examined in the order in which they appear in the config file.
679 Slapd stops with the first {{EX: <what>}} selector that matches the
680 entry and/or attribute. The corresponding access directive is
681 the one slapd will use to evaluate access.
683 Next, slapd compares the entity requesting access to the
684 {{EX: <who>}} selectors within the access directive selected above,
685 in the order in which they appear. It stops with the first {{EX: <who>}}
686 selector that matches the requester. This determines the
687 access the entity requesting access has to the entry and/or
690 Finally, slapd compares the access granted in the selected
691 {{EX: <access>}} clause to the access requested by the client. If it
692 allows greater or equal access, access is granted. Otherwise,
695 The order of evaluation of access directives makes their
696 placement in the configuration file important. If one access
697 directive is more specific than another in terms of the entries
698 it selects, it should appear first in the config file. Similarly, if
699 one {{EX: <who>}} selector is more specific than another it should
700 come first in the access directive. The access control
701 examples given below should help make this clear.
705 H3: Access Control Examples
709 The access control facility described above is quite powerful.
710 This section shows some examples of its use. First, some
713 E: access to * by * read
715 This access directive grants read access to everyone. If it
716 appears alone it is the same as the following defaultaccess
719 E: defaultaccess read
721 The following example shows the use of a regular expression
722 to select the entries by DN in two access directives where
723 ordering is significant.
725 E: access to dn=".*, o=OpenLDAP Project, c=US"
727 E: access to dn=".*, c=US"
730 Read access is granted to entries under the c=US subtree,
731 except for those entries under the "o=OpenLDAP Project,
732 c=US" subtree, to which search access is granted. If the
733 order of these access directives was reversed, the
734 OpenLDAP-specific directive would never be matched, since all
735 OpenLDAP entries are also c=US entries.
737 The next example again shows the importance of ordering,
738 both of the access directives and the "by" clauses. It also
739 shows the use of an attribute selector to grant access to a
740 specific attribute and various <who> selectors.
742 E:access to dn=".*, o=OpenLDAP Project, c=US" attr=homePhone
744 E: by dn=".*, o=OpenLDAP Project, c=US" search
745 E: by domain=.*\.openldap\.org read
747 E:access to dn=".*, o=OpenLDAP Project, c=US"
749 E: by dn=".*, o=OpenLDAP Project, c=US" search
752 This example applies to entries in the "o=OpenLDAP Project, c=US"
753 subtree. To all attributes except homePhone, the entry itself
754 can write them, other OpenLDAP entries can search by them,
755 anybody else has no access. The homePhone attribute is
756 writable by the entry, searchable by other OpenLDAP entries,
757 readable by clients connecting from somewhere in the
758 OpenLDAP.org domain, and comparable by everybody else.
760 Sometimes it is useful to permit a particular DN to add or
761 remove itself from an attribute. For example, if you would like to
762 create a group and allow people too add and remove only
763 their own DN from the member attribute, you could accomplish
764 it with an access directive like this:
766 E: access to attr=member,entry
767 E: by dnattr=member selfwrite
769 The dnattr {{EX: <who>}} selector says that the access applies to
770 entries listed in the member attribute. The selfwrite access
771 selector says that such members can only add or delete their
772 own DN from the attribute, not other values. The addition of
773 the entry attribute is required because access to the entry is
774 required to access any of the entry's attributes.
776 Note that the attr=member construct in the {{EX: <what>}} clause is a
777 shorthand for the clause "dn=* attr=member" (i.e., it matches
778 the member attribute in all entries).
782 H2: Schema Enforcement
786 The {{EX: objectclass}} and schemacheck configuration file options
787 can be used to enforce schema rules on entries in the
788 directory. The schema rules are defined by one or more
789 objectclass lines, and enforcement is turned on or off via the
790 schemacheck option. The format of an {{EX: objectclass}} line is:
792 E: objectclass <name>
793 E: [ requires <attrs> ]
794 E: [ allows <attrs> ]
796 This option defines the schema rules for the object class
797 given by {{EX: <name>}}. Schema rules consist of the attributes the
798 entry is required to have (given by the requires {{EX: <attrs>}}
799 clause) and those attributes that it may optionally have (given
800 by the allows {{EX: <attrs>}} clause). In both clauses, {{EX: <attrs>}} is a
801 comma-separated list of attribute names.
803 Note that object class inheritance (that is, defining one object
804 class in terms of another) is not supported directly. All of an
805 object class's required and allowed attributes must be listed
806 in the objectclass definition.
808 For example, to define an objectclass called myPerson, you
809 might include a definition like this:
811 E: objectclass myperson
812 E: requires cn, sn, objectclass
813 E: allows mail, phone, fax
815 To then enforce this rule (i.e., to make sure an entry with an
816 objectclass of myperson contains the cn, sn and objectclass
817 attributes, and that it contains no other attributes besides
818 mail, phone, and fax), turn on schema checking with a line like
825 H2: Configuration File Example
829 The following is an example configuration file, interspersed
830 with explanatory text. It defines two databases to handle
831 different parts of the X.500 tree; both are LDBM database
832 instances. The line numbers shown are provided for
833 reference only and are not included in the actual file. First, the
834 global configuration section:
836 E: 1. # example config file - global configuration section
837 E: 2. include /usr/local/etc/slapd.at.conf
838 E: 3. include /usr/local/etc/slapd.oc.conf
840 E: 5. referral ldap://ldap.openldap.org
842 Line 1 is a comment. Lines 2 and 3 include other config files
843 containing attribute and object class definitions, respectively.
844 Line 4 turns on schema checking. The {{EX: referral}} option on line 5
845 means that queries not local to one of the databases defined
846 below will be referred to the LDAP server running on the
847 standard port (389) at the host {{EX: ldap.openldap.org}}.
849 The next section of the configuration file defines an LDBM
850 backend that will handle queries for things in the
851 "o=OpenLDAP Project, c=US" portion of the tree. The
852 database is to be replicated to two slave slapds, one on
853 truelies, the other on judgmentday. Indexes are to be
854 maintained for several attributes, and the {{EX: userPassword}}
855 attribute is to be protected from unauthorized access.
857 E: 1. # ldbm definition for the U-M database
859 E: 3. suffix "o=OpenLDAP Project, c=US"
860 E: 4. directory /usr/local/var/openldap
861 E: 6. rootdn "cn=Manager, o=OpenLDAP Project, c=US"
863 E: 8. replogfile /usr/local/var/openldap/slapd.replog
864 E: 9. replica host=slave1.openldap.org:389
865 E: 10. binddn="cn=Replicator, o=OpenLDAP Project, c=US"
866 E: 11. bindmethod=simple credentials=secret
867 E: 12.replica host=slave2.openldap.org
868 E: 13. binddn="cn=Replicator, o=OpenLDAP Project, c=US"
869 E: 14. bindmethod=kerberos
870 E: 15. srvtab=/etc/srvtab.slave2
871 E: 16.# ldbm indexed attribute definitions
872 E: 17.index cn,sn,uid pres,eq,approx,sub
873 E: 18.index objectclass pres,eq
874 E: 19.index default none
875 E: 20.# ldbm access control definitions
876 E: 21.defaultaccess read
877 E: 22.access to attr=userpassword
879 E: 24. by dn="cn=Admin, o=OpenLDAP Project, c=US" write
882 Line 1 is a comment. The start of the database definition is
883 marked by the database keyword on line 2. Line 3 specifies
884 the DN suffix for queries to pass to this database. Line 4
885 specifies the directory in which the database files will live
887 Lines 6 and 7 identify the database "super user" entry and
888 associated password. This entry is not subject to access
889 control or size or time limit restrictions.
891 Lines 8 through 15 are for replication. Line 8 specifies the
892 replication log file (where changes to the database are logged
893 \- this file is written by slapd and read by slurpd). Lines 9
894 through 11 specify the hostname and port for a replicated
895 host, the DN to bind as when performing updates, the bind
896 method (simple) and the credentials (password) for the
897 binddn. Lines 12 through 15 specify a second replication site,
898 using kerberos instead of simple authentication. See Section
899 10 on slurpd for more information on these options.
901 Lines 16 through 19 indicate the indexes to maintain for
902 various attributes. The default is not to maintain any indexes
905 Lines 20 through 25 specify access control for entries in the
906 database. For all entries, the {{EX: userPassword}} attribute is
907 writable by the entry and the "admin" entry, comparable by
908 everyone else. All other attributes allow read access by
909 default (line 21). Note that the special "entry" attribute is not
910 required in the access directive beginning on line 22. This is
911 because the default access is read.
913 The next section of the example configuration file defines
914 another LDBM database. This one handles queries involving
915 the "o="Babs, Inc.", c=US" subtree.
917 E: 1. # ldbm definition for Babs, Inc. database
919 E: 3. suffix "o=\"Babs, Inc.\", c=US"
920 E: 4. directory /usr/local/ldbm-babs
921 E: 5. rootdn "cn=Babs, o=\"Babs, Inc.\", c=US"
924 Note the use of `\' to escape the quotes necessary in the
925 distinguished names given on lines 3 and 5. By default, all
926 indexes are maintained for every attribute in an entry.