2 # Copyright 1999-2000, The OpenLDAP Foundation, All Rights Reserved.
3 # COPYING RESTRICTIONS APPLY, see COPYRIGHT.
5 H1: The slapd Configuration File
7 Once the software has been built and installed, you are ready
8 to configure {{slapd}}(8) for use at your site. The slapd
9 runtime configuration is primarily accomplished through the
10 {{slapd.conf}}(5) file, normally installed in the
11 {{EX:/usr/local/etc/openldap}} directory.
13 An alternate configuration file can be specified via a
14 command-line option to {{slapd}}(8) or {{slurpd}}(8). This chapter
15 describes the general format of the config file, followed by a
16 detailed description of commonly used config file directives.
19 H2: Configuration File Format
21 The {{slapd.conf}}(5) file consists of three types of configuration
22 information: global, backend specific, and database specific. Global
23 information is specified first, followed by information associated
24 with a particular backend type, which is then followed by information
25 associated with a particular database instance. Global directives can
26 be overridden in backend and/or database directives, and backend directives
27 can be overridden by database directives.
29 Blank lines and comment lines beginning with a '{{EX:#}}' character
30 are ignored. If a line begins with white space, it is considered a
31 continuation of the previous line. The general format of slapd.conf is
34 > # global configuration directives
35 > <global config directives>
37 > # backend definition
39 > <backend-specific directives>
41 > # first database definition & config directives
43 > <database-specific directives>
45 > # second database definition & config directives
47 > <database-specific directives>
49 > # second database definition & config directives
51 > <database-specific directives>
53 > # subsequent backend & database definitions & config directives
56 A configuration directive may take arguments. If so, they are
57 separated by white space. If an argument contains white space,
58 the argument should be enclosed in double quotes {{EX:"like this"}}. If
59 an argument contains a double quote or a backslash character `{{EX:\}}',
60 the character should be preceded by a backslash character `{{EX:\}}'.
62 The distribution contains an example configuration file that will
63 be installed in the {{F: /usr/local/etc/openldap}} directory.
64 A number of files containing schema definitions (attribute types
65 and object classes) are also provided in the
66 {{F: /usr/local/etc/openldap/schema}} directory.
69 H2: Configuration File Directives
71 This section details commonly used configuration directives. For
72 a complete list, see the {{slapd.conf}}(5) manual page. This section
73 separates the configuration file directives into global,
74 backend-specific and data-specific categories, describing each
75 directive and its default value (if any), and giving an example of
82 Directives described in this section apply to all backends
83 and databases unless specifically overridden in a backend or
84 database definition. Arguments that should be replaced
85 by actual text are shown in brackets {{EX:<>}}.
88 H4: access to <what> [ by <who> <accesslevel> <control> ]+
90 This directive grants access (specified by <accesslevel>) to a
91 set of entries and/or attributes (specified by <what>) by one or
92 more requesters (specified by <who>).
93 See the {{SECT:Access Control}} section of this chapter for a
94 summary of basic usage.
96 More details discussion of this directive can be found in the
97 {{SECT:Advanced Access Control}} chapter.
101 H4: attributetype <{{REF:RFC2252}} Attribute Type Description>
103 This directive defines an attribute type.
104 Please see the {{SECT:Schema Specification}} chapter
105 for information regarding how to use this directive.
107 H4: defaultaccess { none | compare | search | read | write }
109 This directive specifies the default access to grant requesters
110 when no {{EX:access}} directives have been specified. Any given
111 access level implies all lesser access levels (e.g., read access
112 implies search and compare but not write).
114 Note: It is recommend that the {{EX:access}} directive be used
115 to specify access control. See the {{SECT:Access Control}}
116 section of this chapter for information regarding the {{EX:access}}
121 E: defaultaccess read
124 H4: idletimeout <integer>
126 Specify the number of seconds to wait before forcibly closing
127 an idle client connection. An idletimeout of 0, the default,
128 disables this feature.
131 H4: include <filename>
133 This directive specifies that slapd should read additional
134 configuration information from the given file before continuing
135 with the next line of the current file. The included file should
136 follow the normal slapd config file format. The file is commonly
137 used to include files containing schema specifications.
139 Note: You should be careful when using this directive - there is
140 no small limit on the number of nested include directives, and no
141 loop detection is done.
143 H4: loglevel <integer>
145 This directive specifies the level at which debugging statements
146 and operation statistics should be syslogged (currently logged to
147 the {{syslogd}}(8) {{EX:LOG_LOCAL4}} facility). You must have
148 configured OpenLDAP {{EX:--enable-debug}} (the default) for this
149 to work (except for the two statistics levels, which are always
150 enabled). Log levels are additive. To display what numbers
151 correspond to what kind of debugging, invoke slapd with {{EX:-?}}
152 or consult the table below. The possible values for <integer> are:
154 !block table; colaligns="RL"; align=Center; \
155 title="Table 5.1: Debugging Levels"
157 -1 enable all debugging
159 1 trace function calls
160 2 debug packet handling
161 4 heavy trace debugging
162 8 connection management
163 16 print out packets sent and received
164 32 search filter processing
165 64 configuration file processing
166 128 access control list processing
167 256 stats log connections/operations/results
168 512 stats log entries sent
169 1024 print communication with shell backends
170 2048 print entry parsing debugging
177 This will cause lots and lots of debugging information to be
185 H4: objectclass <{{REF:RFC2252}} Object Class Description>
187 This directive defines an object class.
188 Please see the {{SECT:Schema Specification}} chapter for
189 information regarding how to use this directive.
194 This directive specifies the referral to pass back when slapd
195 cannot find a local database to handle a request.
199 > referral ldap://root.openldap.org
201 This will refer non-local queries to the global root LDAP server
202 at the OpenLDAP Project. Smart LDAP clients can re-ask their
203 query at that server, but note that most of these clients are
204 only going to know how to handle simple LDAP URLs that
205 contain a host part and optionally a distinguished name part.
208 H4: sizelimit <integer>
210 This directive specifies the maximum number of entries to return
211 from a search operation.
218 H4: timelimit <integer>
220 This directive specifies the maximum number of seconds (in real
221 time) slapd will spend answering a search request. If a
222 request is not finished in this time, a result indicating an
223 exceeded timelimit will be returned.
230 H3: General Backend Directives
232 Directives in this section apply only to the backend in which
233 they are defined. They are supported by every type of backend.
234 Backend directives apply to all databases instances of the
235 same type and, depending on the directive, may be overridden
236 by database directives.
240 This directive marks the beginning of a backend declaration.
241 {{EX:<type>}} should be one of the
242 supported backend types listed in Table 5.2.
244 !block table; align=Center; coltags="EX,N"; \
245 title="Table 5.2: Database Backends"
247 bdb Berkeley DB transactional backend
248 dnssrv DNS SRV backend
249 ldbm Lightweight DBM backend
250 ldap Lightweight Directory Access Protocol (Proxy) backend
251 meta Meta Directory backend
252 monitor Monitor backend
253 passwd Provides read-only access to {{passwd}}(5)
254 perl Perl Programmable backend
255 shell Shell (extern program) backend
256 sql SQL Programmable backend
257 tcl TCL Programmable backend
264 This marks the beginning of a new {{TERM:BDB}} backend
268 H3: General Database Directives
270 Directives in this section apply only to the database in which
271 they are defined. They are supported by every type of database.
275 This directive marks the beginning of a database instance
277 {{EX:<type>}} should be one of the
278 supported backend types listed in Table 5.2.
284 This marks the beginning of a new {{TERM:BDB}} database instance
288 H4: readonly { on | off }
290 This directive puts the database into "read-only" mode. Any
291 attempts to modify the database will return an "unwilling to
300 > replica host=<hostname>[:<port>]
301 > [bindmethod={ simple | kerberos | sasl }]
304 > [authcid=<identity>]
305 > [authzid=<identity>]
306 > [credentials=<password>]
307 > [srvtab=<filename>]
309 This directive specifies a replication site for this database. The
310 {{EX:host=}} parameter specifies a host and optionally a port where
311 the slave slapd instance can be found. Either a domain name
312 or IP address may be used for <hostname>. If <port> is not
313 given, the standard LDAP port number (389) is used.
315 The {{EX:binddn=}} parameter gives the DN to bind as for updates to
316 the slave slapd. It should be a DN which has read/write
317 access to the slave slapd's database, typically given as a
318 {{EX:rootdn}} in the slave's config file. It must also match the
319 {{EX:updatedn}} directive in the slave slapd's config file. Since DNs are
320 likely to contain embedded spaces, the entire {{EX:"binddn=<DN>"}}
321 string should be enclosed in double quotes.
323 The {{EX:bindmethod}} is {{EX:simple}} or {{EX:kerberos}} or {{EX:sasl}},
324 depending on whether simple password-based authentication or Kerberos
325 authentication or {{TERM:SASL}} authentication is to be used when connecting
328 Simple authentication should not be used unless adequate integrity
329 and privacy protections are in place (e.g. TLS or IPSEC). Simple
330 authentication requires specification of {{EX:binddn}} and
331 {{EX:credentials}} parameters.
333 Kerberos authentication is deprecated in favor of SASL authentication
334 mechanisms, in particular the {{EX:KERBEROS_V4}} and {{EX:GSSAPI}}
335 mechanisms. Kerberos authentication requires {{EX:binddn}} and
336 {{EX:srvtab}} parameters.
338 SASL authentication is generally recommended. SASL authentication
339 requires specification of a mechanism using the {{EX:mech}} parameter.
340 Depending on the mechanism, an authentication identity and/or
341 credentials can be specified using {{EX:authcid}} and {{EX:credentials}}
342 respectively. The {{EX:authzid}} parameter may be used to specify
343 an authorization identity.
345 See the chapter entitled {{SECT:Replication with slurpd}} for more
346 information on how to use this directive.
349 H4: replogfile <filename>
351 This directive specifies the name of the replication log file to
352 which slapd will log changes. The replication log is typically
353 written by slapd and read by slurpd. Normally, this directive is
354 only used if slurpd is being used to replicate the database.
355 However, you can also use it to generate a transaction log, if
356 slurpd is not running. In this case, you will need to periodically
357 truncate the file, since it will grow indefinitely otherwise.
359 See the chapter entitled {{SECT:Replication with slurpd}} for more
360 information on how to use this directive.
365 This directive specifies the DN that is not subject to
366 access control or administrative limit restrictions for
367 operations on this database. The DN need not refer to
368 an entry in this database or even in the directory. The
369 DN may refer to a SASL identity.
373 > rootdn "cn=Manager,dc=example,dc=com"
377 > rootdn "uid=root,cn=example.com,cn=digest-md5,cn=auth"
379 See the {{SECT:SASL Authentication}} section for information on
380 SASL authentication identities.
383 H4: rootpw <password>
385 This directive can be used to specifies a password for the DN for
392 It is also permissible to provide hash of the password in
393 RFC 2307 form. {{slappasswd}}(8) may be used to generate
398 > rootpw {SSHA}ZKKuqbEKJfKSXhUbHG3fG8MDn9j1v4QN
400 The hash was generated using the command {{EX:slappasswd -s secret}}.
402 This directive is deprecated in favor of SASL based authentication.
405 H4: suffix <dn suffix>
407 This directive specifies the DN suffix of queries that will be
408 passed to this backend database. Multiple suffix lines can be
409 given, and at least one is required for each database
414 > suffix "dc=example,dc=com"
416 Queries with a DN ending in "dc=example,dc=com"
417 will be passed to this backend.
419 Note: When the backend to pass a query to is selected, slapd
420 looks at the suffix line(s) in each database definition in the
421 order they appear in the file. Thus, if one database suffix is a
422 prefix of another, it must appear after it in the config file.
426 This directive is only applicable in a slave slapd. It specifies
427 the DN allowed to make changes to the replica. This may be the DN
428 {{slurpd}}(8) binds as when making changes to the replica or the DN
429 associated with a SASL identity.
433 > updatedn "cn=Update Daemon,dc=example,dc=com"
437 > updatedn "uid=slurpd,cn=example.com,cn=digest-md5,cn=auth"
439 See the {{SECT:Replication with slurpd}} chapter for more information
440 on how to use this directive.
444 This directive is only applicable in a slave slapd. It
445 specifies the URL to return to clients which submit update
446 requests upon the replica.
447 If specified multiple times, each {{TERM:URL}} is provided.
451 > updateref ldap://master.example.net
454 H3: BDB Database Directives
456 Directives in this category only apply to a {{TERM:BDB}} database.
457 That is, they must follow a "database bdb" line and come before any
458 subsequent "backend" or "database" line. For a complete reference
459 of BDB configuration directives, see {{slapd-bdb}}(5).
461 H4: directory <directory>
463 This directive specifies the directory where the BDB files
464 containing the database and associated indices live.
468 > directory /usr/local/var/openldap-data
471 H3: LDBM Database Directives
473 Directives in this category only apply to a {{TERM:LDBM}} database.
474 That is, they must follow a "database ldbm" line and come before
475 any subsequent "backend" or "database" line. For a complete reference
476 of LDBM configuration directives, see {{slapd-ldbm}}(5).
478 H4: cachesize <integer>
480 This directive specifies the size in entries of the in-memory
481 cache maintained by the LDBM backend database instance.
488 H4: dbcachesize <integer>
490 This directive specifies the size in bytes of the in-memory cache
491 associated with each open index file. If not supported by the
492 underlying database method, this directive is ignored without
493 comment. Increasing this number uses more memory but can
494 cause a dramatic performance increase, especially during
495 modifies or when building indices.
504 This option, if present, disables database locking.
505 Enabling this option may improve performance at the expense
511 This option causes on-disk database contents to not be immediately
512 synchronized with in memory changes upon change. Enabling this option
513 may improve performance at the expense of data integrity.
516 H4: directory <directory>
518 This directive specifies the directory where the LDBM files
519 containing the database and associated indices live.
523 > directory /usr/local/var/openldap-data
526 H4: index {<attrlist> | default} [pres,eq,approx,sub,none]
528 This directive specifies the indices to maintain for the given
529 attribute. If only an {{EX:<attrlist>}} is given, the default
530 indices are maintained.
534 > index default pres,eq
536 > index cn,sn pres,eq,sub
537 > index objectClass eq
539 The first line sets the default set of indices to maintain to
540 present and equality. The second line causes the default (pres,eq)
541 set of indices to be maintained for the {{EX:uid}} attribute type.
542 The third line causes present, equality, and substring indices to
543 be maintained for {{EX:cn}} and {{EX:sn}} attribute types. The
544 fourth line causes an equality index for the {{EX:objectClass}}
547 By default, no indices are maintained. It is generally advised
548 that minimally an equality index upon objectClass be maintained.
550 > index objectClass eq
556 This directive specifies the file protection mode that newly
557 created database index files should have.
566 Access to slapd entries and attributes is controlled by the
567 access configuration file directive. The general form of an
570 > <access directive> ::= access to <what>
571 > [by <who> <access> <control>]+
572 > <what> ::= * | [ dn[.<dn style>]=<regex>]
573 > [filter=<ldapfilter>] [attrs=<attrlist>]
574 > <dn style> ::= regex | exact | base | one | subtree | children
575 > <attrlist> ::= <attr> | <attr> , <attrlist>
576 > <attr> ::= <attrname> | entry | children
577 > <who> ::= [* | anonymous | users | self |
578 > dn[.<dn style>]=<regex>]
579 > [dnattr=<attrname> ]
580 > [group[/<objectclass>[/<attrname>][.<basic style>]]=<regex> ]
581 > [peername[.<basic style>]=<regex>]
582 > [sockname[.<basic style>]=<regex>]
583 > [domain[.<basic style>]=<regex>]
584 > [sockurl[.<basic style>]=<regex>]
587 > <basic style> ::= regex | exact
588 > <access> ::= [self]{<level>|<priv>}
589 > <level> ::= none | auth | compare | search | read | write
590 > <priv> ::= {=|+|-}{w|r|s|c|x}+
591 > <control> ::= [stop | continue | break]
593 where the <what> part selects the entries and/or attributes to
594 which the access applies, the {{EX:<who>}} part specifies which
595 entities are granted access, and the {{EX:<access>}} part specifies
596 the access granted. Multiple {{EX:<who> <access> <control>}} triplets
597 are supported, allowing many entities to be granted different
598 access to the same set of entries and attributes. Not all of these
599 access control options are described here; for more details see
600 the {{slapd.access}}(5) man page.
603 H3: What to control access to
605 The <what> part of an access specification determines the
606 entries and attributes to which the access control applies.
607 Entries can be selected in two ways: by a regular expression
608 matching the entry's distinguished name:
610 > dn=<regular expression>
612 Note: The DN pattern specified should be "normalized" to the RFC2253
613 restricted DN form. In particular, there should be no extra spaces
614 and commas should be used to separate components. An example
615 normalized DN is "{{EX:cn=Babs Jensen,dc=example,dc=com}}". An
616 example of a non-normalized DN is "{{EX:cn=Babs Jensen; dc=example;
619 Or, entries may be selected by a filter matching some
620 attribute(s) in the entry:
622 > filter=<ldap filter>
624 where <ldap filter> is a string representation of an LDAP
625 search filter, as described in {{REF:RFC2254}}.
627 Attributes within an entry are selected by including a
628 comma-separated list of attribute names in the <what>
631 > attrs=<attribute list>
633 Access to the entry itself must be granted or denied using the
634 special attribute name "{{EX:entry}}". Note that giving access to an
635 attribute is not enough; access to the entry itself through the
636 {{EX:entry}} attribute is also required. The complete examples at
637 the end of this section should help clear things up.
639 Lastly, there is a special entry selector {{EX:"*"}} that is used to
640 select any entry. It is used when no other {{EX:<what>}}
641 selector has been provided. It's equivalent to "{{EX:dn=.*}}"
644 H3: Who to grant access to
646 The <who> part identifies the entity or entities being granted
647 access. Note that access is granted to "entities" not "entries."
648 The following table summarizes entity specifiers:
650 !block table; align=Center; coltags="EX,N"; \
651 title="Table 5.3: Access Entity Specifiers"
653 * All, including anonymous and authenticated users
654 anonymous Anonymous (non-authenticated) users
655 users Authenticated users
656 self User associated with target entry
657 dn=<regex> Users matching regular expression
660 The DN specifier takes a regular expression which is used
661 to match against the "normalized" DN of the current entity.
663 > dn=<regular expression>
665 By "normalized", we mean that all extra spaces have been
666 removed from the entity's DN and commas are used to
667 separate RDN components.
669 Other control factors are also supported.
670 For example, a {{EX:<what>}} can be restricted by a
671 regular expression matching the client's domain name:
673 > domain=<regular expression>
675 or by an entry listed in a DN-valued attribute in the entry to
676 which the access applies:
678 > dnattr=<dn-valued attribute name>
680 The dnattr specification is used to give access to an entry
681 whose DN is listed in an attribute of the entry (e.g., give
682 access to a group entry to whoever is listed as the owner of
686 H3: The access to grant
689 The kind of <access> granted can be one of the following:
692 !block table; colaligns="LRL"; coltags="EX,EX,N"; align=Center; \
693 title="Table 5.4: Access Levels"
694 Level Privileges Description
696 auth =x needed to bind
697 compare =cx needed to compare
698 search =scx needed to apply search filters
699 read =rscx needed to read search results
700 write =wrscx needed to modify/rename
703 Each level implies all lower levels of access. So, for
704 example, granting someone {{EX:write}} access to an entry also
705 grants them {{EX:read}}, {{EX:search}}, {{EX:compare}}, and
706 {{EX:auth}} access. However, one may use the privileges specifier
707 to grant specific permissions.
710 H3: Access Control Evaluation
712 When evaluating whether some requester should be given access to
713 an entry and/or attribute, slapd compares the entry and/or attribute
714 to the {{EX:<what>}} selectors given in the configuration file.
715 For each entry, access controls provided in the database which holds
716 the entry (or the first database if not held in any database) apply
717 first, followed by the global access directives. Within this
718 priority, access directives are examined in the order in which they
719 appear in the config file. Slapd stops with the first {{EX:<what>}}
720 selector that matches the entry and/or attribute. The corresponding
721 access directive is the one slapd will use to evaluate access.
723 Next, slapd compares the entity requesting access to the {{EX:<who>}}
724 selectors within the access directive selected above in the order
725 in which they appear. It stops with the first {{EX:<who>}} selector
726 that matches the requester. This determines the access the entity
727 requesting access has to the entry and/or attribute.
729 Finally, slapd compares the access granted in the selected
730 {{EX:<access>}} clause to the access requested by the client. If
731 it allows greater or equal access, access is granted. Otherwise,
734 The order of evaluation of access directives makes their placement
735 in the configuration file important. If one access directive is
736 more specific than another in terms of the entries it selects, it
737 should appear first in the config file. Similarly, if one {{EX:<who>}}
738 selector is more specific than another it should come first in the
739 access directive. The access control examples given below should
740 help make this clear.
744 H3: Access Control Examples
746 The access control facility described above is quite powerful.
747 This section shows some examples of its use. First, some
750 > access to * by * read
752 This access directive grants read access to everyone.
759 This directive allows users to modify their own entries, allows
760 authenticate, and allows all others to read. Note that only the
761 first {{EX:by <who>}} clause which matches applies. Hence, the
762 anonymous users are granted {{EX:auth}}, not {{EX:read}}. The last
763 clause could just as well have been "{{EX:by users read}}".
765 It is often desirable to restrict operations based upon the level
766 of protection in place. The following shows how security strength
767 factors (SSF) can be used.
770 > by ssf=128 self write
771 > by ssf=64 anonymous auth
772 > by ssf=64 users read
774 This directive allows users to modify their own entries if security
775 protections have of strength 128 or better have been established,
776 allows simple authentication and read access when 64 or better
777 security protections have been established.
779 The following example shows the use of a regular expression
780 to select the entries by DN in two access directives where
781 ordering is significant.
783 > access to dn=".*,dc=example,dc=com"
785 > access to dn=".*,dc=com"
788 Read access is granted to entries under the {{EX:dc=com}}
789 subtree, except for those entries under the {{EX:dc=example,dc=com}}
790 subtree, to which search access is granted. No access is granted to
791 {{EX:dc=com}} as neither access directive matches this DN.
792 If the order of these access directives was reversed, the
793 trailing directive would never be reached, since all
794 {{EX:dc=example,dc=com}} entries are also {{EX:dc=com}} entries.
796 Also note that if no {{EX:access to}} directive matches or
797 no {{EX:by <who>}} clause, {{B:access is denied}}. That is, every
798 {{EX:access to}} directive ends with an implicit {{EX:by * none}}
799 clause and every access list ends with an implicit
800 {{EX:access to * by * none}} directive. Only if no access controls
801 are specified is the {{EX:defaultaccess}} granted.
803 The next example again shows the importance of ordering,
804 both of the access directives and the {{EX:by <who>}} clauses.
805 It also shows the use of an attribute selector to grant access
806 to a specific attribute and various {{EX:<who>}} selectors.
808 > access to dn="(.*,)?dc=example,dc=com" attr=homePhone
810 > by dn="(.*,)?dc=example,dc=com" search
811 > by domain=.*\.example\.com read
812 > access to dn="(.*,)?dc=example,dc=com"
814 > by dn=".*,dc=example,dc=com" search
817 This example applies to entries in the "{{EX:dc=example,dc=com}}"
818 subtree. To all attributes except {{EX:homePhone}}, the entry itself
819 can write them, other {{EX:example.com}} entries can search by them,
820 anybody else has no access (implicit {{EX:by * none}}) excepting for
821 authentication/authorization (which is always done anonymously).
822 The {{EX:homePhone}} attribute is writable by the entry, searchable
823 by other {{EX:example.com}} entries, readable by clients connecting
824 from somewhere in the {{EX:example.com}} domain, and otherwise not
825 readable (implicit {{EX:by * none}}). All other access
826 is denied by the implicit {{EX:access to * by * none}}.
828 Sometimes it is useful to permit a particular DN to add or
829 remove itself from an attribute. For example, if you would like to
830 create a group and allow people to add and remove only
831 their own DN from the member attribute, you could accomplish
832 it with an access directive like this:
834 > access to attr=member,entry
835 > by dnattr=member selfwrite
837 The dnattr {{EX:<who>}} selector says that the access applies to
838 entries listed in the {{EX:member}} attribute. The {{EX:selfwrite}} access
839 selector says that such members can only add or delete their
840 own DN from the attribute, not other values. The addition of
841 the entry attribute is required because access to the entry is
842 required to access any of the entry's attributes.
845 For more details on how to use the {{EX:access}} directive,
846 consult the {{Advanced Access Control}} chapter.
850 H2: Configuration File Example
852 The following is an example configuration file, interspersed
853 with explanatory text. It defines two databases to handle
854 different parts of the {{TERM:X.500}} tree; both are {{TERM:BDB}}
855 database instances. The line numbers shown are provided for
856 reference only and are not included in the actual file. First, the
857 global configuration section:
859 E: 1. # example config file - global configuration section
860 E: 2. include /usr/local/etc/schema/core.schema
861 E: 3. referral ldap://root.openldap.org
862 E: 4. access to * by * read
864 Line 1 is a comment. Line 2 includes another config file
865 which contains {{core}} schema definitions.
866 The {{EX:referral}} directive on line 3
867 means that queries not local to one of the databases defined
868 below will be referred to the LDAP server running on the
869 standard port (389) at the host {{EX:root.openldap.org}}.
871 Line 4 is a global access control. It applies to all
872 entries (after any applicable database-specific access
875 The next section of the configuration file defines a BDB
876 backend that will handle queries for things in the
877 "dc=example,dc=com" portion of the tree. The
878 database is to be replicated to two slave slapds, one on
879 truelies, the other on judgmentday. Indices are to be
880 maintained for several attributes, and the {{EX:userPassword}}
881 attribute is to be protected from unauthorized access.
883 E: 5. # BDB definition for the example.com
885 E: 7. suffix "dc=example,dc=com"
886 E: 8. directory /usr/local/var/openldap-data
887 E: 9. rootdn "cn=Manager,dc=example,dc=com"
889 E: 11. # replication directives
890 E: 12. replogfile /usr/local/var/openldap/slapd.replog
891 E: 13. replica host=slave1.example.com:389
892 E: 14. binddn="cn=Replicator,dc=example,dc=com"
893 E: 15. bindmethod=simple credentials=secret
894 E: 16. replica host=slave2.example.com
895 E: 17. binddn="cn=Replicator,dc=example,dc=com"
896 E: 18. bindmethod=simple credentials=secret
897 E: 19. # indexed attribute definitions
898 E: 20. index uid pres,eq
899 E: 21. index cn,sn,uid pres,eq,approx,sub
900 E: 22. index objectClass eq
901 E: 23. # database access control definitions
902 E: 24. access to attr=userPassword
904 E: 26. by anonymous auth
905 E: 27. by dn="cn=Admin,dc=example,dc=com" write
909 E: 31. by dn="cn=Admin,dc=example,dc=com" write
912 Line 5 is a comment. The start of the database definition is marked
913 by the database keyword on line 6. Line 7 specifies the DN suffix
914 for queries to pass to this database. Line 8 specifies the directory
915 in which the database files will live.
917 Lines 9 and 10 identify the database {{super-user}} entry and associated
918 password. This entry is not subject to access control or size or
919 time limit restrictions.
921 Lines 11 through 18 are for replication. Line 12 specifies the
922 replication log file (where changes to the database are logged -
923 this file is written by slapd and read by slurpd). Lines 13 through
924 15 specify the hostname and port for a replicated host, the DN to
925 bind as when performing updates, the bind method (simple) and the
926 credentials (password) for the binddn. Lines 16 through 18 specify
927 a second replication site. See the {{SECT:Replication with slurpd}}
928 chapter for more information on these directives.
930 Lines 20 through 22 indicate the indices to maintain for various
933 Lines 24 through 32 specify access control for entries in this
934 database. As this is the first database, the controls also apply
935 to entries not held in any database (such as the Root DSE). For
936 all applicable entries, the {{EX:userPassword}} attribute is writable
937 by the entry itself and by the "admin" entry. It may be used for
938 authentication/authorization purposes, but is otherwise not readable.
939 All other attributes are writable by the entry and the "admin"
940 entry, but may be read by all users (authenticated or not).
942 The next section of the example configuration file defines another
943 BDB database. This one handles queries involving the
944 {{EX:dc=example,dc=net}} subtree but is managed by the same entity
945 as the first database. Note that without line 39, the read access
946 would be allowed due to the global access rule at line 4.
948 E: 33. # BDB definition for example.net
950 E: 35. suffix "dc=example,dc=net"
951 E: 36. directory /usr/local/var/openldap-data-net
952 E: 37. rootdn "cn=Manager,dc=example,dc=com"
953 E: 38. index objectClass eq
954 E: 39. access to * by users read