# $OpenLDAP$
-# Copyright 2005, The OpenLDAP Foundation, All Rights Reserved.
+# Copyright 2005-2006 The OpenLDAP Foundation, All Rights Reserved.
# COPYING RESTRICTIONS APPLY, see COPYRIGHT.
H1: Configuring slapd
Once the software has been built and installed, you are ready
to configure {{slapd}}(8) for use at your site. Unlike previous
-OpenLDAP releases, the slapd runtime configuration in 2.3 is
-fully LDAP-enabled and can be managed using the standard LDAP
+OpenLDAP releases, the slapd(8) runtime configuration in 2.3 (and later)
+is fully LDAP-enabled and can be managed using the standard LDAP
operations with data in {{TERM:LDIF}}. The LDAP configuration engine
allows all of slapd's configuration options to be changed on the fly,
generally without requiring a server restart for the changes
to take effect. The old style {{slapd.conf}}(5) file is still
-supported, but must be converted to the new {{slapd.d}}(5) format
+supported, but must be converted to the new {{slapd-config}}(5) format
to allow runtime changes to be saved. While the old style
configuration uses a single file, normally installed as
{{F:/usr/local/etc/openldap/slapd.conf}}, the new style
configuration database normally resides in the
{{F:/usr/local/etc/openldap/slapd.d}} directory.
-An alternate configuration directory (or file) can be specified via a
-command-line option to {{slapd}}(8) or {{slurpd}}(8). This chapter
-describes the general format of the configuration system, followed by a
-detailed description of commonly used config settings.
+An alternate configuration directory (or file) can be specified via
+a command-line option to {{slapd}}(8). This chapter describes the
+general format of the configuration system, followed by a detailed
+description of commonly used config settings.
+
+Note: some of the backends and of the distributed overlays
+do not support runtime configuration yet. In those cases,
+the old style {{slapd.conf}}(5) file must be used.
+
+Note: the current version of {{slurpd}} has not been updated for
+compatibility with this new configuration engine. If you must use
+slurpd for replication at your site, you will have to maintain an
+old-style {{slapd.conf}} file for slurpd to use.
H2: Configuration Layout
Other objects may be part of the configuration but were omitted from
the illustration for clarity.
-The {{slapd.d}} configuration tree has a very specific structure. The
+The {{slapd-config}} configuration tree has a very specific structure. The
root of the tree is named {{EX:cn=config}} and contains global configuration
settings. Additional settings are contained in separate child entries:
* Include files
The usual rules for LDIF files apply to the configuration information:
Comment lines beginning with a '{{EX:#}}' character
-are ignored. If a line begins with white space, it is considered a
+are ignored. If a line begins with a single space, it is considered a
continuation of the previous line (even if the previous line is a
-comment). Entries are separated by blank lines.
+comment) and the single leading space is removed. Entries are separated by blank lines.
The general layout of the config LDIF is as follows:
A configuration directive may take arguments. If so, the arguments are
separated by white space. If an argument contains white space,
-the argument should be enclosed in double quotes {{EX:"like this"}}. If
-an argument contains a double quote or a backslash character `{{EX:\}}',
-the character should be preceded by a backslash character `{{EX:\}}'.
+the argument should be enclosed in double quotes {{EX:"like this"}}.
In the descriptions that follow, arguments that should be replaced
by actual text are shown in brackets {{EX:<>}}.
H2: Configuration Directives
This section details commonly used configuration directives. For
-a complete list, see the {{slapd.d}}(5) manual page. This section
+a complete list, see the {{slapd-config}}(5) manual page. This section
will treat the configuration directives in a top-down order, starting
with the global directives in the {{EX:cn=config}} entry. Each
directive will be described along with its default value (if any) and
>olcInclude: ./schema/cosine.schema
+H3: cn=module
+
+If support for dynamically loaded modules was enabled when configuring
+slapd, {{EX:cn=module}} entries may be used to specify sets of modules to load.
+Module entries must have the {{EX:olcModuleList}} objectClass.
+
+
+H4: olcModuleLoad: <filename>
+
+Specify the name of a dynamically loadable module to load. The filename
+may be an absolute path name or a simple filename. Non-absolute names
+are searched for in the directories specified by the {{EX:olcModulePath}}
+directive.
+
+
+H4: olcModulePath: <pathspec>
+
+Specify a list of directories to search for loadable modules. Typically the
+path is colon-separated but this depends on the operating system.
+
+
+H4: Sample Entries
+
+>dn: cn=module{0},cn=config
+>objectClass: olcModuleList
+>cn: module{0}
+>olcModuleLoad: /usr/local/lib/smbk5pwd.la
+>
+>dn: cn=module{1},cn=config
+>objectClass: olcModuleList
+>cn: module{1}
+>olcModulePath: /usr/local/lib:/usr/local/lib/slapd
+>olcModuleLoad: accesslog.la
+>olcModuleLoad: pcache.la
+
+
H3: cn=schema
The cn=schema entry holds all of the schema definitions that are hard-coded
objectClass.
-H4: olcAttributeTypes: <{{REF:RFC2252}} Attribute Type Description>
+H4: olcAttributeTypes: <{{REF:RFC4512}} Attribute Type Description>
This directive defines an attribute type.
Please see the {{SECT:Schema Specification}} chapter
for information regarding how to use this directive.
-H4: olcObjectClasses: <{{REF:RFC2252}} Object Class Description>
+H4: olcObjectClasses: <{{REF:RFC4512}} Object Class Description>
This directive defines an object class.
Please see the {{SECT:Schema Specification}} chapter for
>objectClass: olcSchemaConfig
>cn: test
>olcAttributeTypes: ( 1.1.1
-> NAME 'testAttr'
-> EQUALITY integerMatch
-> SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 )
+> NAME 'testAttr'
+> EQUALITY integerMatch
+> SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 )
>olcAttributeTypes: ( 1.1.2 NAME 'testTwo' EQUALITY caseIgnoreMatch
-> SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.44 )
+> SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.44 )
>olcObjectClasses: ( 1.1.3 NAME 'testObject'
-> MAY ( testAttr $ testTwo ) AUXILIARY )
+> MAY ( testAttr $ testTwo ) AUXILIARY )
H3: Backend-specific Directives
title="Table 5.2: Database Backends"
Types Description
bdb Berkeley DB transactional backend
+config Slapd configuration backend
dnssrv DNS SRV backend
+hdb Hierarchical variant of bdb backend
ldap Lightweight Directory Access Protocol (Proxy) backend
-ldbm Lightweight DBM backend
ldif Lightweight Data Interchange Format backend
meta Meta Directory backend
monitor Monitor backend
> olcBackend: bdb
-There are no other directives defined for this entry, so generally
-it will not be needed. However, specific backend types may define
-additional attributes for their particular use.
+There are no other directives defined for this entry. Specific backend
+types may define additional attributes for their particular use but so
+far none have ever been defined. As such, these directives usually do
+not appear in any actual configurations.
H4: Sample Entry
databases. Subsequent database definitions may also override some
frontend settings.
+The {{EX:config}} database is also special; both the {{EX:config}} and
+the {{EX:frontend}} databases are always created implicitly even if they
+are not explicitly configured, and they are created before any other
+databases.
+
\Example:
> olcDatabase: bdb
This marks the beginning of a new {{TERM:BDB}} database instance.
-H4: olcAccess: to <what> [ by <who> <accesslevel> <control> ]+
+H4: olcAccess: 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
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.
+or {{TERM: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.
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.
+written by {{slapd}}(8) and read by {{slurpd}}(8). Normally, this
+directive is only used if {{slurpd}}(8) is being used to replicate
+the database. However, you can also use it to generate a transaction
+log, if {{slurpd}}(8) is not running. In this case, you will need to
+periodically truncate the file, since it will grow indefinitely
+otherwise.
See the chapter entitled {{SECT:Replication with slurpd}} for more
information on how to use this directive.
> olcRootPW: secret
-It is also permissible to provide a hash of the password in RFC 2307
-form. {{slappasswd}}(8) may be used to generate the password hash.
+It is also permissible to provide a hash of the password in
+{{REF:RFC2307}} form. {{slappasswd}}(8) may be used to generate
+the password hash.
\Example:
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 {{EX:draft-zeilenga-ldup-sync-xx.txt}}
-({{a work in progress}}) for more information on the protocol.
+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,
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 syncrepl search specification has
-the same value syntax and the same default values as in the
-{{ldapsearch}}(1) client search tool.
+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 positive integers
+or "unlimited" may be specified.
The LDAP Content Synchronization protocol has two operation
types: {{EX:refreshOnly}} and {{EX:refreshAndPersist}}.
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}}
+or IPsec). Simple authentication requires specification of {{EX:binddn}}
and {{EX:credentials}} parameters.
SASL authentication is generally recommended. SASL authentication
parameter specifies Cyrus SASL security properties.
The syncrepl replication mechanism is supported by the
-three native backends: back-bdb, back-hdb, and back-ldbm.
+two native 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.
> olcUpdateref: ldap://master.example.net
-H4: Sample Entry
+H4: Sample Entries
>dn: olcDatabase=frontend,cn=config
>objectClass: olcDatabaseConfig
+>objectClass: olcFrontendConfig
>olcDatabase: frontend
>olcReadOnly: FALSE
+>
+>dn: olcDatabase=config,cn=config
+>objectClass: olcDatabaseConfig
+>olcDatabase: config
+>olcRootDN: cn=Manager,dc=example,dc=com
+
-H3: BDB Database Directives
+H3: BDB and HDB Database Directives
-Directives in this category only apply to a {{TERM:BDB}} database.
+Directives in this category apply to both the {{TERM:BDB}}
+and the {{TERM:HDB}} database.
They are used in an olcDatabase entry in addition to the generic
database directives defined above. For a complete reference
-of BDB configuration directives, see {{slapd-bdb}}(5). BDB database
-entries must have the {{EX:olcBdbConfig}} objectClass.
+of BDB/HDB configuration directives, see {{slapd-bdb}}(5). In
+addition to the {{EX:olcDatabaseConfig}} objectClass, BDB and HDB
+database entries must have the {{EX:olcBdbConfig}} and
+{{EX:olcHdbConfig}} objectClass, respectively.
H4: olcDbDirectory: <directory>
documentation for more details.
-H4: olcDbNosync: <TRUE|FALSE>
+H4: olcDbNosync: { TRUE | FALSE }
This option causes on-disk database contents to not be immediately
synchronized with in memory changes upon change. Setting this option
-to TRUE may improve performance at the expense of data integrity. This
+to {{EX:TRUE}} may improve performance at the expense of data integrity. This
directive has the same effect as using
> olcDbConfig: set_flags DB_TXN_NOSYNC
manually completed using the slapindex tool.
-H4: olcDbLinearIndex: <TRUE|FALSE>
+H4: olcDbLinearIndex: { TRUE | FALSE }
If this setting is {{EX:TRUE}} slapindex will index one attribute
at a time. The default settings is {{EX:FALSE}} in which case all
H4: Sample Entry
->dn: olcDatabase=bdb,cn=config
+>dn: olcDatabase=hdb,cn=config
>objectClass: olcDatabaseConfig
->objectClass: olcBdbConfig
->olcDatabase: bdb
+>objectClass: olcHdbConfig
+>olcDatabase: hdb
>olcSuffix: "dc=example,dc=com"
>olcDbDirectory: /usr/local/var/openldap-data
>olcDbCacheSize: 1000
>olcDbIndex: objectClass eq
-Note: the remainder of this chapter has not yet been updated to reflect
-the new cn=config mechanisms.
-
H2: Access Control
Access to slapd entries and attributes is controlled by the
-access configuration file directive. The general form of an
-access line is:
+olcAccess attribute, whose values are a sequence of access directives.
+The general form of the olcAccess configuration is:
-> <access directive> ::= access to <what>
-> [by <who> <access> <control>]+
+> olcAccess: <access directive>
+> <access directive> ::= to <what>
+> [by <who> [<access>] [<control>] ]+
> <what> ::= * |
> [dn[.<basic-style>]=<regex> | dn.<scope-style>=<DN>]
> [filter=<ldapfilter>] [attrs=<attrlist>]
> [set=<setspec>]
> [aci=<attrname>]
> <access> ::= [self]{<level>|<priv>}
-> <level> ::= none | auth | compare | search | read | write
-> <priv> ::= {=|+|-}{w|r|s|c|x|0}+
+> <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
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}}.
+described in {{REF:RFC4514}}.
The scope can be either {{EX:base}}, {{EX:one}}, {{EX:subtree}},
or {{EX:children}}. Where {{EX:base}} matches only the entry with
> to filter=<ldap filter>
where <ldap filter> is a string representation of an LDAP
-search filter, as described in {{REF:RFC2254}}. For example:
+search filter, as described in {{REF:RFC4515}}. For example:
> to filter=(objectClass=person)
H3: The access to grant
-
The kind of <access> granted can be one of the following:
-
!block table; colaligns="LRL"; coltags="EX,EX,N"; align=Center; \
title="Table 5.4: Access Levels"
-Level Privileges Description
-none =0 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
+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 {{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
+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.
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
+to the {{EX:<what>}} selectors given in the configuration. 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.
+first, followed by the global access directives (which are held in
+the {{EX:frontend}} database definition). Within this priority,
+access directives are examined in the order in which they appear
+in the configuration attribute. 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
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>}}
+should appear first in the configuration. 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.
A simple example:
-> access to * by * read
+> olcAccess: to * by * read
This access directive grants read access to everyone.
-> access to *
+> olcAccess: to *
> by self write
> by anonymous auth
> by * read
This directive allows the user to modify their entry, allows anonymous
-to authentication against these entries, and allows all others to
+to authenticate 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
of protection in place. The following shows how security strength
factors (SSF) can be used.
-> access to *
+> olcAccess: 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,
+protections 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
+when strength 64 or better security protections have been established. If
+the 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 following example shows the use of style specifiers to select
the entries by DN in two access directives where ordering is
significant.
-> access to dn.children="dc=example,dc=com"
+> olcAccess: to dn.children="dc=example,dc=com"
> by * search
-> access to dn.children="dc=com"
+> olcAccess: to dn.children="dc=com"
> by * read
Read access is granted to entries under the {{EX:dc=com}} subtree,
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
+Also note that if no {{EX:olcAccess: to}} directive matches or no {{EX:by
+<who>}} clause, {{B:access is denied}}. That is, every {{EX:olcAccess:
to}} directive ends with an implicit {{EX:by * none}} clause and
-every access list ends with an implicit {{EX:access to * by * none}}
+every access list ends with an implicit {{EX:olcAccess: to * by * none}}
directive.
The next example again shows the importance of ordering, both of
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
+> olcAccess: to dn.subtree="dc=example,dc=com" attr=homePhone
> by self write
> by dn.children=dc=example,dc=com" search
> by peername.regex=IP:10\..+ read
-> access to dn.subtree="dc=example,dc=com"
+> olcAccess: to dn.subtree="dc=example,dc=com"
> by self write
> by dn.children="dc=example,dc=com" search
> by anonymous auth
their own DN from the member attribute, you could accomplish
it with an access directive like this:
-> access to attr=member,entry
+> olcAccess: to attr=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.
+
+
+H3: Access Control Ordering
+
+Since the ordering of {{EX:olcAccess}} directives is essential to their
+proper evaluation, but LDAP attributes normally do not preserve the
+ordering of their values, OpenLDAP uses a custom schema extension to
+maintain a fixed ordering of these values. This ordering is maintained
+by prepending a {{EX:"{X}"}} numeric index to each value, similarly to
+the approach used for ordering the configuration entries. These index
+tags are maintained automatically by slapd and do not need to be specified
+when originally defining the values. For example, when you create the
+settings
+
+> olcAccess: to attr=member,entry
+> by dnattr=member selfwrite
+> olcAccess: to dn.children="dc=example,dc=com"
+> by * search
+> olcAccess: to dn.children="dc=com"
+> by * read
+
+when you read them back using slapcat or ldapsearch they will contain
+
+> olcAccess: {0}to attr=member,entry
+> by dnattr=member selfwrite
+> olcAccess: {1}to dn.children="dc=example,dc=com"
+> by * search
+> olcAccess: {2}to dn.children="dc=com"
+> by * read
+
+The numeric index may be used to specify a particular value to change
+when using ldapmodify to edit the access rules. This index can be used
+instead of (or in addition to) the actual access value. Using this
+numeric index is very helpful when multiple access rules are being managed.
+
+For example, if we needed to change the second rule above to grant
+write access instead of search, we could try this LDIF:
+
+> changetype: modify
+> delete: olcAccess
+> olcAccess: to dn.children="dc=example,dc=com" by * search
+> -
+> add: olcAccess
+> olcAccess: to dn.children="dc=example,dc=com" by * write
+> -
+
+But this example {{B:will not}} guarantee that the existing values remain in
+their original order, so it will most likely yield a broken security
+configuration. Instead, the numeric index should be used:
+
+> changetype: modify
+> delete: olcAccess
+> olcAccess: {1}
+> -
+> add: olcAccess
+> olcAccess: {1}to dn.children="dc=example,dc=com" by * write
+> -
+
+This example deletes whatever rule is in value #1 of the {{EX:olcAccess}}
+attribute (regardless of its value) and adds a new value that is
+explicitly inserted as value #1. The result will be
+
+> olcAccess: {0}to attr=member,entry
+> by dnattr=member selfwrite
+> olcAccess: {1}to dn.children="dc=example,dc=com"
+> by * write
+> olcAccess: {2}to dn.children="dc=com"
+> by * read
+
+which is exactly what was intended.
+
!if 0
For more details on how to use the {{EX:access}} directive,
consult the {{Advanced Access Control}} chapter.
!endif
-H2: Configuration File Example
+H2: Configuration Example
-The following is an example configuration file, interspersed
+The following is an example configuration, interspersed
with explanatory text. It defines two databases to handle
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
-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
+E: 1. # example config file - global configuration entry
+E: 2. dn: cn=config
+E: 3. objectClass: olcGlobal
+E: 4. cn: config
+E: 5. olcReferral: ldap://root.openldap.org
+E: 6.
+
+Line 1 is a comment. Lines 2-4 identify this as the global
+configuration entry.
+The {{EX:olcReferral:}} directive on line 5
means that queries not local to one of the databases defined
below will be referred to the LDAP server running on the
standard port (389) at the host {{EX:root.openldap.org}}.
-
-Line 4 is a global access control. It 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. Indices are to be
-maintained for several attributes, and the {{EX:userPassword}}
-attribute is to be protected from unauthorized access.
-
-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 uri=ldap://slave1.example.com:389
-E: 14. binddn="cn=Replicator,dc=example,dc=com"
-E: 15. bindmethod=simple credentials=secret
-E: 16. replica uri=ldaps://slave2.example.com:636
-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
+Line 6 is a blank line, indicating the end of this entry.
+
+E: 7. # internal schema
+E: 8. dn: cn=schema,cn=config
+E: 9. objectClass: olcSchemaConfig
+E: 10. cn: schema
+E: 11.
+
+Line 7 is a comment. Lines 8-10 identify this as the root of
+the schema subtree. The actual schema definitions in this entry
+are hardcoded into slapd so no additional attributes are specified here.
+Line 11 is a blank line, indicating the end of this entry.
+
+E: 12. # include the core schema
+E: 13. include: file:///usr/local/etc/openldap/schema/core.ldif
+E: 14.
+
+Line 12 is a comment. Line 13 is an LDIF include directive which
+accesses the {{core}} schema definitions in LDIF format. Line 14
+is a blank line.
+
+Next comes the database definitions. The first database is the
+special {{EX:frontend}} database whose settings are applied globally
+to all the other databases.
+
+E: 15. # global database parameters
+E: 16. dn: olcDatabase=frontend,cn=config
+E: 17. objectClass: olcDatabaseConfig
+E: 18. olcDatabase: frontend
+E: 19. olcAccess: to * by * read
+E: 20.
+
+Line 15 is a comment. Lines 16-18 identify this entry as the global
+database entry. Line 19 is a global access control. It applies to all
+entries (after any applicable database-specific access controls).
+
+The next entry defines a BDB backend that will handle queries for things
+in the "dc=example,dc=com" portion of the tree. Indices are to be maintained
+for several attributes, and the {{EX:userPassword}} attribute is to be
+protected from unauthorized access.
+
+E: 21. # BDB definition for example.com
+E: 22. dn: olcDatabase=bdb,cn=config
+E: 23. objectClass: olcDatabaseConfig
+E: 24. objectClass: olcBdbConfig
+E: 25. olcDatabase: bdb
+E: 26. olcSuffix: "dc=example,dc=com"
+E: 27. olcDbDirectory: /usr/local/var/openldap-data
+E: 28. olcRootDN: "cn=Manager,dc=example,dc=com"
+E: 29. olcRootPW: secret
+E: 30. olcDbIndex: uid pres,eq
+E: 31. olcDbIndex: cn,sn,uid pres,eq,approx,sub
+E: 32. olcDbIndex: objectClass eq
+E: 33. olcAccess: to attr=userPassword
+E: 34. by self write
+E: 35. by anonymous auth
+E: 36. by dn.base="cn=Admin,dc=example,dc=com" write
+E: 37. by * none
+E: 38. olcAccess: to *
+E: 39. by self write
+E: 40. by dn.base="cn=Admin,dc=example,dc=com" write
+E: 41. by * read
+E: 42.
+
+Line 21 is a comment. Lines 22-25 identify this entry as a BDB database
+configuration entry. Line 26 specifies the DN suffix
+for queries to pass to this database. Line 27 specifies the directory
in which the database files will live.
-Lines 9 and 10 identify the database {{super-user}} entry and associated
+Lines 28 and 29 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
+Lines 30 through 32 indicate the indices to maintain for various
attributes.
-Lines 24 through 32 specify access control for entries in this
+Lines 33 through 41 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
All other attributes are writable by the entry and the "admin"
entry, but may be read by all users (authenticated or not).
+Line 42 is a blank line, indicating the end of this entry.
+
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
+as the first database. Note that without line 51, the read access
+would be allowed due to the global access rule at line 19.
+
+E: 42. # BDB definition for example.net
+E: 43. dn: olcDatabase=bdb,cn=config
+E: 44. objectClass: olcDatabaseConfig
+E: 45. objectClass: olcBdbConfig
+E: 46. olcDatabase: bdb
+E: 47. olcSuffix: "dc=example,dc=net"
+E: 48. olcDbDirectory: /usr/local/var/openldap-data-net
+E: 49. olcRootDN: "cn=Manager,dc=example,dc=com"
+E: 50. olcDbIndex: objectClass eq
+E: 51. olcAccess: to * by users read