1 # Copyright 1999, The OpenLDAP Foundation, All Rights Reserved.
2 # COPYING RESTRICTIONS APPLY, see COPYRIGHT.
3 H1: The {{I: slapd}} Configuration File
5 Once the software has been built and installed, you are ready to configure it
6 for use at your site. All slapd runtime configuration is accomplished through
7 the {{EX: slapd.conf}} file, installed in the {{EX: ETCDIR}}
8 directory you specified in the {{EX: Make-common}} file.
10 An alternate configuration file can be specified via a
11 command-line option to slapd or slurpd (see Sections 5 and 8,
12 respectively). This section describes the general format of the config file,
13 followed by a detailed description of each config file option.
17 H2: Configuration File Format
19 The {{EX: slapd.conf}} file consists of a series of global configuration options
20 that apply to slapd as a whole (including all backends), followed by
21 zero or more database backend definitions that contain information
22 specific to a backend instance.
24 Global options can be overridden in a backend (for options that
25 appear more than once, the last appearance in the slapd.conf file is
26 used). Blank lines and comment lines beginning with a `#' character
27 are ignored. If a line begins with white space, it is considered a
28 continuation of the previous line. The general format of slapd.conf is
31 E: # comment - these options apply to every database
32 E: <global config options>
33 E: # first database definition & config options
34 E: database <backend 1 type>
35 E: <config options specific to backend 1>
36 E: # second database definition & config options
37 E: database <backend 2 type>
38 E: <config options specific to backend 2>
39 E: # subsequent database definitions & config options
42 Configuration line arguments are separated by white space. If
43 an argument contains white space, the argument should be
44 enclosed in double quotes "like this". If an argument contains
45 a double quote or a backslash character `\', the character
46 should be preceded by a backslash character `\'.
48 The distribution contains an example configuration file that will
49 be installed in the {{EX: ETCDIR}} directory. Also provided are
50 {{EX: slapd.at.conf}}, which contains many commonly used attribute
51 definitions, and {{EX: slapd.oc.conf}}, which contains many commonly
52 used object class definitions. These files can be included from
53 the slapd configuration file (see below).
57 H2: Configuration File Options
59 This section separates the configuration file options into
60 global and backend-specific categories, describing each
61 option and its default value (if any), and giving an example of
68 Options described in this section apply to all backends,
69 unless specifically overridden in a backend definition. Option
70 arguments that should be replaced by actual text are shown
74 H4: access to <what> [ by <who> <accesslevel> ]+
76 This option grants access (specified by <accesslevel>) to a
77 set of entries and/or attributes (specified by <what>) by one or
78 more requesters (specified by <who>). See Section 5.3 on
79 access control for more details and examples.
82 H4: attribute <name> [<name2>] { bin | ces | cis | tel | dn }
84 This option associates a syntax with an attribute name. By
85 default, an attribute is assumed to have syntax cis. An
86 optional alternate name can be given for an attribute. The
87 possible syntaxes and their meanings are
90 * {{EX: ces}} case exact string (case must match during comparisons)
91 * {{EX: cis}} case ignore string (case is ignored during comparisons)
92 * {{EX: tel}} telephone number string (like cis but blanks and dashes ` '
93 are ignored during comparisons)
94 * {{EX: dn}} distinguished name
97 H4: defaultaccess { none | compare | search | read | write }
99 This option specifies the default access to grant requesters
100 not matched by any other access line (see Section 5.3). Note
101 that an access level implies all lesser access levels (e.g.,
102 write access implies read, search and compare).
106 E: defaultaccess read
108 H4: include <filename>
110 This option specifies that slapd should read additional
111 configuration information from the given file before continuing
112 with the next line of the current file. The included file should
113 follow the normal slapd config file format.
115 Note: You should be careful when using this option - there is
116 no small limit on the number of nested include options, and no
117 loop detection is done.
119 H4: loglevel <integer>
121 This option specifies the level at which debugging statements
122 and operation statistics should be syslogged (currently
123 logged to the syslogd(8) LOG_LOCAL4 facility). You must
124 have compiled slapd with DLDAP_DEBUG for this to work
125 (except for the two stats levels, which are always enabled).
126 Log levels are additive. To display what numbers correspond
127 to what kind of debugging, invoke slapd with the ? flag or
128 consult the table below. The possible values for <integer> are:
130 *1 trace function calls
131 *2 debug packet handling
132 *4 heavy trace debugging
133 *8 connection management
134 *16 print out packets sent and received
135 *32 search filter processing
136 *64 configuration file processing
137 *128 access control list processing
138 *256 stats log connections/operations/results
139 *512 stats log entries sent
140 *1024 print communication with shell backends
141 *2048 print entry parsing debugging
147 This will cause lots and lots of debugging information to be
154 H4: objectclass <name> [ requires <attrs> ] [ allows <attrs> ]
156 This option defines the schema rules for the given object
157 class. Used in conjunction with the schemacheck option. See
158 Section 5.4 for more details.
162 This option specifies the referral to pass back when slapd
163 cannot find a local database to handle a request.
167 E: referral ldap://ldap.openldap.org
169 This will refer non-local queries to the LDAP server at the
170 OpenLDAP Project. Smart LDAP clients can re-ask their
171 query at that server, but note that most of these clients are
172 only going to know how to handle simple LDAP URLs that
173 contain a host part and optionally a distinguished name part.
175 H4: schemacheck { on | off }
177 This option turns schema checking on or off. If schema
178 checking is on, entries added or modified through LDAP operations
179 will be checked to ensure they obey the schema rules implied
180 by their object class(es) as defined by the corresponding objectclass
181 option(s). If schema checking is off this check is not done.
187 H4: sizelimit <integer>
189 This option specifies the maximum number of entries to return
190 from a search operation.
197 H4: srvtab <filename>
199 This option specifies the srvtab file in which slapd can find the
200 kerberos keys necessary for authenticating clients using
201 kerberos. This option is only meaningful if you are using
202 kerberos authentication, which must be enabled at compile
203 time by including the appropriate definitions in the
204 {{EX: Make-common}} file.
208 E: srvtab /etc/srvtab
210 H4: timelimit <integer>
212 This option specifies the maximum number of seconds (in real
213 time) slapd will spend answering a search request. If a
214 request is not finished in this time, a result indicating an
215 exceeded timelimit will be returned.
223 H3: General Backend Options
225 Options in this section only apply to the backend in which
226 they are defined. They are supported by every type of
229 H4: database <databasetype>
231 This option marks the beginning of a new database instance
232 definition. <databasetype> should be one of ldbm, shell, or
233 passwd, depending on which backend will serve the
240 This marks the beginning of a new LDBM backend database
243 H4: lastmod { on | off }
245 This option controls whether slapd will automatically maintain
246 the modifiersName, modifyTimestamp, creatorsName, and
247 createTimestamp attributes for entries.
253 H4: readonly { on | off }
255 This option puts the database into "read-only" mode. Any
256 attempts to modify the database will return an "unwilling to
264 E: replica host=<hostname>[:<port>]
266 E: bindmethod={ simple | kerberos }
267 E: \[credentials=<password>]
268 E: \[srvtab=<filename>]
270 This option specifies a replication site for this database. The
271 {{EX: host=}} parameter specifies a host and optionally a port where
272 the slave slapd instance can be found. Either a domain name
273 or IP address may be used for <hostname>. If <port> is not
274 given, the standard LDAP port number (389) is used.
276 The {{EX: binddn=}} parameter gives the DN to bind as for updates to
277 the slave slapd. It should be a DN which has read/write
278 access to the slave slapd's database, typically given as a
279 "rootdn" in the slave's config file. It must also match the
280 updatedn option in the slave slapd's config file. Since DNs are
281 likely to contain embedded spaces, the entire "{{EX: binddn=<DN>}}"
282 string should be enclosed in quotes.
284 {{EX: bindmethod}} is either simple or kerberos, depending on
285 whether simple password-based authentication or kerberos
286 authentication is to be used when connecting to the slave
287 slapd. Simple authentication requires a valid password be
288 given. Kerberos authentication requires a valid srvtab file.
290 The {{EX: credentials=}} parameter, which is only required if using
291 simple authentication, gives the password for binddn on the
294 The {{EX: srvtab=}} parameter, which is only required if using
295 kerberos, specifies the filename which holds the kerberos key
296 for the slave slapd. If omitted, {{EX: /etc/srvtab}} is used.
298 See Section 10 for more details on replication.
300 H4: replogfile <filename>
302 This option specifies the name of the replication log file to
303 which slapd will log changes. The replication log is typically
304 written by slapd and read by slurpd. Normally, this option is
305 only used if slurpd is being used to replicate the database.
306 However, you can also use it to generate a transaction log, if
307 slurpd is not running. In this case, you will need to periodically
308 truncate the file, since it will grow indefinitely otherwise.
310 See Section 10 for more details on replication.
314 This option specifies the DN of an entry that is not subject to
315 access control or administrative limit restrictions for
316 operations on this database.
320 E: rootdn "cn=Manager, o=OpenLDAP Project, c=US"
322 H4: rootkrbname <kerberosname>
324 This option specifies a kerberos name for the DN given above
325 that will always work, regardless of whether an entry with the
326 given DN exists or has a {{EX: krbName}} attribute. This option is
327 useful when creating a database and also when using slurpd
328 to provide replication service (see Section 10).
332 E: rootkrbname admin@openldap.org
334 H4: rootpw <password>
336 This option specifies a password for the DN given above that
337 will always work, regardless of whether an entry with the given
338 DN exists or has a password. This option is useful when
339 creating a database and also when using slurpd to provide
340 replication service (see Section 10).
346 H4: suffix <dn suffix>
348 This option specifies the DN suffix of queries that will be
349 passed to this backend database. Multiple suffix lines can be
350 given, and at least one is required for each database
355 E: suffix "o=OpenLDAP Project, c=US"
357 Queries with a DN ending in "o=OpenLDAP Project, c=US"
358 will be passed to this backend.
360 Note: when the backend to pass a query to is selected, slapd
361 looks at the suffix line(s) in each database definition in the
362 order they appear in the file. Thus, if one database suffix is a
363 prefix of another, it must appear after it in the config file.
367 This option is only applicable in a slave slapd. It specifies the
368 DN allowed to make changes to the replica (typically, this is
369 the DN slurpd binds as when making changes to the replica).
373 H3: LDBM Backend-Specific Options
375 Options in this category only apply to the LDBM backend
376 database. That is, they must follow a "database ldbm" line and
377 come before any other "database" line.
379 H4: cachesize <integer>
381 This option specifies the size in entries of the in-memory
382 cache maintained by the LDBM backend database instance.
389 H4: dbcachesize <integer>
391 This option specifies the size in bytes of the in-memory cache
392 associated with each open index file. If not supported by the
393 underlying database method, this option is ignored without
394 comment. Increasing this number uses more memory but can
395 cause a dramatic performance increase, especially during
396 modifies or when building indexes.
400 E: dbcachesize 100000
403 H4: directory <directory>
405 This option specifies the directory where the LDBM files
406 containing the database and associated indexes live.
410 E: directory /usr/tmp
413 H4: index {<attrlist> | default} [pres,eq,approx,sub,none]
415 This option specifies the indexes to maintain for the given
416 attribute. If only an <attrlist> is given, all possible indexes are
423 E: index sn,uid eq,sub,approx
425 E: index default none
427 This example causes all indexes to be maintained for the cn
428 attribute; equality, substring, and approximate indexes for the
429 sn and uid attributes; and no indexes for all other attributes.
434 This option specifies the file protection mode that newly
435 created database index files should have.
443 H3: Shell Backend-Specific Options
451 E: compare <pathname>
461 E: abandon <pathname>
463 These options specify the pathname of the command to
464 execute in response to the given LDAP operation. The
465 command given should understand and follow the input/output
466 conventions described in Appendix B.
470 E: search /usr/local/bin/search.sh
472 Note that you need only supply those commands you want the
473 backend to handle. Operations for which a command is not
474 supplied will be refused with an "unwilling to perform" error.
478 H3: Password Backend-Specific Options
480 Options in this category only apply to the PASSWD backend
481 database. That is, they must follow a "database passwd" line
482 and come before any other "database" line.
486 This option specifies an alternate passwd file to use.
494 H3: Tcl Backend-Specific Options
496 H4: scriptpath <pathname>
498 This is the full path to a file containing the tcl command(s) to handle
521 These options specify the name of the proc (function) in the tcl script
522 specified in 'scriptpath' to execute in response to the given LDAP
527 E: search proc_search
529 Note that you need only supply those commands you want the
530 tcl backend to handle. Operations for which a command is not
531 supplied will be refused with an "unwilling to perform" error.
535 This is one of the biggest pluses of using the tcl backend.
536 The realm let's you group several databases to the same interpretor.
537 This basically means they share the same global variables and proc
538 space. So global variables, as well as all the procs are callable
539 between databases. If no tclrealm is specified, it is put into the
546 Access to slapd entries and attributes is controlled by the
547 access configuration file directive. The general form of an
550 E: <access directive> ::= access to <what>
551 E: [ by <who> <access> ]+
552 E: <what> ::= * | [ dn=<regex> ] [ filter=<ldapfilter> ]
553 E: [ attrs=<attrlist> ]
554 E: <who> ::= * | self | dn=<regex> | addr=<regex> |
555 E: domain=<regex> | dnattr=<dn attribute>
556 E: <access> ::= [self]none | [self]compare | [self]search
557 E: | [self]read | [self]write
559 where the <what> part selects the entries and/or attributes to
560 which the access applies, the <who> part specifies which
561 entities are granted access, and the <access> part specifies
562 the access granted. Multiple <who> <access> pairs are
563 supported, allowing many entities to be granted different
564 access to the same set of entries and attributes.
567 H3: What to control access to
569 The <what> part of an access specification determines the
570 entries and attributes to which the access control applies.
571 Entries can be selected in two ways: by a regular expression
572 matching the entry's distinguished name:
574 E: dn=<regular expression>
576 Note: The DN pattern specified should be "normalized",
577 meaning that there should be no extra spaces, and commas
578 should be used to separate components. An example
579 normalized DN is "cn=Babs Jensen,o=OpenLDAP Project,c=US".
580 An example of a non-normalized DN is
581 "cn=Babs Jensen; o=OpenLDAP Project, c=US".
583 Or, entries may be selected by a filter matching some
584 attribute(s) in the entry:
586 E: filter=<ldap filter>
588 where <ldap filter> is a string representation of an LDAP
589 search filter, as described in RFC 1588. The special entry
590 selector "*" is used to select any entry, and is a convenient
591 shorthand for the equivalent "dn=.*" selector.
593 Attributes within an entry are selected by including a
594 comma-separated list of attribute names in the <what>
597 E: attrs=<attribute list>
599 Access to the entry itself must be granted or denied using the
600 special attribute name "entry". Note that giving access to an
601 attribute is not enough; access to the entry itself through the
602 "entry" attribute is also required. The complete examples at
603 the end of this section should help clear things up.
607 H2: Who to grant access to
609 The <who> part identifies the entity or entities being granted
610 access. Note that access is granted to "entities" not "entries."
611 Entities can be specified by the special "*" identifier, matching
612 any entry, the keyword "self" matching the entry protected by
613 the access, or by a regular expression matching an entry's
616 E: dn=<regular expression>
618 Note: The DN pattern specified should be "normalized",
619 meaning that there should be no extra spaces, and commas
620 should be used to separate components.
622 Or entities can be specified by a regular expression matching
623 the client's IP address or domain name:
625 E: addr=<regular expression>
626 E: domain=<regular expression>
628 or by an entry listed in a DN-valued attribute in the entry to
629 which the access applies:
631 E: dnattr=<dn-valued attribute name>
633 The dnattr specification is used to give access to an entry
634 whose DN is listed in an attribute of the entry (e.g., give
635 access to a group entry to whoever is listed as the owner of
640 H3: The access to grant
643 The kind of <access> granted can be one of the following:
645 E: none | compare | search | read | write
647 Note that each level implies all lower levels of access. So, for
648 example, granting someone write access to an entry also
649 grants them read, search, and compare access.
653 H3: Access Control Evaluation
655 When evaluating whether some requester should be given
656 access to an entry and/or attribute, slapd compares the entry
657 and/or attribute to the {{EX: <what>}} selectors given in the
658 configuration file. Access directives local to the current
659 database are examined first, followed by global access
660 directives. Within this priority, access directives are
661 examined in the order in which they appear in the config file.
662 Slapd stops with the first {{EX: <what>}} selector that matches the
663 entry and/or attribute. The corresponding access directive is
664 the one slapd will use to evaluate access.
666 Next, slapd compares the entity requesting access to the
667 {{EX: <who>}} selectors within the access directive selected above,
668 in the order in which they appear. It stops with the first {{EX: <who>}}
669 selector that matches the requester. This determines the
670 access the entity requesting access has to the entry and/or
673 Finally, slapd compares the access granted in the selected
674 {{EX: <access>}} clause to the access requested by the client. If it
675 allows greater or equal access, access is granted. Otherwise,
678 The order of evaluation of access directives makes their
679 placement in the configuration file important. If one access
680 directive is more specific than another in terms of the entries
681 it selects, it should appear first in the config file. Similarly, if
682 one {{EX: <who>}} selector is more specific than another it should
683 come first in the access directive. The access control
684 examples given below should help make this clear.
688 H3: Access Control Examples
692 The access control facility described above is quite powerful.
693 This section shows some examples of its use. First, some
696 E: access to * by * read
698 This access directive grants read access to everyone. If it
699 appears alone it is the same as the following defaultaccess
702 E: defaultaccess read
704 The following example shows the use of a regular expression
705 to select the entries by DN in two access directives where
706 ordering is significant.
708 E: access to dn=".*, o=OpenLDAP Project, c=US"
710 E: access to dn=".*, c=US"
713 Read access is granted to entries under the c=US subtree,
714 except for those entries under the "o=OpenLDAP Project,
715 c=US" subtree, to which search access is granted. If the
716 order of these access directives was reversed, the
717 OpenLDAP-specific directive would never be matched, since all
718 OpenLDAP entries are also c=US entries.
720 The next example again shows the importance of ordering,
721 both of the access directives and the "by" clauses. It also
722 shows the use of an attribute selector to grant access to a
723 specific attribute and various <who> selectors.
725 E:access to dn=".*, o=OpenLDAP Project, c=US" attr=homePhone
727 E: by dn=".*, o=OpenLDAP Project, c=US" search
728 E: by domain=.*\.openldap\.org read
730 E:access to dn=".*, o=OpenLDAP Project, c=US"
732 E: by dn=".*, o=OpenLDAP Project, c=US" search
735 This example applies to entries in the "o=OpenLDAP Project, c=US"
736 subtree. To all attributes except homePhone, the entry itself
737 can write them, other OpenLDAP entries can search by them,
738 anybody else has no access. The homePhone attribute is
739 writable by the entry, searchable by other OpenLDAP entries,
740 readable by clients connecting from somewhere in the
741 OpenLDAP.org domain, and comparable by everybody else.
743 Sometimes it is useful to permit a particular DN to add or
744 remove itself from an attribute. For example, if you would like to
745 create a group and allow people too add and remove only
746 their own DN from the member attribute, you could accomplish
747 it with an access directive like this:
749 E: access to attr=member,entry
750 E: by dnattr=member selfwrite
752 The dnattr {{EX: <who>}} selector says that the access applies to
753 entries listed in the member attribute. The selfwrite access
754 selector says that such members can only add or delete their
755 own DN from the attribute, not other values. The addition of
756 the entry attribute is required because access to the entry is
757 required to access any of the entry's attributes.
759 Note that the attr=member construct in the {{EX: <what>}} clause is a
760 shorthand for the clause "dn=* attr=member" (i.e., it matches
761 the member attribute in all entries).
765 H2: Schema Enforcement
769 The {{EX: objectclass}} and schemacheck configuration file options
770 can be used to enforce schema rules on entries in the
771 directory. The schema rules are defined by one or more
772 objectclass lines, and enforcement is turned on or off via the
773 schemacheck option. The format of an {{EX: objectclass}} line is:
775 E: objectclass <name>
776 E: [ requires <attrs> ]
777 E: [ allows <attrs> ]
779 This option defines the schema rules for the object class
780 given by {{EX: <name>}}. Schema rules consist of the attributes the
781 entry is required to have (given by the requires {{EX: <attrs>}}
782 clause) and those attributes that it may optionally have (given
783 by the allows {{EX: <attrs>}} clause). In both clauses, {{EX: <attrs>}} is a
784 comma-separated list of attribute names.
786 Note that object class inheritance (that is, defining one object
787 class in terms of another) is not supported directly. All of an
788 object class's required and allowed attributes must be listed
789 in the objectclass definition.
791 For example, to define an objectclass called myPerson, you
792 might include a definition like this:
794 E: objectclass myperson
795 E: requires cn, sn, objectclass
796 E: allows mail, phone, fax
798 To then enforce this rule (i.e., to make sure an entry with an
799 objectclass of myperson contains the cn, sn and objectclass
800 attributes, and that it contains no other attributes besides
801 mail, phone, and fax), turn on schema checking with a line like
808 H2: Configuration File Example
812 The following is an example configuration file, interspersed
813 with explanatory text. It defines two databases to handle
814 different parts of the X.500 tree; both are LDBM database
815 instances. The line numbers shown are provided for
816 reference only and are not included in the actual file. First, the
817 global configuration section:
819 E: 1. # example config file - global configuration section
820 E: 2. include /usr/local/etc/slapd.at.conf
821 E: 3. include /usr/local/etc/slapd.oc.conf
823 E: 5. referral ldap://ldap.openldap.org
825 Line 1 is a comment. Lines 2 and 3 include other config files
826 containing attribute and object class definitions, respectively.
827 Line 4 turns on schema checking. The {{EX: referral}} option on line 5
828 means that queries not local to one of the databases defined
829 below will be referred to the LDAP server running on the
830 standard port (389) at the host {{EX: ldap.openldap.org}}.
832 The next section of the configuration file defines an LDBM
833 backend that will handle queries for things in the
834 "o=OpenLDAP Project, c=US" portion of the tree. The
835 database is to be replicated to two slave slapds, one on
836 truelies, the other on judgmentday. Indexes are to be
837 maintained for several attributes, and the {{EX: userPassword}}
838 attribute is to be protected from unauthorized access.
840 E: 1. # ldbm definition for the U-M database
842 E: 3. suffix "o=OpenLDAP Project, c=US"
843 E: 4. directory /usr/local/var/openldap
844 E: 6. rootdn "cn=Manager, o=OpenLDAP Project, c=US"
846 E: 8. replogfile /usr/local/var/openldap/slapd.replog
847 E: 9. replica host=slave1.openldap.org:389
848 E: 10. binddn="cn=Replicator, o=OpenLDAP Project, c=US"
849 E: 11. bindmethod=simple credentials=secret
850 E: 12.replica host=slave2.openldap.org
851 E: 13. binddn="cn=Replicator, o=OpenLDAP Project, c=US"
852 E: 14. bindmethod=kerberos
853 E: 15. srvtab=/etc/srvtab.slave2
854 E: 16.# ldbm indexed attribute definitions
855 E: 17.index cn,sn,uid pres,eq,approx,sub
856 E: 18.index objectclass pres,eq
857 E: 19.index default none
858 E: 20.# ldbm access control definitions
859 E: 21.defaultaccess read
860 E: 22.access to attr=userpassword
862 E: 24. by dn="cn=Admin, o=OpenLDAP Project, c=US" write
865 Line 1 is a comment. The start of the database definition is
866 marked by the database keyword on line 2. Line 3 specifies
867 the DN suffix for queries to pass to this database. Line 4
868 specifies the directory in which the database files will live
870 Lines 6 and 7 identify the database "super user" entry and
871 associated password. This entry is not subject to access
872 control or size or time limit restrictions.
874 Lines 8 through 15 are for replication. Line 8 specifies the
875 replication log file (where changes to the database are logged
876 \- this file is written by slapd and read by slurpd). Lines 9
877 through 11 specify the hostname and port for a replicated
878 host, the DN to bind as when performing updates, the bind
879 method (simple) and the credentials (password) for the
880 binddn. Lines 12 through 15 specify a second replication site,
881 using kerberos instead of simple authentication. See Section
882 10 on slurpd for more information on these options.
884 Lines 16 through 19 indicate the indexes to maintain for
885 various attributes. The default is not to maintain any indexes
888 Lines 20 through 25 specify access control for entries in the
889 database. For all entries, the {{EX: userPassword}} attribute is
890 writable by the entry and the "admin" entry, comparable by
891 everyone else. All other attributes allow read access by
892 default (line 21). Note that the special "entry" attribute is not
893 required in the access directive beginning on line 22. This is
894 because the default access is read.
896 The next section of the example configuration file defines
897 another LDBM database. This one handles queries involving
898 the "o="Babs, Inc.", c=US" subtree.
900 E: 1. # ldbm definition for Babs, Inc. database
902 E: 3. suffix "o=\"Babs, Inc.\", c=US"
903 E: 4. directory /usr/local/ldbm-babs
904 E: 5. rootdn "cn=Babs, o=\"Babs, Inc.\", c=US"
907 Note the use of `\' to escape the quotes necessary in the
908 distinguished names given on lines 3 and 5. By default, all
909 indexes are maintained for every attribute in an entry.