# $OpenLDAP$
-# Copyright 1999-2000, The OpenLDAP Foundation, All Rights Reserved.
+# Copyright 1999-2007 The OpenLDAP Foundation, All Rights Reserved.
# COPYING RESTRICTIONS APPLY, see COPYRIGHT.
H1: The slapd Configuration File
-Once the software has been built and installed, you are ready to configure it
-for use at your site. All slapd runtime configuration is accomplished through
-the {{I:slapd.conf}}(5) file, normally installed in the
+Once the software has been built and installed, you are ready
+to configure {{slapd}}(8) for use at your site. The slapd
+runtime configuration is primarily accomplished through the
+{{slapd.conf}}(5) file, normally installed in the
{{EX:/usr/local/etc/openldap}} directory.
-An alternate configuration file can be specified via a
-command-line option to slapd or slurpd (see Sections 5 and 8,
-respectively). This section describes the general format of the config file,
-followed by a detailed description of each config file directive.
-
+An alternate configuration file location can be specified via a command-line
+option to {{slapd}}(8). This chapter describes the general format
+of the {{slapd.conf}}(5) configuration file, followed by a detailed
+description of commonly used config file directives.
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
are ignored. If a line begins with white space, it is considered a
-continuation of the previous line. The general format of slapd.conf is
-as follows:
+continuation of the previous line (even if the previous line is a
+comment).
+
+The general format of slapd.conf is as follows:
> # global configuration directives
> <global config directives>
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,
-unless specifically overridden in a backend definition.
-Arguments to directives should be replaced by actual text are
-shown in brackets {{EX:<>}}.
+Directives described in this section apply to all backends
+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: access to <what> [ by <who> <accesslevel> <control> ]+
+H4: access to <what> [ by <who> [<accesslevel>] [<control>] ]+
-This directive grants access (specified by <accesslevel>) to a
-set of entries and/or attributes (specified by <what>) by one or
-more requesters (specified by <who>). See Section 5.3 on
-access control for more details and examples.
+This directive grants access (specified by <accesslevel>) to a set
+of entries and/or attributes (specified by <what>) by one or more
+requestors (specified by <who>). See the {{SECT:The access
+Configuration Directive}} section of this chapter for a summary of
+basic usage.
+!if 0
+More details discussion of this directive can be found in the
+{{SECT:Advanced Access Control}} chapter.
+!endif
-H4: attributetype <RFC2252 Attribute Type Description>
+Note: If no {{EX:access}} directives are specified, the default
+access control policy, {{EX:access to * by * read}}, allows all
+both authenticated and anonymous users read access.
-This directive defines an attribute type.
-H4: defaultaccess { none | compare | search | read | write }
+H4: attributetype <{{REF:RFC4512}} Attribute Type Description>
-This directive specifies the default access to grant requesters
-not matched by any other access line (see Section 5.3). Note
-that an access level implies all lesser access levels (e.g.,
-write access implies read, search and compare).
+This directive defines an attribute type.
+Please see the {{SECT:Schema Specification}} chapter
+for information regarding how to use this directive.
-\Default:
+H4: idletimeout <integer>
+
+Specify the number of seconds to wait before forcibly closing
+an idle client connection. An idletimeout of 0, the default,
+disables this feature.
-E: defaultaccess read
H4: include <filename>
This directive specifies that slapd should read additional
configuration information from the given file before continuing
with the next line of the current file. The included file should
-follow the normal slapd config file format.
+follow the normal slapd config file format. The file is commonly
+used to include files containing schema specifications.
Note: You should be careful when using this directive - there is
no small limit on the number of nested include directives, and no
H4: loglevel <integer>
This directive specifies the level at which debugging statements
-and operation statistics should be syslogged (currently
-logged to the {{syslogd}}(8) LOG_LOCAL4 facility). You must
-have compiled slapd with -DLDAP_DEBUG for this to work
-(except for the two statistics levels, which are always enabled).
-Log levels are additive. To display what numbers correspond
-to what kind of debugging, invoke slapd with the ? flag or
-consult the table below. The possible values for <integer> are:
+and operation statistics should be syslogged (currently logged to
+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
+correspond to what kind of debugging, invoke slapd with {{EX:-?}}
+or consult the table below. The possible values for <integer> are:
!block table; colaligns="RL"; align=Center; \
- title="Table 5.1: Debugging Levels"
+ title="Table 6.1: Debugging Levels"
Level Description
-1 enable all debugging
0 no debugging
E: loglevel 256
-H4: objectclass <RFC2252 Object Class Description>
+
+H4: objectclass <{{REF:RFC4512}} Object Class Description>
This directive defines an object class.
+Please see the {{SECT:Schema Specification}} chapter for
+information regarding how to use this directive.
+
H4: referral <URI>
only going to know how to handle simple LDAP URLs that
contain a host part and optionally a distinguished name part.
-H4: schemacheck { on | off }
-
-This directive turns schema checking on or off. If schema
-checking is on, entries added or modified through LDAP operations
-will be checked to ensure they obey the schema rules implied
-by their object class(es) as defined by the corresponding objectclass
-directive(s). If schema checking is off this check is not done.
-
-\Default:
-
-> schemacheck on
H4: sizelimit <integer>
> sizelimit 500
-H4: srvtab <filename>
-
-This directive specifies the srvtab file in which slapd can find the
-Kerberos keys necessary for authenticating clients using
-Kerberos. This directive is only meaningful if you are using
-Kerberos authentication, which must be enabled at compile
-time by including the appropriate definitions in the
-{{EX:Make-common}} file.
-
-\Default:
-
-> srvtab /etc/srvtab
-
H4: timelimit <integer>
This directive specifies the maximum number of seconds (in real
H3: General Backend Directives
-H3: General Database 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 6.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
+hdb Hierarchical variant of bdb 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
+!endblock
-Directives in this section only apply to the database in which
-they are defined. They are supported by every type of database.
+\Example:
-H4: database <databasetype>
+> backend bdb
-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 marks the beginning of a new {{TERM:BDB}} backend
+definition.
-\Example:
-> database ldbm
+H3: General Database Directives
-This marks the beginning of a new LDBM backend database
-instance definition.
+Directives in this section apply only to the database in which
+they are defined. They are supported by every type of database.
-H4: lastmod { on | off }
+H4: database <type>
-This directive controls whether slapd will automatically maintain
-the modifiersName, modifyTimestamp, creatorsName, and
-createTimestamp attributes for entries.
+This directive marks the beginning of a database instance
+declaration.
+{{EX:<type>}} should be one of the
+supported backend types listed in Table 6.2.
-\Default:
+\Example:
+
+> database bdb
+
+This marks the beginning of a new {{TERM:BDB}} database instance
+declaration.
-> lastmod on
H4: readonly { on | off }
> readonly off
-H4: replica
-
-> replica host=<hostname>[:<port>]
-> "binddn=<DN>"
-> [bindmethod={ simple | kerberos }]
-> [credentials=<password>]
-> [srvtab=<filename>]
-
-This directive specifies a replication site for this database. The
-{{EX:host=}} parameter specifies a host and optionally a port where
-the slave slapd instance can be found. Either a domain name
-or IP address may be used for <hostname>. If <port> is not
-given, the standard LDAP port number (389) is used.
-The {{EX:binddn=}} parameter gives the DN to bind as for updates to
-the slave slapd. It should be a DN which has read/write
-access to the slave slapd's database, typically given as a
-{{EX:rootdn}} in the slave's config file. It must also match the
-updatedn directive in the slave slapd's config file. Since DNs are
-likely to contain embedded spaces, the entire {{EX:"binddn=<DN>"}}
-string should be enclosed in double quotes.
+H4: rootdn <DN>
-The {{EX:bindmethod}} is either simple or kerberos, depending on
-whether simple password-based authentication or kerberos
-authentication is to be used when connecting to the slave
-slapd. Simple authentication requires a valid password be
-given. Kerberos authentication requires a valid srvtab file.
+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 this database or even in the directory. The
+DN may refer to a SASL identity.
-The {{EX:credentials=}} parameter, which is only required if using
-simple authentication, gives the password for {{EX:binddn}} on the
-slave slapd.
+Entry-based Example:
-The {{EX:srvtab=}} parameter, which is only required if using
-kerberos, specifies the filename which holds the kerberos key
-for the slave slapd. If omitted, {{F:/etc/srvtab}} is used.
+> rootdn "cn=Manager,dc=example,dc=com"
-See Section 10 for more details on replication.
+SASL-based Example:
-H4: replogfile <filename>
+> rootdn "uid=root,cn=example.com,cn=digest-md5,cn=auth"
-This directive specifies the name of the replication log file to
-which slapd will log changes. The replication log is typically
-written by slapd and read by slurpd. Normally, this directive is
-only used if slurpd is being used to replicate the database.
-However, you can also use it to generate a transaction log, if
-slurpd is not running. In this case, you will need to periodically
-truncate the file, since it will grow indefinitely otherwise.
+See the {{SECT:SASL Authentication}} section for information on
+SASL authentication identities.
-See Section 10 for more details on replication.
-H4: rootdn <dn>
+H4: rootpw <password>
-This directive specifies the DN of an entry that is not subject to
-access control or administrative limit restrictions for
-operations on this database.
+This directive can be used to specifies a password for the DN for
+the rootdn (when the rootdn is set to a DN within the database).
\Example:
-> rootdn "cn=Manager, dc=example, dc=com"
-
-H4: rootkrbname <kerberosname>
+> rootpw secret
-This directive specifies a kerberos name for the DN given above
-that will always work, regardless of whether an entry with the
-given DN exists or has a {{EX:krbName}} attribute. This directive is
-useful when creating a database and also when using slurpd
-to provide replication service (see Section 10).
+It is also permissible to provide hash of the password in {{REF:RFC2307}}
+form. {{slappasswd}}(8) may be used to generate the password hash.
\Example:
-> rootkrbname admin@EXAMPLE.COM
+> rootpw {SSHA}ZKKuqbEKJfKSXhUbHG3fG8MDn9j1v4QN
-H4: rootpw <password>
+The hash was generated using the command {{EX:slappasswd -s secret}}.
-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 useful when
-creating a database and also when using slurpd to provide
-replication service (see Section 10).
-
-\Example:
-
-> rootpw secret
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 (typically, this is
-the DN slurpd binds as when making changes to the replica).
-
-
-
-H3: LDBM Backend-Specific Directives
-
-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.
-
-H4: cachesize <integer>
-
-This directive specifies the size in entries of the in-memory
-cache maintained by the LDBM backend database instance.
-
-\Default:
-
-> cachesize 1000
-
-
-H4: dbcachesize <integer>
-
-This directive specifies the size in bytes of the in-memory cache
-associated with each open index file. If not supported by the
-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.
-
-\Default:
-
-> dbcachesize 100000
-
-
-H4: directory <directory>
-
-This directive specifies the directory where the LDBM files
-containing the database and associated indexes live.
-
-\Default:
-
-> directory /usr/local/var/openldap-ldbm
-
-
-H4: index {<attrlist> | default} [pres,eq,approx,sub,none]
-
-This directive specifies the indexes to maintain for the given
-attribute. If only an <attrlist> is given, all possible indexes are
-maintained.
-
-\Example:
-
-> index default pres,eq
-> index objectClass,uid
-> index cn,sn eq,sub,approx
-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 objectClass and uid attribute
-types. The third line causes equality, substring, and approximate
-filters to be maintained for cn and sn attribute types.
-
-H4: mode <integer>
-
-This directive specifies the file protection mode that newly
-created database index files should have.
-
-\Default:
-
-> mode 0600
-
-
-
-H3: Shell Backend-Specific Directives
-
-> bind <pathname>
-> unbind <pathname>
-> search <pathname>
-> compare <pathname>
-> modify <pathname>
-> modrdn <pathname>
-> add <pathname>
-> delete <pathname>
-> abandon <pathname>
-
-These directives specify the pathname of the command to
-execute in response to the given LDAP operation. The
-command given should understand and follow the input/output
-conventions described in Appendix B.
+H4: syncrepl
+
+> syncrepl rid=<replica ID>
+> provider=ldap[s]://<hostname>[:port]
+> [type=refreshOnly|refreshAndPersist]
+> [interval=dd:hh:mm:ss]
+> [retry=[<retry interval> <# of retries>]+]
+> searchbase=<base DN>
+> [filter=<filter str>]
+> [scope=sub|one|base]
+> [attrs=<attr list>]
+> [attrsonly]
+> [sizelimit=<limit>]
+> [timelimit=<limit>]
+> [schemachecking=on|off]
+> [bindmethod=simple|sasl]
+> [binddn=<DN>]
+> [saslmech=<mech>]
+> [authcid=<identity>]
+> [authzid=<identity>]
+> [credentials=<passwd>]
+> [realm=<realm>]
+> [secprops=<properties>]
+
+
+This directive specifies the current database as a replica of the
+master content by establishing the current {{slapd}}(8) as a
+replication consumer site running a syncrepl replication engine.
+The master database is located at the replication provider site
+specified by the {{EX:provider}} parameter. The replica database is
+kept up-to-date with the master content using the LDAP Content
+Synchronization protocol. See {{REF:RFC4533}}
+for more information on the protocol.
+
+The {{EX:rid}} parameter is used for identification of the current
+{{EX:syncrepl}} directive within the replication consumer server,
+where {{EX:<replica ID>}} uniquely identifies the syncrepl specification
+described by the current {{EX:syncrepl}} directive. {{EX:<replica ID>}}
+is non-negative and is no more than three decimal digits in length.
+
+The {{EX:provider}} parameter specifies the replication provider site
+containing the master content as an LDAP URI. The {{EX:provider}}
+parameter specifies a scheme, a host and optionally a port where the
+provider slapd instance can be found. Either a domain name or IP
+address may be used for <hostname>. Examples are
+{{EX:ldap://provider.example.com:389}} or {{EX:ldaps://192.168.1.1:636}}.
+If <port> is not given, the standard LDAP port number (389 or 636) is used.
+Note that the syncrepl uses a consumer-initiated protocol, and hence its
+specification is located at the consumer site, whereas the {{EX:replica}}
+specification is located at the provider site. {{EX:syncrepl}} and
+{{EX:replica}} directives define two independent replication
+mechanisms. They do not represent the replication peers of each other.
+
+The content of the syncrepl replica is defined using a search
+specification as its result set. The consumer slapd will
+send search requests to the provider slapd according to the search
+specification. The search specification includes {{EX:searchbase}},
+{{EX:scope}}, {{EX:filter}}, {{EX:attrs}}, {{EX:attrsonly}},
+{{EX:sizelimit}}, and {{EX:timelimit}} parameters as in the normal
+search specification. The {{EX:searchbase}} parameter has no
+default value and must always be specified. The {{EX:scope}} defaults
+to {{EX:sub}}, the {{EX:filter}} defaults to {{EX:(objectclass=*)}},
+{{EX:attrs}} defaults to {{EX:"*,+"}} to replicate all user and operational
+attributes, and {{EX:attrsonly}} is unset by default. Both {{EX:sizelimit}}
+and {{EX:timelimit}} default to "unlimited", and only integers
+or "unlimited" may be specified.
+
+The LDAP Content Synchronization protocol has two operation
+types: {{EX:refreshOnly}} and {{EX:refreshAndPersist}}.
+The operation type is specified by the {{EX:type}} parameter.
+In the {{EX:refreshOnly}} operation, the next synchronization search operation
+is periodically rescheduled at an interval time after each
+synchronization operation finishes. The interval is specified
+by the {{EX:interval}} parameter. It is set to one day by default.
+In the {{EX:refreshAndPersist}} operation, a synchronization search
+remains persistent in the provider slapd. Further updates to the
+master replica will generate {{EX:searchResultEntry}} to the consumer slapd
+as the search responses to the persistent synchronization search.
+
+If an error occurs during replication, the consumer will attempt to reconnect
+according to the retry parameter which is a list of the <retry interval>
+and <# of retries> pairs. For example, retry="60 10 300 3" lets the consumer
+retry every 60 seconds for the first 10 times and then retry every 300 seconds
+for the next three times before stop retrying. + in <# of retries> means
+indefinite number of retries until success.
+
+The schema checking can be enforced at the LDAP Sync consumer site
+by turning on the {{EX:schemachecking}} parameter.
+If it is turned on, every replicated entry will be checked for its
+schema as the entry is stored into the replica content.
+Every entry in the replica should contain those attributes
+required by the schema definition.
+If it is turned off, entries will be stored without checking
+schema conformance. The default is off.
+
+The {{EX:binddn}} parameter gives the DN to bind as for the
+syncrepl searches to the provider slapd. It should be a DN
+which has read access to the replication content in the
+master database.
+
+The {{EX:bindmethod}} is {{EX:simple}} or {{EX:sasl}},
+depending on whether simple password-based authentication or
+{{TERM:SASL}} authentication is to be used when connecting
+to the provider slapd.
+
+Simple authentication should not be used unless adequate data
+integrity and confidentiality protections are in place (e.g. TLS
+or IPsec). Simple authentication requires specification of {{EX:binddn}}
+and {{EX:credentials}} parameters.
+
+SASL authentication is generally recommended. SASL authentication
+requires specification of a mechanism using the {{EX:saslmech}} parameter.
+Depending on the mechanism, an authentication identity and/or
+credentials can be specified using {{EX:authcid}} and {{EX:credentials}},
+respectively. The {{EX:authzid}} parameter may be used to specify
+an authorization identity.
+
+The {{EX:realm}} parameter specifies a realm which a certain
+mechanisms authenticate the identity within. The {{EX:secprops}}
+parameter specifies Cyrus SASL security properties.
+
+The syncrepl replication mechanism is supported by the two primary
+database backends: back-bdb and back-hdb.
+
+See the {{SECT:LDAP Sync Replication}} chapter of the admin guide
+for more information on how to use this directive.
+
+
+H4: updateref <URL>
+
+This directive is only applicable in a {{slave}} (or {{shadow}})
+{{slapd}}(8) instance. It
+specifies the URL to return to clients which submit update
+requests upon the replica.
+If specified multiple times, each {{TERM:URL}} is provided.
\Example:
-> search /usr/local/bin/search.sh
-
-Note that you need only supply those commands you want the
-backend to handle. Operations for which a command is not
-supplied will be refused with an "unwilling to perform" error.
+> updateref ldap://master.example.net
+H3: BDB and HDB Database Directives
-H3: Password Backend-Specific Directives
+Directives in this category only apply to both the {{TERM:BDB}}
+and the {{TERM:HDB}} database.
+That is, they must follow a "database bdb" or "database hdb" line
+and come before any
+subsequent "backend" or "database" line. For a complete reference
+of BDB/HDB configuration directives, see {{slapd-bdb}}(5).
-Directives in this category only apply to the PASSWD backend
-database. That is, they must follow a "database passwd" line
-and come before any other "database" line.
-H4: file <filename>
+H4: directory <directory>
-This directive specifies an alternate passwd file to use.
+This directive specifies the directory where the BDB files
+containing the database and associated indices live.
\Default:
-> file /etc/passwd
-
-
-
-H3: TCL Backend-Specific Directives
-
-H4: scriptpath <pathname>
-
-This is the full path to a file containing the TCL command(s) to handle
-the LDAP operations.
-
-H4: Proc specifiers
+> directory /usr/local/var/openldap-data
-> bind <proc>
-> unbind <proc>
-> search <proc>
-> compare <proc>
-> modify <proc>
-> modrdn <proc>
-> add <proc>
-> delete <proc>
-> abandon <proc>
-These directives specify the name of the proc (function) in the
-TCL script specified in {{EX:scriptpath}} to execute in response to
-the given LDAP operation.
+H2: The access Configuration Directive
-\Example:
-
-> search proc_search
-
-Note that you need only supply those commands you want the
-TCL backend to handle. Operations for which a command is not
-supplied will be refused with an "unwilling to perform" error.
-
-H4: tclrealm <name>
-
-This is one of the biggest pluses of using the TCL backend.
-The realm let's you group several databases to the same interpretor.
-This basically means they share the same global variables and proc
-space. So global variables, as well as all the procs are callable
-between databases. If no {{EX:tclrealm}} is specified, it is put into the
-"default" realm.
-
-
-
-H2: Access Control
-
-Access to slapd entries and attributes is controlled by the
+Access to entries and attributes is controlled by the
access configuration file directive. The general form of an
access line is:
> <access directive> ::= access to <what>
-> [by <who> <access> <control>]+
-> <what> ::= * | [ dn[.<target style>]=<regex>]
+> [by <who> [<access>] [<control>] ]+
+> <what> ::= * |
+> [dn[.<basic-style>]=<regex> | dn.<scope-style>=<DN>]
> [filter=<ldapfilter>] [attrs=<attrlist>]
-> <target style> ::= regex | base | one | subtree | children
-> <attrlist> ::= <attr> | <attr> , <attrlist>
+> <basic-style> ::= regex | exact
+> <scope-style> ::= base | one | subtree | children
+> <attrlist> ::= <attr> [val[.<basic-style>]=<regex>] | <attr> , <attrlist>
> <attr> ::= <attrname> | entry | children
-> <who> ::= [* | anonymous | users | self |
-> dn[.<subject style>]=<regex>]
-> [dnattr=<attrname> ]
-> [group[/<objectclass>[/<attrname>][.<basic style>]]=<regex> ]
-> [peername[.<basic style>]=<regex>]
-> [sockname[.<basic style>]=<regex>]
-> [domain[.<basic style>]=<regex>]
-> [sockurl[.<basic style>]=<regex>]
+> <who> ::= * | [anonymous | users | self
+> | dn[.<basic-style>]=<regex> | dn.<scope-style>=<DN>]
+> [dnattr=<attrname>]
+> [group[/<objectclass>[/<attrname>][.<basic-style>]]=<regex>]
+> [peername[.<basic-style>]=<regex>]
+> [sockname[.<basic-style>]=<regex>]
+> [domain[.<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
-> <priv> ::= {=|+|-}{w|r|s|c|x}+
+> <level> ::= none | disclose | auth | compare | search | read | write | manage
+> <priv> ::= {=|+|-}{m|w|r|s|c|x|d|0}+
> <control> ::= [stop | continue | break]
-where the <what> part selects the entries and/or attributes to
-which the access applies, the {{EX:<who>}} part specifies which
-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.
+where the <what> part selects the entries and/or attributes to which
+the access applies, the {{EX:<who>}} part specifies which 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. 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
-The <what> part of an access specification determines the
-entries and attributes to which the access control applies.
-Entries can be selected in two ways: by a regular expression
-matching the entry's distinguished name:
+The <what> part of an access specification determines the entries
+and attributes to which the access control applies. Entries are
+commonly selected in two ways: by DN and by filter. The following
+qualifiers select entries by DN:
-> dn=<regular expression>
+> to *
+> to dn[.<basic-style>]=<regex>
+> to dn.<scope-style>=<DN>
-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".
+The first form is used to select all entries. The second form may
+be used to select entries by matching a regular expression against
+the target entry's {{normalized DN}}. (The second form is not
+discussed further in this document.) The third form is used to
+select entries which are within the requested scope of DN. The
+<DN> is a string representation of the Distinguished Name, as
+described in {{REF:RFC4514}}.
-Or, entries may be selected by a filter matching some
-attribute(s) in the entry:
+The scope can be either {{EX:base}}, {{EX:one}}, {{EX:subtree}},
+or {{EX:children}}. Where {{EX:base}} matches only the entry with
+provided DN, {{EX:one}} matches the entries whose parent is the
+provided DN, {{EX:subtree}} matches all entries in the subtree whose
+root is the provided DN, and {{EX:children}} matches all entries
+under the DN (but not the entry named by the DN).
-> filter=<ldap filter>
+For example, if the directory contained entries named:
+
+> 0: o=suffix
+> 1: cn=Manager,o=suffix
+> 2: ou=people,o=suffix
+> 3: uid=kdz,ou=people,o=suffix
+> 4: cn=addresses,uid=kdz,ou=people,o=suffix
+> 5: uid=hyc,ou=people,o=suffix
+
+\Then:
+. {{EX:dn.base="ou=people,o=suffix"}} match 2;
+. {{EX:dn.one="ou=people,o=suffix"}} match 3, and 5;
+. {{EX:dn.subtree="ou=people,o=suffix"}} match 2, 3, 4, and 5; and
+. {{EX:dn.children="ou=people,o=suffix"}} match 3, 4, and 5.
+
+
+Entries may also be selected using a filter:
+
+> to filter=<ldap filter>
where <ldap filter> is a string representation of an LDAP
-search filter, as described in RFC 2254.
+search filter, as described in {{REF:RFC4515}}. For example:
+
+> to filter=(objectClass=person)
-The special entry selector "*" is used to select any entry,
-and is a convenient shorthand for the equivalent "dn=.*" selector.
+Note that entries may be selected by both DN and filter by
+including both qualifiers in the <what> clause.
-Attributes within an entry are selected by including a
-comma-separated list of attribute names in the <what>
-selector:
+> to dn.one="ou=people,o=suffix" filter=(objectClass=person)
+
+Attributes within an entry are selected by including a comma-separated
+list of attribute names in the <what> selector:
> attrs=<attribute list>
-Access to the entry itself must be granted or denied using the
-special attribute name "{{EX:entry}}". Note that giving access to an
-attribute is not enough; access to the entry itself through the
-{{EX:entry}} attribute is also required. The complete examples at
-the end of this section should help clear things up.
+A specific value of an attribute is selected by using a single
+attribute name and also using a value selector:
+
+> attrs=<attribute> val[.<style>]=<regex>
+There are two special {{pseudo}} attributes {{EX:entry}} and
+{{EX:children}}. To read (and hence return) a target entry, the
+subject must have {{EX:read}} access to the target's {{entry}}
+attribute. To add or delete an entry, the subject must have
+{{EX:write}} access to the entry's {{EX:entry}} attribute AND must
+have {{EX:write}} access to the entry's parent's {{EX:children}}
+attribute. To rename an entry, the subject must have {{EX:write}}
+access to entry's {{EX:entry}} attribute AND have {{EX:write}}
+access to both the old parent's and new parent's {{EX:children}}
+attributes. The complete examples at the end of this section should
+help clear things up.
+
+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=.*}}"
H3: Who to grant access to
The <who> part identifies the entity or entities being granted
access. Note that access is granted to "entities" not "entries."
-Entities can be specified by the special "*" identifier, matching
-any entry, the keyword "self" matching the entry protected by
-the access, or by a regular expression matching an entry's
-distinguished name:
-
-> 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.
-
-Or entities can be specified by a regular expression matching
-the client's IP address or domain name:
+The following table summarizes entity specifiers:
+
+!block table; align=Center; coltags="EX,N"; \
+ title="Table 6.3: Access Entity Specifiers"
+Specifier|Entities
+*|All, including anonymous and authenticated users
+anonymous|Anonymous (non-authenticated) users
+users|Authenticated users
+self|User associated with target entry
+dn[.<basic-style>]=<regex>|Users matching a regular expression
+dn.<scope-style>=<DN>|Users within scope of a DN
+!endblock
-> addr=<regular expression>
-> domain=<regular expression>
+The DN specifier behaves much like <what> clause DN specifiers.
-or by an entry listed in a DN-valued attribute in the entry to
-which the access applies:
+Other control factors are also supported. For example, a {{EX:<who>}}
+can be restricted by an entry listed in a DN-valued attribute in
+the entry to which the access applies:
> dnattr=<dn-valued attribute name>
access to a group entry to whoever is listed as the owner of
the group entry).
+Some factors may not be appropriate in all environments (or any).
+For example, the domain factor relies on IP to domain name lookups.
+As these can easily spoofed, the domain factor should not be avoided.
H3: The access to grant
-
The kind of <access> granted can be one of the following:
-
-!block table; colaligns="LRL"; align=Center; \
- title="Table 5.2: Access Levels"
-Level Privledges Description
-none no access
-auth =x needed to bind
-compare =cx needed to compare
-search =scx needed to apply search filters
-read =rscx needed to read search results
-write =wrscx needed to modify/rename
+!block table; colaligns="LRL"; coltags="EX,EX,N"; align=Center; \
+ title="Table 6.4: Access Levels"
+Level Privileges Description
+none =0 no access
+disclose =d needed for information disclosure on error
+auth =dx needed to authenticate (bind)
+compare =cdx needed to compare
+search =scdx needed to apply search filters
+read =rscdx needed to read search results
+write =wrscdx needed to modify/rename
+manage =mwrscdx needed to manage
!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.
+Each level implies all lower levels of access. So, for example,
+granting someone {{EX:write}} access to an entry also grants them
+{{EX:read}}, {{EX:search}}, {{EX:compare}}, {{EX:auth}} and
+{{EX:disclose}} 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.
H3: Access Control Examples
+The access control facility described above is quite powerful. This
+section shows some examples of its use for descriptive purposes.
-
-The access control facility described above is quite powerful.
-This section shows some examples of its use. First, some
-simple examples:
+A simple example:
> access to * by * read
> 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}}.
+This directive allows the user to modify their entry, allows anonymous
+to authentication against these entries, and allows all others to
+read these entries. 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}}".
-The following example shows the use of a regular expression
-to select the entries by DN in two access directives where
-ordering is significant.
+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 dn=".*,dc=example,dc=com"
+> 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 authentication access to anonymous users, and read access
+when 64 or better security protections have been established. If
+client has not establish sufficient security protections, the
+implicit {{EX:by * none}} clause would be applied.
+
+The following example shows the use of a style specifiers to select
+the entries by DN in two access directives where ordering is
+significant.
+
+> access to dn.children="dc=example,dc=com"
> by * search
-> access to dn=".*,dc=com"
+> access to dn.children="dc=com"
> by * read
-Read access is granted to entries under the {{EX:dc=com}}.
-subtree, except for those entries under the {{EX:dc=example,dc=com}}
-subtree, to which search access is granted. No access to
-{{EX:dc=com}} as the neither access directive matches this DN.
-If the order of these access directives was reversed, the
-trailing directive would never be reached, since all
-{{EX:dc=example,dc=com}} entries are also {{EX:dc=com}} entries.
-
-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.
-
-The next example again shows the importance of ordering,
-both of the access directives and the {{EX:by <who>}} clauses.
-It also shows the use of an attribute selector to grant access
-to a specific attribute and various {{EX:<who>}} selectors.
-
-> access to dn="(.*,)?dc=example,dc=com" attr=homePhone
+Read access is granted to entries under the {{EX:dc=com}} subtree,
+except for those entries under the {{EX:dc=example,dc=com}} subtree,
+to which search access is granted. No access is granted to
+{{EX:dc=com}} as neither access directive matches this DN. If the
+order of these access directives was reversed, the trailing directive
+would never be reached, since all entries under {{EX:dc=example,dc=com}}
+are also under {{EX:dc=com}} entries.
+
+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 an implicit {{EX:by * none}} clause and
+every access list ends with an implicit {{EX:access to * by * none}}
+directive.
+
+The next example again shows the importance of ordering, both of
+the access directives and the {{EX:by <who>}} clauses. It also
+shows the use of an attribute selector to grant access to a specific
+attribute and various {{EX:<who>}} selectors.
+
+> access to dn.subtree="dc=example,dc=com" attrs=homePhone
> by self write
-> by dn="(.*,)?dc=example,dc=com" search
-> by domain=.*\.example\.com read
-> access to dn="(.*,)?dc=example,dc=com"
+> by dn.children="dc=example,dc=com" search
+> by peername.regex=IP:10\..+ read
+> access to dn.subtree="dc=example,dc=com"
> by self write
-> by dn=".*,dc=example,dc=com" search
+> by dn.children="dc=example,dc=com" search
> by anonymous auth
-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
-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
-from somewhere in the {{EX:example.com}} domain, and otherwise not
-readable (implicit {{EX:by * none}}). All other access
-is denied by the implicit {{EX:access to * by * none}}.
+This example applies to entries in the "{{EX:dc=example,dc=com}}"
+subtree. To all attributes except {{EX:homePhone}}, an entry can
+write to itself, entries under {{EX:example.com}} entries can search
+by them, 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 entries under {{EX:example.com}}, readable by
+clients connecting from network 10, and otherwise not readable
+(implicit {{EX:by * none}}). All other access is denied by the
+implicit {{EX:access to * by * none}}.
Sometimes it is useful to permit a particular DN to add or
remove itself from an attribute. For example, if you would like to
-create a group and allow people too add and remove only
+create a group and allow people to add and remove only
their own DN from the member attribute, you could accomplish
it with an access directive like this:
-> access to attr=member,entry
+> access to attrs=member,entry
> by dnattr=member selfwrite
The dnattr {{EX:<who>}} selector says that the access applies to
the entry attribute is required because access to the entry is
required to access any of the entry's attributes.
-Note that the {{EX:attr=member}} construct in the {{EX:<what>}}
-clause is a shorthand for the clause "{{EX:dn=.* attr=member}}"
-(i.e., it matches the {{EX:member}} attribute in all entries).
-
-
-
-H2: Schema Specification
-
-The {{EX:objectclass}} and {{EX:attributeTypes}} configuration file
-directives can be used to define schema rules on entries in the
-directory.
-
-H3: Object Identifiers
-
-Each schema element is identified by a globally unique
-{{TERM[expand]OID}} ({{TERM:OID}}). OIDs are also used to identify
-other objects.
-They are commonly found in protocols described by {{TERM:ASN.1}}. In
-particular, they are heavy used by Simple Network Management
-Protocol (SNMP). As OIDs are hierarchical, your organization
-can obtain one OID and branch it as needed. For example,
-if your organization were assigned OID {{EX:1.1}}, you could branch
-the tree as follows:
-
-!block table; colaligns="LR"; coltags="EX,N"; align=Center; \
- title="Table 5.1: Debugging Levels"
-{{N:OID}} Assignment
-1.1 Organization's OID
-1.1.1 SNMP Elements
-1.1.2 LDAP Elements
-1.1.2.1 AttributeTypes
-1.1.2.1.1 myAttribute
-1.1.2.2 ObjectClasses
-1.1.2.2.1 myObjectClass
-!endblock
-
-You are, of course, free to design a hierarchy suitable to your
-organizational needs under your organization's OID. No matter
-what hierarchy you choose, you should maintain a registry of
-assignments you make. This can be a simple flat file or a
-something more sophisticated such as the OpenLDAP OID Registry
-{{URL:http://www.openldap.org/faq/index.cgi?file=197}}.
-
-For more information about Object Identifers (and a listing
-service) see {{URL:http://www.alvestrand.no/harald/objectid/}}.
-
-.{{Under no circumstances should you use a fictious OID!}}
-
-To obtain a fully registered OID at {{no cost}}, apply for
-a OID under {{ORG[expand]IANA}} maintained
-{{Private Enterprise}} arch. Any private enterprise (organization)
-may request an OID to be assigned under this arch. Just fill
-out the form at {{URL: http://www.iana.org/cgi-bin/enterprise.pl}}
-and your official OID will be sent to you usually within a few days.
-Your base OID will be something like {{EX:1.3.6.1.4.1.X}} were {{EX:X}}
-is an integer.
-
-Note: Don't let the "MIB/SNMP" statement confuse you. OIDs
-obtained using this form may be used for any purpose including
-identifying LDAP schema elements.
-
-
-H3: AttributeType Specification
-
-{{B:To be specified.}}
-
-H3: ObjectClass Specification
-
-The schema rules are defined by one or more
-objectclass lines, and enforcement is turned on or off via the
-schemacheck directives. The format of an {{EX:objectclass}} line is:
-
-> objectclass <RFC2252 Object Class Description>
-
-This directive defines the schema rules for the object class
-given by {{EX:<name>}}. Schema rules consist of the attributes the
-entry is required to have (given by the requires {{EX:<attrs>}}
-clause) and those attributes that it may optionally have (given
-by the allows {{EX:<attrs>}} clause). In both clauses, {{EX:<attrs>}}
-is a comma-separated list of attribute names.
-
-For example, to define an object class called {{myPerson}}, you
-might include a definition like this:
-
-> objectclass ( 1.2.3 NAME 'myPerson'
-> DESC 'my person'
-> MUST ( cn $ sn )
-> MAY ( mail $ phone $ fax ) )
-
+!if 0
+For more details on how to use the {{EX:access}} directive,
+consult the {{Advanced Access Control}} chapter.
+!endif
H2: Configuration File Example
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: 1. # example config file - global configuration section
-E: 2. include /usr/local/etc/schema/core.schema
-E: 3. referral ldap://root.openldap.org
-
-Line 1 is a comment. Lines 2 include another config file
-which containing {{core}} schema definitions.
+E: 1. # example config file - global configuration section
+E: 2. include /usr/local/etc/schema/core.schema
+E: 3. referral ldap://root.openldap.org
+E: 4. access to * by * read
+
+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}}.
-The next section of the configuration file defines an LDBM
+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 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: 4. # ldbm definition for the example.com
-E: 5. database ldbm
-E: 6. suffix "dc=example, dc=com"
-E: 7. directory /usr/local/var/openldap
-E: 8. rootdn "cn=Manager, dc=example, dc=com"
-E: 9. rootpw secret
-E: 10. replogfile /usr/local/var/openldap/slapd.replog
-E: 11. replica host=slave1.example.com:389
-E: 12. binddn="cn=Replicator, dc=example, dc=com"
-E: 13. bindmethod=simple credentials=secret
-E: 14. replica host=slave2.example.com
-E: 15. binddn="cn=Replicator, dc=example, dc=com"
-E: 16. bindmethod=kerberos
-E: 17. srvtab=/etc/srvtab.slave2
-E: 18. # ldbm indexed attribute definitions
-E: 19. index uid pres,eq
-E: 20. index cn,sn,uid pres,eq,approx,sub
-E: 21. index objectClass eq
-E: 22. # ldbm access control definitions
-E: 23. access to attr=userPassword
-E: 24. by self write
-E: 25. by anonymous auth
-E: 26. by dn="cn=Admin,dc=example,dc=com" write
-E: 27. by * none
-E: 28. access to *
-E: 29. by self write
-E: 30. by anonymous auth
-E: 31. by dn="cn=Admin,dc=example,dc=com" write
-E: 32. by * read
-
-Line 4 is a comment. The start of the database definition is
-marked by the database keyword on line 5. Line 6 specifies
-the DN suffix for queries to pass to this database. Line 7
-specifies the directory in which the database files will live
-
-Lines 8 and 9 identify the database "super user" entry and
-associated password. This entry is not subject to access
-control or size or time limit restrictions.
-
-Lines 10 through 17 are for replication. Line 10 specifies the
-replication log file (where changes to the database are logged
-\- this file is written by slapd and read by slurpd). Lines 11
-through 13 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 14 through 17 specify a second replication site,
-using kerberos instead of simple authentication. See Section
-10 on slurpd for more information on these directives.
-
-Lines 19 through 21 indicate the indexes to maintain for
-various attributes.
-
-Lines 23 through 32 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.
-
-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=net"
-
+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. # indexed attribute definitions
+E: 12. index uid pres,eq
+E: 13. index cn,sn,uid pres,eq,approx,sub
+E: 14. index objectClass eq
+E: 15. # database access control definitions
+E: 16. access to attrs=userPassword
+E: 17. by self write
+E: 18. by anonymous auth
+E: 19. by dn.base="cn=Admin,dc=example,dc=com" write
+E: 20. by * none
+E: 21. access to *
+E: 22. by self write
+E: 23. by dn.base="cn=Admin,dc=example,dc=com" write
+E: 24. 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 12 through 14 indicate the indices to maintain for various
+attributes.
+
+Lines 16 through 24 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