H2: Configuration File Format
-The {{slapd.conf}}(5) file consists three types of configuration
-information: global, backend specific, database specific. Global
+The {{slapd.conf}}(5) file consists of three types of configuration
+information: global, backend specific, and database specific. Global
information is specified first, followed by information associated
with a particular backend type, which is then followed by information
associated with a particular database instance. Global directives can
-be overridden in a backend and/or database directives, backend directives
+be overridden in backend and/or database directives, and backend directives
can be overridden by database directives.
Blank lines and comment lines beginning with a '{{EX:#}}' character
The distribution contains an example configuration file that will
be installed in the {{F: /usr/local/etc/openldap}} directory.
-A number of files containing schema definition (attribute types
+A number of files containing schema definitions (attribute types
and object classes) are also provided in the
{{F: /usr/local/etc/openldap/schema}} directory.
H2: Configuration File Directives
This section details commonly used configuration directives. For
-a complete list, see {{slapd.conf}}(5) manual page. This section
+a complete list, see the {{slapd.conf}}(5) manual page. This section
separates the configuration file directives into global,
backend-specific and data-specific categories, describing each
directive and its default value (if any), and giving an example of
H3: Global Directives
Directives described in this section apply to all backends
-and databases, unless specifically overridden in a backend or
-database definition. Arguments to directives should be replaced
+and databases unless specifically overridden in a backend or
+database definition. Arguments that should be replaced
by actual text are shown in brackets {{EX:<>}}.
H4: defaultaccess { none | compare | search | read | write }
This directive specifies the default access to grant requesters
-when no {{EX:access}} directives have been specified. Access
-levels implies all lesser access levels (e.g., read access
-implies search and compare but no write).
+when no {{EX:access}} directives have been specified. Any given
+access level implies all lesser access levels (e.g., read access
+implies search and compare but not write).
Note: It is recommend that the {{EX:access}} directive be used
to specify access control. See the {{SECT:Access Control}}
H4: idletimeout <integer>
Specify the number of seconds to wait before forcibly closing
-an idle client connections. A idletimeout of 0, the default,
+an idle client connection. An idletimeout of 0, the default,
disables this feature.
This directive specifies the level at which debugging statements
and operation statistics should be syslogged (currently logged to
-the {{syslogd}}(8) {EX:LOG_LOCAL4}} facility). You must have
+the {{syslogd}}(8) {{EX:LOG_LOCAL4}} facility). You must have
configured OpenLDAP {{EX:--enable-debug}} (the default) for this
to work (except for the two statistics levels, which are always
enabled). Log levels are additive. To display what numbers
H3: General Backend Directives
+Directives in this section apply only to the backend in which
+they are defined. They are supported by every type of backend.
+Backend directives apply to all databases instances of the
+same type and, depending on the directive, may be overridden
+by database directives.
+
+H4: backend <type>
+
+This directive marks the beginning of a backend declaration.
+{{EX:<type>}} should be one of the
+supported backend types listed in Table 5.2.
+
+!block table; align=Center; coltags="EX,N"; \
+ title="Table 5.2: Database Backends"
+Types Description
+bdb Berkeley DB transactional backend
+dnssrv DNS SRV backend
+ldbm Lightweight DBM backend
+ldap Lightweight Directory Access Protocol (Proxy) backend
+meta Meta Directory backend
+monitor Monitor backend
+passwd Provides read-only access to {{passwd}}(5)
+perl Perl Programmable backend
+shell Shell (extern program) backend
+sql SQL Programmable backend
+tcl TCL Programmable backend
+!endblock
+
+\Example:
+
+> backend bdb
+
+This marks the beginning of a new {{TERM:BDB}} backend
+definition.
+
+
H3: General Database Directives
-Directives in this section only apply to the database in which
+Directives in this section apply only to the database in which
they are defined. They are supported by every type of database.
-H4: database <databasetype>
+H4: database <type>
-This directive marks the beginning of a new database instance
-definition. <databasetype> should be one of ldbm, shell, or
-passwd, depending on which backend will serve the
-database.
+This directive marks the beginning of a database instance
+declaration.
+{{EX:<type>}} should be one of the
+supported backend types listed in Table 5.2.
\Example:
-> database ldbm
+> database bdb
-This marks the beginning of a new LDBM backend database
-instance definition.
+This marks the beginning of a new {{TERM:BDB}} database instance
+declaration.
H4: readonly { on | off }
{{EX:credentials}} parameters.
Kerberos authentication is deprecated in favor of SASL authentication
-mechanisms, in particular the {EX:KERBEROS_V4}} and {{EX:GSSAPI}}
+mechanisms, in particular the {{EX:KERBEROS_V4}} and {{EX:GSSAPI}}
mechanisms. Kerberos authentication requires {{EX:binddn}} and
{{EX:srvtab}} parameters.
respectively. The {{EX:authzid}} parameter may be used to specify
an authorization identity.
-See the {{SECT:Replication}} chapter for more information on how to
-use this directive.
+See the chapter entitled {{SECT:Replication with slurpd}} for more
+information on how to use this directive.
H4: replogfile <filename>
slurpd is not running. In this case, you will need to periodically
truncate the file, since it will grow indefinitely otherwise.
-See the {{SECT:Replication}} chapter for more information on how to
-use this directive.
+See the chapter entitled {{SECT:Replication with slurpd}} for more
+information on how to use this directive.
H4: rootdn <dn>
This directive specifies the DN that is not subject to
access control or administrative limit restrictions for
operations on this database. The DN need not refer to
-an entry in the directory. The DN may refer to a SASL
-identity.
+an entry in this database or even in the directory. The
+DN may refer to a SASL identity.
Entry-based Example:
-> rootdn "cn=Manager, dc=example, dc=com"
+> rootdn "cn=Manager,dc=example,dc=com"
SASL-based Example:
-> rootdn "uid=root@EXAMPLE.COM"
+> rootdn "uid=root,cn=example.com,cn=digest-md5,cn=auth"
+
+See the {{SECT:SASL Authentication}} section for information on
+SASL authentication identities.
H4: rootpw <password>
-This directive specifies a password for the DN given above that
-will always work, regardless of whether an entry with the given
-DN exists or has a password.
-This directive is deprecated in favor of SASL based authentication.
+This directive can be used to specifies a password for the DN for
+the rootdn.
\Example:
> rootpw secret
+It is also permissible to provide hash of the password in
+RFC 2307 form. {{slappasswd}}(8) may be used to generate
+the password hash.
+
+\Example:
+
+> rootpw {SSHA}ZKKuqbEKJfKSXhUbHG3fG8MDn9j1v4QN
+
+The hash was generated using the command {{EX:slappasswd -s secret}}.
+
+This directive is deprecated in favor of SASL based authentication.
+
H4: suffix <dn suffix>
\Example:
-> suffix "dc=example, dc=com"
+> suffix "dc=example,dc=com"
-Queries with a DN ending in "dc=example, dc=com"
+Queries with a DN ending in "dc=example,dc=com"
will be passed to this backend.
-Note: when the backend to pass a query to is selected, slapd
+Note: When the backend to pass a query to is selected, slapd
looks at the suffix line(s) in each database definition in the
order they appear in the file. Thus, if one database suffix is a
prefix of another, it must appear after it in the config file.
H4: updatedn <dn>
-This directive is only applicable in a slave slapd. It specifies the
-DN allowed to make changes to the replica. This may be the
-the DN slurpd binds as when making changes to the replica or
-the DN associated with a SASL identity.
+This directive is only applicable in a slave slapd. It specifies
+the DN allowed to make changes to the replica. This may be the DN
+{{slurpd}}(8) binds as when making changes to the replica or the DN
+associated with a SASL identity.
Entry-based Example:
-> updatedn "cn=Update Daemon, dc=example, dc=com"
+> updatedn "cn=Update Daemon,dc=example,dc=com"
SASL-based Example:
-> updatedn "uid=slurpd@EXAMPLE.COM"
+> updatedn "uid=slurpd,cn=example.com,cn=digest-md5,cn=auth"
-See the {{SECT:Replication}} chapter for more information on how to
-use this directive.
+See the {{SECT:Replication with slurpd}} chapter for more information
+on how to use this directive.
H4: updateref <URL>
\Example:
-> update ldap://master.example.net
+> updateref ldap://master.example.net
+
+
+H3: BDB Database Directives
+
+Directives in this category only apply to a {{TERM:BDB}} database.
+That is, they must follow a "database bdb" line and come before any
+subsequent "backend" or "database" line. For a complete reference
+of BDB configuration directives, see {{slapd-bdb}}(5).
+H4: directory <directory>
+
+This directive specifies the directory where the BDB files
+containing the database and associated indices live.
+
+\Default:
-H3: LDBM Backend-Specific Directives
+> directory /usr/local/var/openldap-data
-Directives in this category only apply to the LDBM backend
-database. That is, they must follow a "database ldbm" line and
-come before any other "database" line.
+
+H3: LDBM Database Directives
+
+Directives in this category only apply to a {{TERM:LDBM}} database.
+That is, they must follow a "database ldbm" line and come before
+any subsequent "backend" or "database" line. For a complete reference
+of LDBM configuration directives, see {{slapd-ldbm}}(5).
H4: cachesize <integer>
underlying database method, this directive is ignored without
comment. Increasing this number uses more memory but can
cause a dramatic performance increase, especially during
-modifies or when building indexes.
+modifies or when building indices.
\Default:
H4: dbnosync
-This option causes on-disk database contents not be immediately
+This option causes on-disk database contents to not be immediately
synchronized with in memory changes upon change. Enabling this option
-may improve performance at the expense of data security.
+may improve performance at the expense of data integrity.
H4: directory <directory>
This directive specifies the directory where the LDBM files
-containing the database and associated indexes live.
+containing the database and associated indices live.
\Default:
-> directory /usr/local/var/openldap-ldbm
+> directory /usr/local/var/openldap-data
H4: index {<attrlist> | default} [pres,eq,approx,sub,none]
-This directive specifies the indexes to maintain for the given
+This directive specifies the indices to maintain for the given
attribute. If only an {{EX:<attrlist>}} is given, the default
-indexes are maintained.
-
+indices are maintained.
\Example:
> index default pres,eq
-> index objectClass,uid
-> index cn,sn eq,sub,approx
+> index uid
+> index cn,sn pres,eq,sub
+> index objectClass eq
+
+The first line sets the default set of indices to maintain to
+present and equality. The second line causes the default (pres,eq)
+set of indices to be maintained for the {{EX:uid}} attribute type.
+The third line causes present, equality, and substring indices to
+be maintained for {{EX:cn}} and {{EX:sn}} attribute types. The
+fourth line causes an equality index for the {{EX:objectClass}}
+attribute type.
+
+By default, no indices are maintained. It is generally advised
+that minimally an equality index upon objectClass be maintained.
+
+> index objectClass eq
+
-The first line sets the default to indices to maintain to present
-and equality. The second line causes the default (pres,eq) set
-of indices to be maintained for {{EX:objectClass}} and {{EX:uid}} attribute
-types. The third line causes equality, substring, and approximate
-filters to be maintained for {{EX:cn}} and {{EX:sn}} attribute types.
H4: mode <integer>
> mode 0600
-
-H3: Other Backend and Databases
-
-{{slapd}}(8) supports a number of other backend database types.
-
-!block table; align=Center; coltags="EX,N"; \
- title="Table 5.2: Backend Database Types"
-Types Description
-passwd Provides read-only access to {{F:/etc/passwd}}
-shell Shell (extern program) backend
-sql SQL Programmable backend
-!endblock
-
-See {{slapd.conf}}(5) for details.
-
-
-
H2: Access Control
Access to slapd entries and attributes is controlled by the
> <access directive> ::= access to <what>
> [by <who> <access> <control>]+
-> <what> ::= * | [ dn[.<target style>]=<regex>]
+> <what> ::= * | [ dn[.<dn style>]=<regex>]
> [filter=<ldapfilter>] [attrs=<attrlist>]
-> <target style> ::= regex | base | one | subtree | children
+> <dn style> ::= regex | exact | base | one | subtree | children
> <attrlist> ::= <attr> | <attr> , <attrlist>
> <attr> ::= <attrname> | entry | children
> <who> ::= [* | anonymous | users | self |
-> dn[.<subject style>]=<regex>]
+> dn[.<dn style>]=<regex>]
> [dnattr=<attrname> ]
> [group[/<objectclass>[/<attrname>][.<basic style>]]=<regex> ]
> [peername[.<basic style>]=<regex>]
> [sockurl[.<basic style>]=<regex>]
> [set=<setspec>]
> [aci=<attrname>]
-> <subject style> ::= regex | exact | base | one | subtree | children
> <basic style> ::= regex | exact
> <access> ::= [self]{<level>|<priv>}
> <level> ::= none | auth | compare | search | read | write
entities are granted access, and the {{EX:<access>}} part specifies
the access granted. Multiple {{EX:<who> <access> <control>}} triplets
are supported, allowing many entities to be granted different
-access to the same set of entries and attributes.
+access to the same set of entries and attributes. Not all of these
+access control options are described here; for more details see
+the {{slapd.access}}(5) man page.
H3: What to control access to
> dn=<regular expression>
-Note: The DN pattern specified should be "normalized",
-meaning that there should be no extra spaces, and commas
-should be used to separate components. An example
-normalized DN is "cn=Babs Jensen,dc=example,dc=com".
-An example of a non-normalized DN is
-"cn=Babs Jensen; dc=example, dc=com".
+Note: The DN pattern specified should be "normalized" to the RFC2253
+restricted DN form. In particular, there should be no extra spaces
+and commas should be used to separate components. An example
+normalized DN is "{{EX:cn=Babs Jensen,dc=example,dc=com}}". An
+example of a non-normalized DN is "{{EX:cn=Babs Jensen; dc=example;
+dc=com}}".
Or, entries may be selected by a filter matching some
attribute(s) in the entry:
{{EX:entry}} attribute is also required. The complete examples at
the end of this section should help clear things up.
-Lastly, there is a special entry selector {{EX:"*"}} is used to
+Lastly, there is a special entry selector {{EX:"*"}} that is used to
select any entry. It is used when no other {{EX:<what>}}
selector has been provided. It's equivalent to "{{EX:dn=.*}}"
The <who> part identifies the entity or entities being granted
access. Note that access is granted to "entities" not "entries."
-The follow table summaries entity specifiers:
+The following table summarizes entity specifiers:
!block table; align=Center; coltags="EX,N"; \
title="Table 5.3: Access Entity Specifiers"
> dn=<regular expression>
By "normalized", we mean that all extra spaces have been
-removed from the entities DN and commas are used to
+removed from the entity's DN and commas are used to
separate RDN components.
-Other control factors forms are also supported.
+Other control factors are also supported.
For example, a {{EX:<what>}} can be restricted by a
-regular expression matching the client's IP address or domain name:
+regular expression matching the client's domain name:
-> addr=<regular expression>
> domain=<regular expression>
or by an entry listed in a DN-valued attribute in the entry to
!block table; colaligns="LRL"; coltags="EX,EX,N"; align=Center; \
title="Table 5.4: Access Levels"
-Level Privledges Description
+Level Privileges Description
none no access
auth =x needed to bind
compare =cx needed to compare
!endblock
Each level implies all lower levels of access. So, for
-example, granting someone write access to an entry also
-grants them read, search, compare, and auth access. However,
-one may use the privledges specify to grant specific permissions.
+example, granting someone {{EX:write}} access to an entry also
+grants them {{EX:read}}, {{EX:search}}, {{EX:compare}}, and
+{{EX:auth}} access. However, one may use the privileges specifier
+to grant specific permissions.
H3: Access Control Evaluation
-When evaluating whether some requester should be given
-access to an entry and/or attribute, slapd compares the entry
-and/or attribute to the {{EX:<what>}} selectors given in the
-configuration file. Access directives local to the current
-database are examined first, followed by global access
-directives. Within this priority, access directives are
-examined in the order in which they appear in the config file.
-Slapd stops with the first {{EX:<what>}} selector that matches the
-entry and/or attribute. The corresponding access directive is
-the one slapd will use to evaluate access.
-
-Next, slapd compares the entity requesting access to the
-{{EX:<who>}} selectors within the access directive selected above,
-in the order in which they appear. It stops with the first {{EX:<who>}}
-selector that matches the requester. This determines the
-access the entity requesting access has to the entry and/or
-attribute.
+When evaluating whether some requester should be given access to
+an entry and/or attribute, slapd compares the entry and/or attribute
+to the {{EX:<what>}} selectors given in the configuration file.
+For each entry, access controls provided in the database which holds
+the entry (or the first database if not held in any database) apply
+first, followed by the global access directives. Within this
+priority, access directives are examined in the order in which they
+appear in the config file. Slapd stops with the first {{EX:<what>}}
+selector that matches the entry and/or attribute. The corresponding
+access directive is the one slapd will use to evaluate access.
+
+Next, slapd compares the entity requesting access to the {{EX:<who>}}
+selectors within the access directive selected above in the order
+in which they appear. It stops with the first {{EX:<who>}} selector
+that matches the requester. This determines the access the entity
+requesting access has to the entry and/or attribute.
Finally, slapd compares the access granted in the selected
-{{EX:<access>}} clause to the access requested by the client. If it
-allows greater or equal access, access is granted. Otherwise,
+{{EX:<access>}} clause to the access requested by the client. If
+it allows greater or equal access, access is granted. Otherwise,
access is denied.
-The order of evaluation of access directives makes their
-placement in the configuration file important. If one access
-directive is more specific than another in terms of the entries
-it selects, it should appear first in the config file. Similarly, if
-one {{EX:<who>}} selector is more specific than another it should
-come first in the access directive. The access control
-examples given below should help make this clear.
+The order of evaluation of access directives makes their placement
+in the configuration file important. If one access directive is
+more specific than another in terms of the entries it selects, it
+should appear first in the config file. Similarly, if one {{EX:<who>}}
+selector is more specific than another it should come first in the
+access directive. The access control examples given below should
+help make this clear.
> by anonymous auth
> by * read
-This directive allows users to modify their own entries,
-allows authenticate, and allows authenticated users to read.
-Note that only the first {{EX:by <who>}} clause which matches applies.
-Hence, the anonymous users are granted {{EX:auth}}, not {{EX:read}}.
-The last clause just as well have been "{{EX:by users read}}".
+This directive allows users to modify their own entries, allows
+authenticate, and allows all others to read. Note that only the
+first {{EX:by <who>}} clause which matches applies. Hence, the
+anonymous users are granted {{EX:auth}}, not {{EX:read}}. The last
+clause could just as well have been "{{EX:by users read}}".
+
+It is often desirable to restrict operations based upon the level
+of protection in place. The following shows how security strength
+factors (SSF) can be used.
+
+> access to *
+> by ssf=128 self write
+> by ssf=64 anonymous auth
+> by ssf=64 users read
+
+This directive allows users to modify their own entries if security
+protections have of strength 128 or better have been established,
+allows simple authentication and read access when 64 or better
+security protections have been established.
The following example shows the use of a regular expression
to select the entries by DN in two access directives where
Also note that if no {{EX:access to}} directive matches or
no {{EX:by <who>}} clause, {{B:access is denied}}. That is, every
-{{EX:access to}} directive ends with a implicit {{EX:by * none}}
-clause and access list itself ends with {{EX:access to * by * none}}
-directive. Only if no access controls are specified, is the
-{{EX:defaultaccess}} granted.
+{{EX:access to}} directive ends with an implicit {{EX:by * none}}
+clause and every access list ends with an implicit
+{{EX:access to * by * none}} directive. Only if no access controls
+are specified is the {{EX:defaultaccess}} granted.
The next example again shows the importance of ordering,
both of the access directives and the {{EX:by <who>}} clauses.
> by dn=".*,dc=example,dc=com" search
> by anonymous auth
-This example applies to entries in the "{{EX:dc=example, dc=com}}"
+This example applies to entries in the "{{EX:dc=example,dc=com}}"
subtree. To all attributes except {{EX:homePhone}}, the entry itself
can write them, other {{EX:example.com}} entries can search by them,
-anybody else has no access ((implicit {{EX:by * none}}) excepting for
+anybody else has no access (implicit {{EX:by * none}}) excepting for
authentication/authorization (which is always done anonymously).
The {{EX:homePhone}} attribute is writable by the entry, searchable
by other {{EX:example.com}} entries, readable by clients connecting
The following is an example configuration file, interspersed
with explanatory text. It defines two databases to handle
-different parts of the {{TERM:X.500}} tree; both are {{TERM:LDBM}}
+different parts of the {{TERM:X.500}} tree; both are {{TERM:BDB}}
database instances. The line numbers shown are provided for
reference only and are not included in the actual file. First, the
global configuration section:
E: 3. referral ldap://root.openldap.org
E: 4. access to * by * read
-Line 1 is a comment. Lines 2 include another config file
-which containing {{core}} schema definitions.
+Line 1 is a comment. Line 2 includes another config file
+which contains {{core}} schema definitions.
The {{EX:referral}} directive on line 3
means that queries not local to one of the databases defined
below will be referred to the LDAP server running on the
standard port (389) at the host {{EX:root.openldap.org}}.
-Line 4 is a global access control. It is used only if
-no database access controls match or when the target
-objects are not under the control of any database (such as
-the Root DSE).
+Line 4 is a global access control. It applies to all
+entries (after any applicable database-specific access
+controls).
-The next section of the configuration file defines an LDBM
+The next section of the configuration file defines a BDB
backend that will handle queries for things in the
"dc=example,dc=com" portion of the tree. The
database is to be replicated to two slave slapds, one on
-truelies, the other on judgmentday. Indexes are to be
+truelies, the other on judgmentday. Indices are to be
maintained for several attributes, and the {{EX:userPassword}}
attribute is to be protected from unauthorized access.
-E: 5. # ldbm definition for the example.com
-E: 6. database ldbm
-E: 7. suffix "dc=example, dc=com"
-E: 8. directory /usr/local/var/openldap
-E: 9. rootdn "cn=Manager, dc=example, dc=com"
+E: 5. # BDB definition for the example.com
+E: 6. database bdb
+E: 7. suffix "dc=example,dc=com"
+E: 8. directory /usr/local/var/openldap-data
+E: 9. rootdn "cn=Manager,dc=example,dc=com"
E: 10. rootpw secret
E: 11. # replication directives
E: 12. replogfile /usr/local/var/openldap/slapd.replog
E: 13. replica host=slave1.example.com:389
-E: 14. binddn="cn=Replicator, dc=example, dc=com"
+E: 14. binddn="cn=Replicator,dc=example,dc=com"
E: 15. bindmethod=simple credentials=secret
E: 16. replica host=slave2.example.com
-E: 17. binddn="cn=Replicator, dc=example, dc=com"
+E: 17. binddn="cn=Replicator,dc=example,dc=com"
E: 18. bindmethod=simple credentials=secret
E: 19. # indexed attribute definitions
E: 20. index uid pres,eq
E: 21. index cn,sn,uid pres,eq,approx,sub
E: 22. index objectClass eq
-E: 23. # ldbm access control definitions
+E: 23. # database access control definitions
E: 24. access to attr=userPassword
E: 25. by self write
E: 26. by anonymous auth
E: 28. by * none
E: 29. access to *
E: 30. by self write
-E: 31. by anonymous auth
-E: 32. by dn="cn=Admin,dc=example,dc=com" write
-E: 33. by * read
-
-Line 5 is a comment. The start of the database definition is
-marked by the database keyword on line 6. Line 7 specifies
-the DN suffix for queries to pass to this database. Line 8
-specifies the directory in which the database files will live.
-
-Lines 9 and 10 identify the database "super user" entry and
-associated password. This entry is not subject to access
-control or size or time limit restrictions.
-
-Lines 11 through 18 are for replication. Line 11 specifies the
-replication log file (where changes to the database are logged
-\- this file is written by slapd and read by slurpd). Lines 12
-through 14 specify the hostname and port for a replicated
-host, the DN to bind as when performing updates, the bind
-method (simple) and the credentials (password) for the
-binddn. Lines 15 through 18 specify a second replication site.
-See the {{SECT:Replication with slurpd}} chapter for more
-information on these directives.
-
-Lines 20 through 22 indicate the indexes to maintain for
-various attributes.
-
-Lines 24 through 33 specify access control for entries in the
-database. For all entries, the {{EX:userPassword}} attribute is
-writable by the entry and the "admin" entry, may be used for
-authentication/authorization purposes, but is otherwise not
-readable. All other attributes by writable by the entry and
-the "admin" entry, may be used for authentication/authorization
-purposes, but may be read by authenticated users.
-
-The next section of the example configuration file defines
-another LDBM database. This one handles queries involving
-the {{EX:dc=example,dc=net}} subtree. Note that without
-line 38, the read access would be allowed due to the
-global access rule at line 4.
-
-E: 33. # ldbm definition for example.net
-E: 34. database ldbm
-E: 35. suffix "dc=example, dc=net"
-E: 36. directory /usr/local/var/ldbm-example-net
-E: 37. rootdn "cn=Manager, dc=example, dc=com"
-E: 38. access to * by users read
+E: 31. by dn="cn=Admin,dc=example,dc=com" write
+E: 32. by * read
+
+Line 5 is a comment. The start of the database definition is marked
+by the database keyword on line 6. Line 7 specifies the DN suffix
+for queries to pass to this database. Line 8 specifies the directory
+in which the database files will live.
+
+Lines 9 and 10 identify the database {{super-user}} entry and associated
+password. This entry is not subject to access control or size or
+time limit restrictions.
+
+Lines 11 through 18 are for replication. Line 12 specifies the
+replication log file (where changes to the database are logged -
+this file is written by slapd and read by slurpd). Lines 13 through
+15 specify the hostname and port for a replicated host, the DN to
+bind as when performing updates, the bind method (simple) and the
+credentials (password) for the binddn. Lines 16 through 18 specify
+a second replication site. See the {{SECT:Replication with slurpd}}
+chapter for more information on these directives.
+
+Lines 20 through 22 indicate the indices to maintain for various
+attributes.
+
+Lines 24 through 32 specify access control for entries in this
+database. As this is the first database, the controls also apply
+to entries not held in any database (such as the Root DSE). For
+all applicable entries, the {{EX:userPassword}} attribute is writable
+by the entry itself and by the "admin" entry. It may be used for
+authentication/authorization purposes, but is otherwise not readable.
+All other attributes are writable by the entry and the "admin"
+entry, but may be read by all users (authenticated or not).
+
+The next section of the example configuration file defines another
+BDB database. This one handles queries involving the
+{{EX:dc=example,dc=net}} subtree but is managed by the same entity
+as the first database. Note that without line 39, the read access
+would be allowed due to the global access rule at line 4.
+
+E: 33. # BDB definition for example.net
+E: 34. database bdb
+E: 35. suffix "dc=example,dc=net"
+E: 36. directory /usr/local/var/openldap-data-net
+E: 37. rootdn "cn=Manager,dc=example,dc=com"
+E: 38. index objectClass eq
+E: 39. access to * by users read
projects / openldap / blobdiff