2 # Copyright 1999, The OpenLDAP Foundation, All Rights Reserved.
3 # COPYING RESTRICTIONS APPLY, see COPYRIGHT.
4 H1: The {{I: slapd}} Configuration File
6 Once the software has been built and installed, you are ready to configure it
7 for use at your site. All slapd runtime configuration is accomplished through
8 the {{EX: slapd.conf}} file, installed in the {{EX: ETCDIR}}
9 directory you specified in the {{EX: Make-common}} file.
11 An alternate configuration file can be specified via a
12 command-line option to slapd or slurpd (see Sections 5 and 8,
13 respectively). This section describes the general format of the config file,
14 followed by a detailed description of each config file option.
18 H2: Configuration File Format
20 The {{EX: slapd.conf}} file consists of a series of global configuration options
21 that apply to slapd as a whole (including all backends), followed by
22 zero or more database backend definitions that contain information
23 specific to a backend instance.
25 Global options can be overridden in a backend (for options that
26 appear more than once, the last appearance in the slapd.conf file is
27 used). Blank lines and comment lines beginning with a `#' character
28 are ignored. If a line begins with white space, it is considered a
29 continuation of the previous line. The general format of slapd.conf is
32 E: # comment - these options apply to every database
33 E: <global config options>
34 E: # first database definition & config options
35 E: database <backend 1 type>
36 E: <config options specific to backend 1>
37 E: # second database definition & config options
38 E: database <backend 2 type>
39 E: <config options specific to backend 2>
40 E: # subsequent database definitions & config options
43 Configuration line arguments are separated by white space. If
44 an argument contains white space, the argument should be
45 enclosed in double quotes "like this". If an argument contains
46 a double quote or a backslash character `\', the character
47 should be preceded by a backslash character `\'.
49 The distribution contains an example configuration file that will
50 be installed in the {{EX: ETCDIR}} directory. Also provided are
51 {{EX: slapd.at.conf}}, which contains many commonly used attribute
52 definitions, and {{EX: slapd.oc.conf}}, which contains many commonly
53 used object class definitions. These files can be included from
54 the slapd configuration file (see below).
58 H2: Configuration File Options
60 This section separates the configuration file options into
61 global and backend-specific categories, describing each
62 option and its default value (if any), and giving an example of
69 Options described in this section apply to all backends,
70 unless specifically overridden in a backend definition. Option
71 arguments that should be replaced by actual text are shown
75 H4: access to <what> [ by <who> <accesslevel> <control> ]+
77 This option grants access (specified by <accesslevel>) to a
78 set of entries and/or attributes (specified by <what>) by one or
79 more requesters (specified by <who>). See Section 5.3 on
80 access control for more details and examples.
83 H4: attribute <name> [<name2>] { bin | ces | cis | tel | dn }
85 This option associates a syntax with an attribute name. By
86 default, an attribute is assumed to have syntax cis. An
87 optional alternate name can be given for an attribute. The
88 possible syntaxes and their meanings are
91 * {{EX: ces}} case exact string (case must match during comparisons)
92 * {{EX: cis}} case ignore string (case is ignored during comparisons)
93 * {{EX: tel}} telephone number string (like cis but blanks and dashes ` '
94 are ignored during comparisons)
95 * {{EX: dn}} distinguished name
98 H4: defaultaccess { none | compare | search | read | write }
100 This option specifies the default access to grant requesters
101 not matched by any other access line (see Section 5.3). Note
102 that an access level implies all lesser access levels (e.g.,
103 write access implies read, search and compare).
107 E: defaultaccess read
109 H4: include <filename>
111 This option specifies that slapd should read additional
112 configuration information from the given file before continuing
113 with the next line of the current file. The included file should
114 follow the normal slapd config file format.
116 Note: You should be careful when using this option - there is
117 no small limit on the number of nested include options, and no
118 loop detection is done.
120 H4: loglevel <integer>
122 This option specifies the level at which debugging statements
123 and operation statistics should be syslogged (currently
124 logged to the syslogd(8) LOG_LOCAL4 facility). You must
125 have compiled slapd with DLDAP_DEBUG for this to work
126 (except for the two stats levels, which are always enabled).
127 Log levels are additive. To display what numbers correspond
128 to what kind of debugging, invoke slapd with the ? flag or
129 consult the table below. The possible values for <integer> are:
131 *1 trace function calls
132 *2 debug packet handling
133 *4 heavy trace debugging
134 *8 connection management
135 *16 print out packets sent and received
136 *32 search filter processing
137 *64 configuration file processing
138 *128 access control list processing
139 *256 stats log connections/operations/results
140 *512 stats log entries sent
141 *1024 print communication with shell backends
142 *2048 print entry parsing debugging
148 This will cause lots and lots of debugging information to be
155 H4: objectclass <name> [ requires <attrs> ] [ allows <attrs> ]
157 This option defines the schema rules for the given object
158 class. Used in conjunction with the schemacheck option. See
159 Section 5.4 for more details.
163 This option specifies the referral to pass back when slapd
164 cannot find a local database to handle a request.
168 E: referral ldap://ldap.openldap.org
170 This will refer non-local queries to the LDAP server at the
171 OpenLDAP Project. Smart LDAP clients can re-ask their
172 query at that server, but note that most of these clients are
173 only going to know how to handle simple LDAP URLs that
174 contain a host part and optionally a distinguished name part.
176 H4: schemacheck { on | off }
178 This option turns schema checking on or off. If schema
179 checking is on, entries added or modified through LDAP operations
180 will be checked to ensure they obey the schema rules implied
181 by their object class(es) as defined by the corresponding objectclass
182 option(s). If schema checking is off this check is not done.
188 H4: sizelimit <integer>
190 This option specifies the maximum number of entries to return
191 from a search operation.
198 H4: srvtab <filename>
200 This option specifies the srvtab file in which slapd can find the
201 kerberos keys necessary for authenticating clients using
202 kerberos. This option is only meaningful if you are using
203 kerberos authentication, which must be enabled at compile
204 time by including the appropriate definitions in the
205 {{EX: Make-common}} file.
209 E: srvtab /etc/srvtab
211 H4: timelimit <integer>
213 This option specifies the maximum number of seconds (in real
214 time) slapd will spend answering a search request. If a
215 request is not finished in this time, a result indicating an
216 exceeded timelimit will be returned.
224 H3: General Backend Options
226 Options in this section only apply to the backend in which
227 they are defined. They are supported by every type of
230 H4: database <databasetype>
232 This option marks the beginning of a new database instance
233 definition. <databasetype> should be one of ldbm, shell, or
234 passwd, depending on which backend will serve the
241 This marks the beginning of a new LDBM backend database
244 H4: lastmod { on | off }
246 This option controls whether slapd will automatically maintain
247 the modifiersName, modifyTimestamp, creatorsName, and
248 createTimestamp attributes for entries.
254 H4: readonly { on | off }
256 This option puts the database into "read-only" mode. Any
257 attempts to modify the database will return an "unwilling to
265 E: replica host=<hostname>[:<port>]
267 E: bindmethod={ simple | kerberos }
268 E: \[credentials=<password>]
269 E: \[srvtab=<filename>]
271 This option specifies a replication site for this database. The
272 {{EX: host=}} parameter specifies a host and optionally a port where
273 the slave slapd instance can be found. Either a domain name
274 or IP address may be used for <hostname>. If <port> is not
275 given, the standard LDAP port number (389) is used.
277 The {{EX: binddn=}} parameter gives the DN to bind as for updates to
278 the slave slapd. It should be a DN which has read/write
279 access to the slave slapd's database, typically given as a
280 "rootdn" in the slave's config file. It must also match the
281 updatedn option in the slave slapd's config file. Since DNs are
282 likely to contain embedded spaces, the entire "{{EX: binddn=<DN>}}"
283 string should be enclosed in quotes.
285 {{EX: bindmethod}} is either simple or kerberos, depending on
286 whether simple password-based authentication or kerberos
287 authentication is to be used when connecting to the slave
288 slapd. Simple authentication requires a valid password be
289 given. Kerberos authentication requires a valid srvtab file.
291 The {{EX: credentials=}} parameter, which is only required if using
292 simple authentication, gives the password for binddn on the
295 The {{EX: srvtab=}} parameter, which is only required if using
296 kerberos, specifies the filename which holds the kerberos key
297 for the slave slapd. If omitted, {{EX: /etc/srvtab}} is used.
299 See Section 10 for more details on replication.
301 H4: replogfile <filename>
303 This option specifies the name of the replication log file to
304 which slapd will log changes. The replication log is typically
305 written by slapd and read by slurpd. Normally, this option is
306 only used if slurpd is being used to replicate the database.
307 However, you can also use it to generate a transaction log, if
308 slurpd is not running. In this case, you will need to periodically
309 truncate the file, since it will grow indefinitely otherwise.
311 See Section 10 for more details on replication.
315 This option specifies the DN of an entry that is not subject to
316 access control or administrative limit restrictions for
317 operations on this database.
321 E: rootdn "cn=Manager, o=OpenLDAP Project, c=US"
323 H4: rootkrbname <kerberosname>
325 This option specifies a kerberos name for the DN given above
326 that will always work, regardless of whether an entry with the
327 given DN exists or has a {{EX: krbName}} attribute. This option is
328 useful when creating a database and also when using slurpd
329 to provide replication service (see Section 10).
333 E: rootkrbname admin@openldap.org
335 H4: rootpw <password>
337 This option specifies a password for the DN given above that
338 will always work, regardless of whether an entry with the given
339 DN exists or has a password. This option is useful when
340 creating a database and also when using slurpd to provide
341 replication service (see Section 10).
347 H4: suffix <dn suffix>
349 This option specifies the DN suffix of queries that will be
350 passed to this backend database. Multiple suffix lines can be
351 given, and at least one is required for each database
356 E: suffix "o=OpenLDAP Project, c=US"
358 Queries with a DN ending in "o=OpenLDAP Project, c=US"
359 will be passed to this backend.
361 Note: when the backend to pass a query to is selected, slapd
362 looks at the suffix line(s) in each database definition in the
363 order they appear in the file. Thus, if one database suffix is a
364 prefix of another, it must appear after it in the config file.
368 This option is only applicable in a slave slapd. It specifies the
369 DN allowed to make changes to the replica (typically, this is
370 the DN slurpd binds as when making changes to the replica).
374 H3: LDBM Backend-Specific Options
376 Options in this category only apply to the LDBM backend
377 database. That is, they must follow a "database ldbm" line and
378 come before any other "database" line.
380 H4: cachesize <integer>
382 This option specifies the size in entries of the in-memory
383 cache maintained by the LDBM backend database instance.
390 H4: dbcachesize <integer>
392 This option specifies the size in bytes of the in-memory cache
393 associated with each open index file. If not supported by the
394 underlying database method, this option is ignored without
395 comment. Increasing this number uses more memory but can
396 cause a dramatic performance increase, especially during
397 modifies or when building indexes.
401 E: dbcachesize 100000
404 H4: directory <directory>
406 This option specifies the directory where the LDBM files
407 containing the database and associated indexes live.
411 E: directory /usr/tmp
414 H4: index {<attrlist> | default} [pres,eq,approx,sub,none]
416 This option specifies the indexes to maintain for the given
417 attribute. If only an <attrlist> is given, all possible indexes are
424 E: index sn,uid eq,sub,approx
426 E: index default none
428 This example causes all indexes to be maintained for the cn
429 attribute; equality, substring, and approximate indexes for the
430 sn and uid attributes; and no indexes for all other attributes.
435 This option specifies the file protection mode that newly
436 created database index files should have.
444 H3: Shell Backend-Specific Options
452 E: compare <pathname>
462 E: abandon <pathname>
464 These options specify the pathname of the command to
465 execute in response to the given LDAP operation. The
466 command given should understand and follow the input/output
467 conventions described in Appendix B.
471 E: search /usr/local/bin/search.sh
473 Note that you need only supply those commands you want the
474 backend to handle. Operations for which a command is not
475 supplied will be refused with an "unwilling to perform" error.
479 H3: Password Backend-Specific Options
481 Options in this category only apply to the PASSWD backend
482 database. That is, they must follow a "database passwd" line
483 and come before any other "database" line.
487 This option specifies an alternate passwd file to use.
495 H3: Tcl Backend-Specific Options
497 H4: scriptpath <pathname>
499 This is the full path to a file containing the tcl command(s) to handle
522 These options specify the name of the proc (function) in the tcl script
523 specified in 'scriptpath' to execute in response to the given LDAP
528 E: search proc_search
530 Note that you need only supply those commands you want the
531 tcl backend to handle. Operations for which a command is not
532 supplied will be refused with an "unwilling to perform" error.
536 This is one of the biggest pluses of using the tcl backend.
537 The realm let's you group several databases to the same interpretor.
538 This basically means they share the same global variables and proc
539 space. So global variables, as well as all the procs are callable
540 between databases. If no tclrealm is specified, it is put into the
547 Access to slapd entries and attributes is controlled by the
548 access configuration file directive. The general form of an
551 E: <access directive> ::= access to <what>
552 E: [ by <who> <access> <control> ]+
553 E: <what> ::= * | [ dn[.<target style>]=<regex> ] [ filter=<ldapfilter> ]
554 E: [ attrs=<attrlist> ]
555 E: <target style> ::= regex | base | one | subtree | children
556 E: <attrlist> ::= <attr> | <attr> , <attrlist>
557 E: <attr> ::= <attrname> | entry | children
558 E: <who> ::= [ * | anonymous | users | self | dn[.<subject style>]=<regex> ]
559 E: [ dnattr=<attrname> ]
560 E: [ group[/<objectclass>[/<attrname>][.<basic style>]]=<regex> ]
561 E: [ peername[.<basic style>]=<regex> ] [ sockname[.<basic style>]=<regex> ]
562 E: [ domain[.<basic style>]=<regex> ] [ sockurl[.<basic style>]=<regex> ]
564 E: [ aci=<attrname> ]
565 E: <subject style> ::= regex | exact | base | one | subtree | children
566 E: <basic style> ::= regex | exact
567 E: <access> ::= [self]{<level>|<priv>}
568 E: <level> ::= none | auth | compare | search | read | write
569 E: <priv> ::= {=|+|-}{w|r|s|c|x}+
570 E: <control> ::= [ stop | continue | break ]
572 where the <what> part selects the entries and/or attributes to
573 which the access applies, the <who> part specifies which
574 entities are granted access, and the <access> part specifies
575 the access granted. Multiple <who> <access> <control> triplets are
576 supported, allowing many entities to be granted different
577 access to the same set of entries and attributes.
580 H3: What to control access to
582 The <what> part of an access specification determines the
583 entries and attributes to which the access control applies.
584 Entries can be selected in two ways: by a regular expression
585 matching the entry's distinguished name:
587 E: dn=<regular expression>
589 Note: The DN pattern specified should be "normalized",
590 meaning that there should be no extra spaces, and commas
591 should be used to separate components. An example
592 normalized DN is "cn=Babs Jensen,o=OpenLDAP Project,c=US".
593 An example of a non-normalized DN is
594 "cn=Babs Jensen; o=OpenLDAP Project, c=US".
596 Or, entries may be selected by a filter matching some
597 attribute(s) in the entry:
599 E: filter=<ldap filter>
601 where <ldap filter> is a string representation of an LDAP
602 search filter, as described in RFC 1588. The special entry
603 selector "*" is used to select any entry, and is a convenient
604 shorthand for the equivalent "dn=.*" selector.
606 Attributes within an entry are selected by including a
607 comma-separated list of attribute names in the <what>
610 E: attrs=<attribute list>
612 Access to the entry itself must be granted or denied using the
613 special attribute name "entry". Note that giving access to an
614 attribute is not enough; access to the entry itself through the
615 "entry" attribute is also required. The complete examples at
616 the end of this section should help clear things up.
620 H2: Who to grant access to
622 The <who> part identifies the entity or entities being granted
623 access. Note that access is granted to "entities" not "entries."
624 Entities can be specified by the special "*" identifier, matching
625 any entry, the keyword "self" matching the entry protected by
626 the access, or by a regular expression matching an entry's
629 E: dn=<regular expression>
631 Note: The DN pattern specified should be "normalized",
632 meaning that there should be no extra spaces, and commas
633 should be used to separate components.
635 Or entities can be specified by a regular expression matching
636 the client's IP address or domain name:
638 E: addr=<regular expression>
639 E: domain=<regular expression>
641 or by an entry listed in a DN-valued attribute in the entry to
642 which the access applies:
644 E: dnattr=<dn-valued attribute name>
646 The dnattr specification is used to give access to an entry
647 whose DN is listed in an attribute of the entry (e.g., give
648 access to a group entry to whoever is listed as the owner of
653 H3: The access to grant
656 The kind of <access> granted can be one of the following:
658 E: none | compare | search | read | write
660 Note that each level implies all lower levels of access. So, for
661 example, granting someone write access to an entry also
662 grants them read, search, and compare access.
666 H3: Access Control Evaluation
668 When evaluating whether some requester should be given
669 access to an entry and/or attribute, slapd compares the entry
670 and/or attribute to the {{EX: <what>}} selectors given in the
671 configuration file. Access directives local to the current
672 database are examined first, followed by global access
673 directives. Within this priority, access directives are
674 examined in the order in which they appear in the config file.
675 Slapd stops with the first {{EX: <what>}} selector that matches the
676 entry and/or attribute. The corresponding access directive is
677 the one slapd will use to evaluate access.
679 Next, slapd compares the entity requesting access to the
680 {{EX: <who>}} selectors within the access directive selected above,
681 in the order in which they appear. It stops with the first {{EX: <who>}}
682 selector that matches the requester. This determines the
683 access the entity requesting access has to the entry and/or
686 Finally, slapd compares the access granted in the selected
687 {{EX: <access>}} clause to the access requested by the client. If it
688 allows greater or equal access, access is granted. Otherwise,
691 The order of evaluation of access directives makes their
692 placement in the configuration file important. If one access
693 directive is more specific than another in terms of the entries
694 it selects, it should appear first in the config file. Similarly, if
695 one {{EX: <who>}} selector is more specific than another it should
696 come first in the access directive. The access control
697 examples given below should help make this clear.
701 H3: Access Control Examples
705 The access control facility described above is quite powerful.
706 This section shows some examples of its use. First, some
709 E: access to * by * read
711 This access directive grants read access to everyone. If it
712 appears alone it is the same as the following defaultaccess
715 E: defaultaccess read
717 The following example shows the use of a regular expression
718 to select the entries by DN in two access directives where
719 ordering is significant.
721 E: access to dn=".*, o=OpenLDAP Project, c=US"
723 E: access to dn=".*, c=US"
726 Read access is granted to entries under the c=US subtree,
727 except for those entries under the "o=OpenLDAP Project,
728 c=US" subtree, to which search access is granted. If the
729 order of these access directives was reversed, the
730 OpenLDAP-specific directive would never be matched, since all
731 OpenLDAP entries are also c=US entries.
733 The next example again shows the importance of ordering,
734 both of the access directives and the "by" clauses. It also
735 shows the use of an attribute selector to grant access to a
736 specific attribute and various <who> selectors.
738 E:access to dn=".*, o=OpenLDAP Project, c=US" attr=homePhone
740 E: by dn=".*, o=OpenLDAP Project, c=US" search
741 E: by domain=.*\.openldap\.org read
743 E:access to dn=".*, o=OpenLDAP Project, c=US"
745 E: by dn=".*, o=OpenLDAP Project, c=US" search
748 This example applies to entries in the "o=OpenLDAP Project, c=US"
749 subtree. To all attributes except homePhone, the entry itself
750 can write them, other OpenLDAP entries can search by them,
751 anybody else has no access. The homePhone attribute is
752 writable by the entry, searchable by other OpenLDAP entries,
753 readable by clients connecting from somewhere in the
754 OpenLDAP.org domain, and comparable by everybody else.
756 Sometimes it is useful to permit a particular DN to add or
757 remove itself from an attribute. For example, if you would like to
758 create a group and allow people too add and remove only
759 their own DN from the member attribute, you could accomplish
760 it with an access directive like this:
762 E: access to attr=member,entry
763 E: by dnattr=member selfwrite
765 The dnattr {{EX: <who>}} selector says that the access applies to
766 entries listed in the member attribute. The selfwrite access
767 selector says that such members can only add or delete their
768 own DN from the attribute, not other values. The addition of
769 the entry attribute is required because access to the entry is
770 required to access any of the entry's attributes.
772 Note that the attr=member construct in the {{EX: <what>}} clause is a
773 shorthand for the clause "dn=* attr=member" (i.e., it matches
774 the member attribute in all entries).
778 H2: Schema Enforcement
782 The {{EX: objectclass}} and schemacheck configuration file options
783 can be used to enforce schema rules on entries in the
784 directory. The schema rules are defined by one or more
785 objectclass lines, and enforcement is turned on or off via the
786 schemacheck option. The format of an {{EX: objectclass}} line is:
788 E: objectclass <name>
789 E: [ requires <attrs> ]
790 E: [ allows <attrs> ]
792 This option defines the schema rules for the object class
793 given by {{EX: <name>}}. Schema rules consist of the attributes the
794 entry is required to have (given by the requires {{EX: <attrs>}}
795 clause) and those attributes that it may optionally have (given
796 by the allows {{EX: <attrs>}} clause). In both clauses, {{EX: <attrs>}} is a
797 comma-separated list of attribute names.
799 Note that object class inheritance (that is, defining one object
800 class in terms of another) is not supported directly. All of an
801 object class's required and allowed attributes must be listed
802 in the objectclass definition.
804 For example, to define an objectclass called myPerson, you
805 might include a definition like this:
807 E: objectclass myperson
808 E: requires cn, sn, objectclass
809 E: allows mail, phone, fax
811 To then enforce this rule (i.e., to make sure an entry with an
812 objectclass of myperson contains the cn, sn and objectclass
813 attributes, and that it contains no other attributes besides
814 mail, phone, and fax), turn on schema checking with a line like
821 H2: Configuration File Example
825 The following is an example configuration file, interspersed
826 with explanatory text. It defines two databases to handle
827 different parts of the X.500 tree; both are LDBM database
828 instances. The line numbers shown are provided for
829 reference only and are not included in the actual file. First, the
830 global configuration section:
832 E: 1. # example config file - global configuration section
833 E: 2. include /usr/local/etc/slapd.at.conf
834 E: 3. include /usr/local/etc/slapd.oc.conf
836 E: 5. referral ldap://ldap.openldap.org
838 Line 1 is a comment. Lines 2 and 3 include other config files
839 containing attribute and object class definitions, respectively.
840 Line 4 turns on schema checking. The {{EX: referral}} option on line 5
841 means that queries not local to one of the databases defined
842 below will be referred to the LDAP server running on the
843 standard port (389) at the host {{EX: ldap.openldap.org}}.
845 The next section of the configuration file defines an LDBM
846 backend that will handle queries for things in the
847 "o=OpenLDAP Project, c=US" portion of the tree. The
848 database is to be replicated to two slave slapds, one on
849 truelies, the other on judgmentday. Indexes are to be
850 maintained for several attributes, and the {{EX: userPassword}}
851 attribute is to be protected from unauthorized access.
853 E: 1. # ldbm definition for the U-M database
855 E: 3. suffix "o=OpenLDAP Project, c=US"
856 E: 4. directory /usr/local/var/openldap
857 E: 6. rootdn "cn=Manager, o=OpenLDAP Project, c=US"
859 E: 8. replogfile /usr/local/var/openldap/slapd.replog
860 E: 9. replica host=slave1.openldap.org:389
861 E: 10. binddn="cn=Replicator, o=OpenLDAP Project, c=US"
862 E: 11. bindmethod=simple credentials=secret
863 E: 12.replica host=slave2.openldap.org
864 E: 13. binddn="cn=Replicator, o=OpenLDAP Project, c=US"
865 E: 14. bindmethod=kerberos
866 E: 15. srvtab=/etc/srvtab.slave2
867 E: 16.# ldbm indexed attribute definitions
868 E: 17.index cn,sn,uid pres,eq,approx,sub
869 E: 18.index objectclass pres,eq
870 E: 19.index default none
871 E: 20.# ldbm access control definitions
872 E: 21.defaultaccess read
873 E: 22.access to attr=userpassword
875 E: 24. by dn="cn=Admin, o=OpenLDAP Project, c=US" write
878 Line 1 is a comment. The start of the database definition is
879 marked by the database keyword on line 2. Line 3 specifies
880 the DN suffix for queries to pass to this database. Line 4
881 specifies the directory in which the database files will live
883 Lines 6 and 7 identify the database "super user" entry and
884 associated password. This entry is not subject to access
885 control or size or time limit restrictions.
887 Lines 8 through 15 are for replication. Line 8 specifies the
888 replication log file (where changes to the database are logged
889 \- this file is written by slapd and read by slurpd). Lines 9
890 through 11 specify the hostname and port for a replicated
891 host, the DN to bind as when performing updates, the bind
892 method (simple) and the credentials (password) for the
893 binddn. Lines 12 through 15 specify a second replication site,
894 using kerberos instead of simple authentication. See Section
895 10 on slurpd for more information on these options.
897 Lines 16 through 19 indicate the indexes to maintain for
898 various attributes. The default is not to maintain any indexes
901 Lines 20 through 25 specify access control for entries in the
902 database. For all entries, the {{EX: userPassword}} attribute is
903 writable by the entry and the "admin" entry, comparable by
904 everyone else. All other attributes allow read access by
905 default (line 21). Note that the special "entry" attribute is not
906 required in the access directive beginning on line 22. This is
907 because the default access is read.
909 The next section of the example configuration file defines
910 another LDBM database. This one handles queries involving
911 the "o="Babs, Inc.", c=US" subtree.
913 E: 1. # ldbm definition for Babs, Inc. database
915 E: 3. suffix "o=\"Babs, Inc.\", c=US"
916 E: 4. directory /usr/local/ldbm-babs
917 E: 5. rootdn "cn=Babs, o=\"Babs, Inc.\", c=US"
920 Note the use of `\' to escape the quotes necessary in the
921 distinguished names given on lines 3 and 5. By default, all
922 indexes are maintained for every attribute in an entry.