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> ]+
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> ]+
553 E: <what> ::= * | [ dn=<regex> ] [ filter=<ldapfilter> ]
554 E: [ attrs=<attrlist> ]
555 E: <who> ::= * | self | dn=<regex> | addr=<regex> |
556 E: domain=<regex> | dnattr=<dn attribute>
557 E: <access> ::= [self]none | [self]compare | [self]search
558 E: | [self]read | [self]write
560 where the <what> part selects the entries and/or attributes to
561 which the access applies, the <who> part specifies which
562 entities are granted access, and the <access> part specifies
563 the access granted. Multiple <who> <access> pairs are
564 supported, allowing many entities to be granted different
565 access to the same set of entries and attributes.
568 H3: What to control access to
570 The <what> part of an access specification determines the
571 entries and attributes to which the access control applies.
572 Entries can be selected in two ways: by a regular expression
573 matching the entry's distinguished name:
575 E: dn=<regular expression>
577 Note: The DN pattern specified should be "normalized",
578 meaning that there should be no extra spaces, and commas
579 should be used to separate components. An example
580 normalized DN is "cn=Babs Jensen,o=OpenLDAP Project,c=US".
581 An example of a non-normalized DN is
582 "cn=Babs Jensen; o=OpenLDAP Project, c=US".
584 Or, entries may be selected by a filter matching some
585 attribute(s) in the entry:
587 E: filter=<ldap filter>
589 where <ldap filter> is a string representation of an LDAP
590 search filter, as described in RFC 1588. The special entry
591 selector "*" is used to select any entry, and is a convenient
592 shorthand for the equivalent "dn=.*" selector.
594 Attributes within an entry are selected by including a
595 comma-separated list of attribute names in the <what>
598 E: attrs=<attribute list>
600 Access to the entry itself must be granted or denied using the
601 special attribute name "entry". Note that giving access to an
602 attribute is not enough; access to the entry itself through the
603 "entry" attribute is also required. The complete examples at
604 the end of this section should help clear things up.
608 H2: Who to grant access to
610 The <who> part identifies the entity or entities being granted
611 access. Note that access is granted to "entities" not "entries."
612 Entities can be specified by the special "*" identifier, matching
613 any entry, the keyword "self" matching the entry protected by
614 the access, or by a regular expression matching an entry's
617 E: dn=<regular expression>
619 Note: The DN pattern specified should be "normalized",
620 meaning that there should be no extra spaces, and commas
621 should be used to separate components.
623 Or entities can be specified by a regular expression matching
624 the client's IP address or domain name:
626 E: addr=<regular expression>
627 E: domain=<regular expression>
629 or by an entry listed in a DN-valued attribute in the entry to
630 which the access applies:
632 E: dnattr=<dn-valued attribute name>
634 The dnattr specification is used to give access to an entry
635 whose DN is listed in an attribute of the entry (e.g., give
636 access to a group entry to whoever is listed as the owner of
641 H3: The access to grant
644 The kind of <access> granted can be one of the following:
646 E: none | compare | search | read | write
648 Note that each level implies all lower levels of access. So, for
649 example, granting someone write access to an entry also
650 grants them read, search, and compare access.
654 H3: Access Control Evaluation
656 When evaluating whether some requester should be given
657 access to an entry and/or attribute, slapd compares the entry
658 and/or attribute to the {{EX: <what>}} selectors given in the
659 configuration file. Access directives local to the current
660 database are examined first, followed by global access
661 directives. Within this priority, access directives are
662 examined in the order in which they appear in the config file.
663 Slapd stops with the first {{EX: <what>}} selector that matches the
664 entry and/or attribute. The corresponding access directive is
665 the one slapd will use to evaluate access.
667 Next, slapd compares the entity requesting access to the
668 {{EX: <who>}} selectors within the access directive selected above,
669 in the order in which they appear. It stops with the first {{EX: <who>}}
670 selector that matches the requester. This determines the
671 access the entity requesting access has to the entry and/or
674 Finally, slapd compares the access granted in the selected
675 {{EX: <access>}} clause to the access requested by the client. If it
676 allows greater or equal access, access is granted. Otherwise,
679 The order of evaluation of access directives makes their
680 placement in the configuration file important. If one access
681 directive is more specific than another in terms of the entries
682 it selects, it should appear first in the config file. Similarly, if
683 one {{EX: <who>}} selector is more specific than another it should
684 come first in the access directive. The access control
685 examples given below should help make this clear.
689 H3: Access Control Examples
693 The access control facility described above is quite powerful.
694 This section shows some examples of its use. First, some
697 E: access to * by * read
699 This access directive grants read access to everyone. If it
700 appears alone it is the same as the following defaultaccess
703 E: defaultaccess read
705 The following example shows the use of a regular expression
706 to select the entries by DN in two access directives where
707 ordering is significant.
709 E: access to dn=".*, o=OpenLDAP Project, c=US"
711 E: access to dn=".*, c=US"
714 Read access is granted to entries under the c=US subtree,
715 except for those entries under the "o=OpenLDAP Project,
716 c=US" subtree, to which search access is granted. If the
717 order of these access directives was reversed, the
718 OpenLDAP-specific directive would never be matched, since all
719 OpenLDAP entries are also c=US entries.
721 The next example again shows the importance of ordering,
722 both of the access directives and the "by" clauses. It also
723 shows the use of an attribute selector to grant access to a
724 specific attribute and various <who> selectors.
726 E:access to dn=".*, o=OpenLDAP Project, c=US" attr=homePhone
728 E: by dn=".*, o=OpenLDAP Project, c=US" search
729 E: by domain=.*\.openldap\.org read
731 E:access to dn=".*, o=OpenLDAP Project, c=US"
733 E: by dn=".*, o=OpenLDAP Project, c=US" search
736 This example applies to entries in the "o=OpenLDAP Project, c=US"
737 subtree. To all attributes except homePhone, the entry itself
738 can write them, other OpenLDAP entries can search by them,
739 anybody else has no access. The homePhone attribute is
740 writable by the entry, searchable by other OpenLDAP entries,
741 readable by clients connecting from somewhere in the
742 OpenLDAP.org domain, and comparable by everybody else.
744 Sometimes it is useful to permit a particular DN to add or
745 remove itself from an attribute. For example, if you would like to
746 create a group and allow people too add and remove only
747 their own DN from the member attribute, you could accomplish
748 it with an access directive like this:
750 E: access to attr=member,entry
751 E: by dnattr=member selfwrite
753 The dnattr {{EX: <who>}} selector says that the access applies to
754 entries listed in the member attribute. The selfwrite access
755 selector says that such members can only add or delete their
756 own DN from the attribute, not other values. The addition of
757 the entry attribute is required because access to the entry is
758 required to access any of the entry's attributes.
760 Note that the attr=member construct in the {{EX: <what>}} clause is a
761 shorthand for the clause "dn=* attr=member" (i.e., it matches
762 the member attribute in all entries).
766 H2: Schema Enforcement
770 The {{EX: objectclass}} and schemacheck configuration file options
771 can be used to enforce schema rules on entries in the
772 directory. The schema rules are defined by one or more
773 objectclass lines, and enforcement is turned on or off via the
774 schemacheck option. The format of an {{EX: objectclass}} line is:
776 E: objectclass <name>
777 E: [ requires <attrs> ]
778 E: [ allows <attrs> ]
780 This option defines the schema rules for the object class
781 given by {{EX: <name>}}. Schema rules consist of the attributes the
782 entry is required to have (given by the requires {{EX: <attrs>}}
783 clause) and those attributes that it may optionally have (given
784 by the allows {{EX: <attrs>}} clause). In both clauses, {{EX: <attrs>}} is a
785 comma-separated list of attribute names.
787 Note that object class inheritance (that is, defining one object
788 class in terms of another) is not supported directly. All of an
789 object class's required and allowed attributes must be listed
790 in the objectclass definition.
792 For example, to define an objectclass called myPerson, you
793 might include a definition like this:
795 E: objectclass myperson
796 E: requires cn, sn, objectclass
797 E: allows mail, phone, fax
799 To then enforce this rule (i.e., to make sure an entry with an
800 objectclass of myperson contains the cn, sn and objectclass
801 attributes, and that it contains no other attributes besides
802 mail, phone, and fax), turn on schema checking with a line like
809 H2: Configuration File Example
813 The following is an example configuration file, interspersed
814 with explanatory text. It defines two databases to handle
815 different parts of the X.500 tree; both are LDBM database
816 instances. The line numbers shown are provided for
817 reference only and are not included in the actual file. First, the
818 global configuration section:
820 E: 1. # example config file - global configuration section
821 E: 2. include /usr/local/etc/slapd.at.conf
822 E: 3. include /usr/local/etc/slapd.oc.conf
824 E: 5. referral ldap://ldap.openldap.org
826 Line 1 is a comment. Lines 2 and 3 include other config files
827 containing attribute and object class definitions, respectively.
828 Line 4 turns on schema checking. The {{EX: referral}} option on line 5
829 means that queries not local to one of the databases defined
830 below will be referred to the LDAP server running on the
831 standard port (389) at the host {{EX: ldap.openldap.org}}.
833 The next section of the configuration file defines an LDBM
834 backend that will handle queries for things in the
835 "o=OpenLDAP Project, c=US" portion of the tree. The
836 database is to be replicated to two slave slapds, one on
837 truelies, the other on judgmentday. Indexes are to be
838 maintained for several attributes, and the {{EX: userPassword}}
839 attribute is to be protected from unauthorized access.
841 E: 1. # ldbm definition for the U-M database
843 E: 3. suffix "o=OpenLDAP Project, c=US"
844 E: 4. directory /usr/local/var/openldap
845 E: 6. rootdn "cn=Manager, o=OpenLDAP Project, c=US"
847 E: 8. replogfile /usr/local/var/openldap/slapd.replog
848 E: 9. replica host=slave1.openldap.org:389
849 E: 10. binddn="cn=Replicator, o=OpenLDAP Project, c=US"
850 E: 11. bindmethod=simple credentials=secret
851 E: 12.replica host=slave2.openldap.org
852 E: 13. binddn="cn=Replicator, o=OpenLDAP Project, c=US"
853 E: 14. bindmethod=kerberos
854 E: 15. srvtab=/etc/srvtab.slave2
855 E: 16.# ldbm indexed attribute definitions
856 E: 17.index cn,sn,uid pres,eq,approx,sub
857 E: 18.index objectclass pres,eq
858 E: 19.index default none
859 E: 20.# ldbm access control definitions
860 E: 21.defaultaccess read
861 E: 22.access to attr=userpassword
863 E: 24. by dn="cn=Admin, o=OpenLDAP Project, c=US" write
866 Line 1 is a comment. The start of the database definition is
867 marked by the database keyword on line 2. Line 3 specifies
868 the DN suffix for queries to pass to this database. Line 4
869 specifies the directory in which the database files will live
871 Lines 6 and 7 identify the database "super user" entry and
872 associated password. This entry is not subject to access
873 control or size or time limit restrictions.
875 Lines 8 through 15 are for replication. Line 8 specifies the
876 replication log file (where changes to the database are logged
877 \- this file is written by slapd and read by slurpd). Lines 9
878 through 11 specify the hostname and port for a replicated
879 host, the DN to bind as when performing updates, the bind
880 method (simple) and the credentials (password) for the
881 binddn. Lines 12 through 15 specify a second replication site,
882 using kerberos instead of simple authentication. See Section
883 10 on slurpd for more information on these options.
885 Lines 16 through 19 indicate the indexes to maintain for
886 various attributes. The default is not to maintain any indexes
889 Lines 20 through 25 specify access control for entries in the
890 database. For all entries, the {{EX: userPassword}} attribute is
891 writable by the entry and the "admin" entry, comparable by
892 everyone else. All other attributes allow read access by
893 default (line 21). Note that the special "entry" attribute is not
894 required in the access directive beginning on line 22. This is
895 because the default access is read.
897 The next section of the example configuration file defines
898 another LDBM database. This one handles queries involving
899 the "o="Babs, Inc.", c=US" subtree.
901 E: 1. # ldbm definition for Babs, Inc. database
903 E: 3. suffix "o=\"Babs, Inc.\", c=US"
904 E: 4. directory /usr/local/ldbm-babs
905 E: 5. rootdn "cn=Babs, o=\"Babs, Inc.\", c=US"
908 Note the use of `\' to escape the quotes necessary in the
909 distinguished names given on lines 3 and 5. By default, all
910 indexes are maintained for every attribute in an entry.