ITS#2497 value-level ACLs

[openldap] / doc / guide / admin / slapdconfig.sdf

diff --git a/doc/guide/admin/slapdconfig.sdf b/doc/guide/admin/slapdconfig.sdf
index 50031bb554804275d305dae6737cb3c4b299d41c..7b6bf2464c9e85849190237aca9b42dcf7620428 100644 (file)
--- a/doc/guide/admin/slapdconfig.sdf
+++ b/doc/guide/admin/slapdconfig.sdf
@@ -1,29 +1,29 @@
 # $OpenLDAP$
 # $OpenLDAP$

-# Copyright 1999-2000, The OpenLDAP Foundation, All Rights Reserved.
+# Copyright 1999-2003, The OpenLDAP Foundation, All Rights Reserved.

 # COPYING RESTRICTIONS APPLY, see COPYRIGHT.
 
 H1: The slapd Configuration File
 
 # 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
 {{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.
-
+command-line option to {{slapd}}(8) or {{slurpd}}(8). This chapter
+describes the general format of the config file, followed by a
+detailed description of commonly used config file directives.

 
 
 H2: Configuration File Format
 
 
 
 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
 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
 can be overridden by database directives.
 
 Blank lines and comment lines beginning with a '{{EX:#}}' character


@@ -61,7 +61,7 @@ the character should be preceded by a backslash character `{{EX:\}}'.
 
 The distribution contains an example configuration file that will
 be installed in the {{F: /usr/local/etc/openldap}} directory.
 
 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.
 
 and object classes) are also provided in the
 {{F: /usr/local/etc/openldap/schema}} directory.
 


@@ -69,7 +69,7 @@ and object classes) are also provided in the
 H2: Configuration File Directives
 
 This section details commonly used configuration directives.  For
 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
 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


@@ -79,41 +79,50 @@ its use.
 
 H3: Global Directives
 
 
 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> ]+
 
 This directive grants access (specified by <accesslevel>) to a
 set of entries and/or attributes (specified by <what>) by one or
 
 
 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.
+more requesters (specified by <who>).
+See the {{SECT:Access Control}} 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:RFC2252}} 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
 
 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
 
 Note: You should be careful when using this directive - there is
 no small limit on the number of nested include directives, and no


@@ -122,13 +131,13 @@ loop detection is done.
 H4: loglevel <integer>
 
 This directive specifies the level at which debugging statements
 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"
 
 !block table; colaligns="RL"; align=Center; \
        title="Table 5.1: Debugging Levels"


@@ -160,9 +169,13 @@ logged.
 
 E: loglevel 256
 
 
 E: loglevel 256
 

-H4: objectclass <RFC2252 Object Class Description>
+
+H4: objectclass <{{REF:RFC2252}} Object Class Description>

 
 This directive defines an object class.
 
 This directive defines an object class.

+Please see the {{SECT:Schema Specification}} chapter for
+information regarding how to use this directive.
+

 
 H4: referral <URI>
 
 
 H4: referral <URI>
 


@@ -179,17 +192,6 @@ query at that server, but note that most of these clients are
 only going to know how to handle simple LDAP URLs that
 contain a host part and optionally a distinguished name part.
 
 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>
 
 
 H4: sizelimit <integer>
 


@@ -201,19 +203,6 @@ from a search operation.
 >      sizelimit 500
 
 
 >      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
 H4: timelimit <integer>
 
 This directive specifies the maximum number of seconds (in real


@@ -228,34 +217,60 @@ exceeded timelimit will be returned.
 
 H3: General Backend Directives
 
 
 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 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
+ldap   Lightweight Directory Access Protocol (Proxy) backend
+ldbm   Lightweight DBM 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 5.2.

 
 

-\Default:
+\Example:
+
+>      database bdb
+
+This marks the beginning of a new {{TERM:BDB}} database instance
+declaration.

 
 

->      lastmod on

 
 H4: readonly { on | off }
 
 
 H4: readonly { on | off }
 


@@ -270,8 +285,11 @@ perform" error.
 H4: replica
 
 >      replica host=<hostname>[:<port>]
 H4: replica
 
 >      replica host=<hostname>[:<port>]

->              "binddn=<DN>"
->              [bindmethod={ simple | kerberos }]
+>              [bindmethod={simple|kerberos|sasl}]
+>              ["binddn=<DN>"]
+>              [saslmech=<mech>]
+>              [authcid=<identity>]
+>              [authzid=<identity>]

 >              [credentials=<password>]
 >              [srvtab=<filename>]
 
 >              [credentials=<password>]
 >              [srvtab=<filename>]
 


@@ -285,25 +303,35 @@ 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
 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
+{{EX: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.
 
 likely to contain embedded spaces, the entire {{EX:"binddn=<DN>"}}
 string should be enclosed in double quotes.
 

-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.
+The {{EX:bindmethod}} is {{EX:simple}} or {{EX:kerberos}} or {{EX:sasl}},
+depending on whether simple password-based authentication or Kerberos
+authentication or {{TERM:SASL}} authentication is to be used when connecting
+to the slave slapd.
+
+Simple authentication should not be used unless adequate integrity
+and privacy protections are in place (e.g. TLS or IPSEC).  Simple
+authentication requires specification of {{EX:binddn}} and
+{{EX:credentials}} parameters.

 
 

-The {{EX:credentials=}} parameter, which is only required if using
-simple authentication, gives the password for {{EX:binddn}} on the
-slave slapd.
+Kerberos authentication is deprecated in favor of SASL authentication
+mechanisms, in particular the {{EX:KERBEROS_V4}} and {{EX:GSSAPI}}
+mechanisms.  Kerberos authentication requires {{EX:binddn}} and
+{{EX:srvtab}} parameters.

 
 

-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.
+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.
+
+See the chapter entitled {{SECT:Replication with slurpd}} for more
+information on how to use this directive.

 
 

-See Section 10 for more details on replication.

 
 H4: replogfile <filename>
 
 
 H4: replogfile <filename>
 


@@ -315,42 +343,49 @@ 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.
 
 slurpd is not running. In this case, you will need to periodically
 truncate the file, since it will grow indefinitely otherwise.
 

-See Section 10 for more details on replication.
+See the chapter entitled {{SECT:Replication with slurpd}} for more
+information on how to use this directive.
+

 
 H4: rootdn <dn>
 
 
 H4: rootdn <dn>
 

-This directive specifies the DN of an entry that is not subject to
+This directive specifies the DN that is not subject to

 access control or administrative limit restrictions for
 access control or administrative limit restrictions for

-operations on this database.
+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.

 
 

-\Example:
+Entry-based Example:

 
 

->      rootdn "cn=Manager, dc=example, dc=com"
+>      rootdn "cn=Manager,dc=example,dc=com"

 
 

-H4: rootkrbname <kerberosname>
+SASL-based Example:

 
 

-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).
+>      rootdn "uid=root,cn=example.com,cn=digest-md5,cn=auth"

 
 

-\Example:
+See the {{SECT:SASL Authentication}} section for information on
+SASL authentication identities.

 
 

->      rootkrbname admin@EXAMPLE.COM

 
 H4: rootpw <password>
 
 
 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 useful when
-creating a database and also when using slurpd to provide
-replication service (see Section 10).
+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:
 
 >      rootpw secret
 
 
 \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}}.
+
+

 H4: suffix <dn suffix>
 
 This directive specifies the DN suffix of queries that will be
 H4: suffix <dn suffix>
 
 This directive specifies the DN suffix of queries that will be


@@ -360,176 +395,227 @@ definition.
 
 \Example:
 
 
 \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.
 
 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.
 
 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>
+H4: syncrepl
+
+>      syncrepl id=<replica ID>
+>              provider=ldap[s]://<hostname>[:port]
+>              [updatedn=<dn>]
+>              [binddn=<dn>]
+>              [bindmethod=simple|sasl]
+>              [binddn=<simple DN>]
+>              [credentials=<simple passwd>]
+>              [saslmech=<SASL mech>]
+>              [secprops=<properties>]
+>              [realm=<realm>]
+>              [authcId=<authentication ID>]
+>              [authzId=<authorization ID>]
+>              [searchbase=<base DN>]
+>              [filter=<filter str>]
+>              [attrs=<attr list>]
+>              [scope=sub|one|base]
+>              [schemachecking=on|off]
+>              [type=refreshOnly|refreshAndPersist]
+>              [interval=dd:hh:mm]
+
+This directive specifies an LDAP Sync replication between this
+database and the specified replication provider site. The id=
+parameter identifies the LDAP Sync specification in the database.
+The {{EX:provider=}} parameter specifies a replication provider site as
+an LDAP URI.
+
+The LDAP Sync replication specification is based on the search
+specification which defines the content of the replica. The replica
+consists of the entries matching the search specification. As with
+the normal searches, the search specification consists of
+{{EX:searchbase}}, {{EX:scope}}, {{EX:filter}}, and EX:attrs}}
+parameters.
+
+The LDAP Sync replication has two types of operating modes. In the
+{{EX:refreshOnly}} mode, the next synchronization session is
+rescheduled at the interval time after the current session finishes.
+The default interval is set to one day. In the {{EX:refreshAndPersist}}
+mode, the LDAP Sync search remains persistent in the provider LDAP
+server. Further updates to the provider replica will generate
+searchResultEntry to the consumer.
+
+The schema checking can be enforced at the LDAP Sync consumer site
+by turning on the {{EX:schemachecking}} parameter. The default is off.
+
+The {{EX:binddn=}} parameter gives the DN for the LDAP Sync search
+to bind as to the provider slapd. The content of the replica will
+be subject to the access control privileges of the DN.
+
+The {{EX:bindmethod}} is {{EX:simple}} or {{EX:sasl}}, depending
+on whether simple password-based authentication or SASL authentication
+is to be used when connecting to the provider slapd.
+
+Simple authentication should not be used unless adequate integrity
+and data confidential 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:mech}} 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
+a proxy authorization identity.
+
+The LDAP Sync replication is supported in three native backends:
+back-bdb, back-hdb, and back-ldbm.
+
+See the {{SECT:LDAP Sync Replication}} chapter for more information
+on how to use this directive.

 
 

-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).

 
 

+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 DN
+{{slurpd}}(8) binds as when making changes to the replica or the DN
+associated with a SASL identity.

 
 

-H3: LDBM Backend-Specific Directives
+Entry-based Example:

 
 

-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.
+>      updatedn "cn=Update Daemon,dc=example,dc=com"

 
 

-H4: cachesize <integer>
+SASL-based Example:

 
 

-This directive specifies the size in entries of the in-memory
-cache maintained by the LDBM backend database instance.
+>      updatedn "uid=slurpd,cn=example.com,cn=digest-md5,cn=auth"

 
 

-\Default:
+See the {{SECT:Replication with slurpd}} chapter for more information
+on how to use this directive.

 
 

->      cachesize 1000
+H4: updateref <URL>

 
 

+This directive is only applicable in a slave slapd. It
+specifies the URL to return to clients which submit update
+requests upon the replica.
+If specified multiple times, each {{TERM:URL}} is provided.

 
 

-H4: dbcachesize <integer>
+\Example:

 
 

-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.
+>      updateref       ldap://master.example.net

 
 

-\Default:

 
 

->      dbcachesize 100000
+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>
 
 
 H4: directory <directory>
 

-This directive specifies the directory where the LDBM files
-containing the database and associated indexes live.
+This directive specifies the directory where the BDB files
+containing the database and associated indices live.

 
 \Default:
 
 
 \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.
+>      directory /usr/local/var/openldap-data

 
 

-\Example:

 
 

->      index default pres,eq
->      index objectClass,uid
->      index cn,sn eq,sub,approx
+H3: LDBM Database Directives

 
 

-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.
+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: mode <integer>
+H4: cachesize <integer>

 
 

-This directive specifies the file protection mode that newly
-created database index files should have.
+This directive specifies the size in entries of the in-memory
+cache maintained by the LDBM backend database instance.

 
 \Default:
 
 
 \Default:
 

->      mode 0600
+>      cachesize 1000

 
 
 
 

+H4: dbcachesize <integer>

 
 

-H3: Shell Backend-Specific Directives
+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 indices.

 
 

->      bind <pathname>
->      unbind <pathname>
->      search <pathname>
->      compare <pathname>
->      modify <pathname>
->      modrdn <pathname>
->      add <pathname>
->      delete <pathname>
->      abandon <pathname>
+\Default:

 
 

-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.
+>      dbcachesize 100000

 
 

-\Example:

 
 

->      search /usr/local/bin/search.sh
+H4: dbnolocking

 
 

-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.
+This option, if present, disables database locking.
+Enabling this option may improve performance at the expense
+of data security.

 
 
 
 

+H4: dbnosync

 
 

-H3: Password Backend-Specific Directives
+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 integrity.

 
 

-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 LDBM files
+containing the database and associated indices live.

 
 \Default:
 
 
 \Default:
 

->      file /etc/passwd
+>      directory /usr/local/var/openldap-data

 
 
 
 

+H4: index {<attrlist> | default} [pres,eq,approx,sub,none]

 
 

-H3: TCL Backend-Specific Directives
+This directive specifies the indices to maintain for the given
+attribute. If only an {{EX:<attrlist>}} is given, the default
+indices are maintained.

 
 

-H4: scriptpath <pathname>
+\Example:

 
 

-This is the full path to a file containing the TCL command(s) to handle
-the LDAP operations.
+>      index default pres,eq
+>      index uid
+>      index cn,sn pres,eq,sub
+>      index objectClass eq

 
 

-H4: Proc specifiers
+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.

 
 

->      bind <proc>
->      unbind <proc>
->      search <proc>
->      compare <proc>
->      modify <proc>
->      modrdn <proc>
->      add <proc>
->      delete <proc>
->      abandon <proc>
+By default, no indices are maintained.  It is generally advised
+that minimally an equality index upon objectClass be maintained.

 
 

-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.
+>      index objectClass eq

 
 

-\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: mode <integer>

 
 

-H4: tclrealm <name>
+This directive specifies the file protection mode that newly
+created database index files should have.

 
 

-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.
+\Default:

 
 

+>      mode 0600

 
 
 H2: Access Control
 
 
 H2: Access Control


@@ -540,100 +626,143 @@ access line is:
 
 >      <access directive> ::= access to <what>
 >              [by <who> <access> <control>]+
 
 >      <access directive> ::= access to <what>
 >              [by <who> <access> <control>]+

->      <what> ::= * | [ dn[.<target style>]=<regex>]
+>      <what> ::= * |
+>              [dn[.<basic-style>]=<regex> | dn.<scope-style>=<DN>]

 >              [filter=<ldapfilter>] [attrs=<attrlist>]
 >              [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
 >      <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>]
 >              [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}+
 >      <control> ::= [stop | continue | break]
 
 >      <access> ::= [self]{<level>|<priv>}
 >      <level> ::= none | auth | compare | search | read | write
 >      <priv> ::= {=|+|-}{w|r|s|c|x}+
 >      <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
 
 
 
 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:
+
+>      by *
+>      by dn[.<basic-style>]=<regex>
+>      by dn.<scope-style>=<DN>

 
 

->      dn=<regular expression>
+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:RFC2253}}.

 
 

-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 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).

 
 

-Or, entries may be selected by a filter matching some
-attribute(s) in the entry:
+For example, if the directory contained entries named:

 
 

->      filter=<ldap filter>
+>      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:
+
+>      by filter=<ldap filter>

 
 where <ldap filter> is a string representation of an LDAP
 
 where <ldap filter> is a string representation of an LDAP

-search filter, as described in RFC 2254.
+search filter, as described in {{REF:RFC2254}}.  For example:

 
 

-The special entry selector "*" is used to select any entry,
-and is a convenient shorthand for the equivalent "dn=.*" selector.
+>      by filter=(objectClass=person)

 
 

-Attributes within an entry are selected by including a
-comma-separated list of attribute names in the <what>
-selector:
+Note that entries may be selected by both DN and filter by
+including both qualifiers in the <what> clause.

 
 

->      attrs=<attribute list>
+>      by dn.one="ou=people,o=suffix" filter=(objectClass=person)

 
 

-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.
+Attributes within an entry are selected by including a comma-separated
+list of attribute names in the <what> selector:

 
 

+>      attrs=<attribute list>

 
 

+A specific value of an attribute is selected by using a single
+attribute name and also using a value selector:

 
 

-H2: Who to grant access to
+>      attrs=<attribute> val[.<style>]=<regex>

 
 

-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:
+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.

 
 

->      dn=<regular expression>
+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=.*}}"

 
 

-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:
+H3: Who to grant access to

 
 

->      addr=<regular expression>
->      domain=<regular expression>
+The <who> part identifies the entity or entities being granted
+access. Note that access is granted to "entities" not "entries."
+The following table summarizes entity specifiers:
+
+!block table; align=Center; coltags="EX,N"; \
+       title="Table 5.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

 
 

-or by an entry listed in a DN-valued attribute in the entry to
-which the access applies:
+The DN specifier behaves much like <what> clause DN specifiers.
+
+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>
 
 
 >      dnattr=<dn-valued attribute name>
 


@@ -642,6 +771,9 @@ whose DN is listed in an attribute of the entry (e.g., give
 access to a group entry to whoever is listed as the owner of
 the group entry).
 
 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
 
 
 H3: The access to grant


@@ -650,9 +782,9 @@ H3: The access to grant
 The kind of <access> granted can be one of the following:
 
 
 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
+!block table; colaligns="LRL"; coltags="EX,EX,N"; align=Center; \
+       title="Table 5.4: Access Levels"
+Level  Privileges      Description

 none                   no access
 auth   =x              needed to bind
 compare        =cx             needed to compare
 none                   no access
 auth   =x              needed to bind
 compare        =cx             needed to compare


@@ -662,50 +794,48 @@ write     =wrscx          needed to modify/rename
 !endblock
 
 Each level implies all lower levels of access. So, for
 !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
 
 
 
 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
 
 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.
 
 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
 
 
 
 
 H3: Access Control Examples
 

-
-

 The access control facility described above is quite powerful.
 This section shows some examples of its use. First, some
 simple examples:
 The access control facility described above is quite powerful.
 This section shows some examples of its use. First, some
 simple examples:


@@ -719,63 +849,80 @@ This access directive grants read access to everyone.
 >              by anonymous auth
 >              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}}".
+
+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.

 
 

-The following example shows the use of a regular expression
+>      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.
 
 to select the entries by DN in two access directives where
 ordering is significant.
 

->      access to dn=".*,dc=example,dc=com"
+>      access to dn.children="dc=example,dc=com"

 >              by * search
 >              by * search

->      access to dn=".*,dc=com"
+>      access to dn.children="dc=com"

 >              by * read
 
 >              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" attr=homePhone

 >              by self write
 >              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=IP:10\..+ read
+>      access to dn.subtree="dc=example,dc=com"

 >              by self write
 >              by self write

->              by dn=".*,dc=example,dc=com" search
+>              by dn.children="dc=example,dc=com" search

 >              by anonymous auth
 
 >              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
 
 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:
 
 their own DN from the member attribute, you could accomplish
 it with an access directive like this:
 


@@ -789,177 +936,114 @@ own DN from the attribute, not other values. The addition of
 the entry attribute is required because access to the entry is
 required to access any of the entry's attributes.
 
 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 {{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 Object
-Identifier (OID).  OIDs are also used to identify other objects.
-They are commonly found in protocols described by 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 in as needed.  For example,
-if your organization were assigned OID 1.1, you could branch
-the tree as follows:
-
-!block table; colaligns="RL"; align=Center; \
-       title="Table 5.1: Debugging Levels"
-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.
-
-.{{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.
-
-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
 
 
 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:
 
 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 {{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
 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.
 
 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. # 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: 15.         bindmethod=simple credentials=secret
+E: 16. replica host=slave2.example.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. # database access control definitions
+E: 24. access to attr=userPassword
+E: 25.         by self write
+E: 26.         by anonymous auth
+E: 27.         by dn.base="cn=Admin,dc=example,dc=com" write
+E: 28.         by * none
+E: 29. access to *
+E: 30.         by self write
+E: 31.         by dn.base="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