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,
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
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
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
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,
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
> olcAccess: <access directive>
> <access directive> ::= to <what>
-> [by <who> <access> <control>]+
+> [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.
-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 (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.
+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
projects / openldap / blobdiff