# $OpenLDAP$
-# Copyright 1999-2003, The OpenLDAP Foundation, All Rights Reserved.
+# Copyright 1999-2007 The OpenLDAP Foundation, All Rights Reserved.
# COPYING RESTRICTIONS APPLY, see COPYRIGHT.
H1: The slapd Configuration File
Types Description
bdb Berkeley DB transactional backend
dnssrv DNS SRV backend
+hdb Hierarchical variant of bdb backend
ldap Lightweight Directory Access Protocol (Proxy) backend
ldbm Lightweight DBM backend
meta Meta Directory backend
H4: replica
> replica uri=ldap[s]://<hostname>[:<port>] | host=<hostname>[:<port>]
-> [bindmethod={simple|kerberos|sasl}]
+> [bindmethod={simple|sasl}]
> ["binddn=<DN>"]
> [saslmech=<mech>]
> [authcid=<identity>]
> [authzid=<identity>]
> [credentials=<password>]
-> [srvtab=<filename>]
This directive specifies a replication site for this database. The
{{EX:uri=}} parameter specifies a scheme, a host and optionally a port where
entire {{EX:"binddn=<DN>"}} string should be enclosed in double
quotes.
-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.
+The {{EX:bindmethod}} is {{EX:simple}} or {{EX:sasl}}, depending
+on whether simple password-based authentication or {{TERM:SASL}}
+authentication is to be used when connecting to the 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.
-
-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.
+Simple authentication should not be used unless adequate data
+integrity and confidentiality protections are in place (e.g. TLS
+or IPSEC). Simple authentication requires specification of
+{{EX:binddn}} and {{EX:credentials}} parameters.
SASL authentication is generally recommended. SASL authentication
requires specification of a mechanism using the {{EX:saslmech}} parameter.
> provider=ldap[s]://<hostname>[:port]
> [type=refreshOnly|refreshAndPersist]
> [interval=dd:hh:mm:ss]
+> [retry=[<retry interval> <# of retries>]+]
> [searchbase=<base DN>]
> [filter=<filter str>]
> [scope=sub|one|base]
> [sizelimit=<limit>]
> [timelimit=<limit>]
> [schemachecking=on|off]
-> [updatedn=<DN>]
> [bindmethod=simple|sasl]
> [binddn=<DN>]
> [saslmech=<mech>]
({{a work in progress}}) for more information on the protocol.
The {{EX:rid}} parameter is used for identification of the current
-{{EX:syncrepl}} directive within the replication consumer site,
+{{EX:syncrepl}} directive within the replication consumer server,
where {{EX:<replica ID>}} uniquely identifies the syncrepl specification
described by the current {{EX:syncrepl}} directive. {{EX:<replica ID>}}
-is non-negative and is no more than three digits in length.
+is non-negative and is no more than three decimal digits in length.
The {{EX:provider}} parameter specifies the replication provider site
containing the master content as an LDAP URI. The {{EX:provider}}
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 integers
+or "unlimited" may be specified.
The LDAP Content Synchronization protocol has two operation
types: {{EX:refreshOnly}} and {{EX:refreshAndPersist}}.
master replica will generate {{EX:searchResultEntry}} to the consumer slapd
as the search responses to the persistent synchronization search.
+If an error occurs during replication, the consumer will attempt to reconnect
+according to the retry parameter which is a list of the <retry interval>
+and <# of retries> pairs. For example, retry="60 10 300 3" lets the consumer
+retry every 60 seconds for the first 10 times and then retry every 300 seconds
+for the next three times before stop retrying. + in <# of retries> means
+indefinite number of retries until success.
+
The schema checking can be enforced at the LDAP Sync consumer site
by turning on the {{EX:schemachecking}} parameter.
If it is turned on, every replicated entry will be checked for its
If it is turned off, entries will be stored without checking
schema conformance. The default is off.
-The {{EX:updatedn}} parameter specifies the DN in the consumer site
-which is allowed to make changes to the replica. This DN is used
-locally by the syncrepl engine when updating the replica with the
-entries received from the provider site by using the internal
-operation mechanism. The update of the replica content is subject
-to the access control privileges of the DN. The DN should have
-read/write access to the replica database. Generally, this DN
-{{should not}} be the same as {{EX:rootdn}}.
-
The {{EX:binddn}} parameter gives the DN to bind as for the
syncrepl searches to the provider slapd. It should be a DN
which has read access to the replication content in the
{{TERM:SASL}} authentication is to be used when connecting
to the provider 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.
+Simple authentication should not be used unless adequate data
+integrity and confidentiality protections are in place (e.g. TLS
+or IPSEC). Simple authentication requires specification of {{EX:binddn}}
+and {{EX:credentials}} parameters.
SASL authentication is generally recommended. SASL authentication
requires specification of a mechanism using the {{EX:saslmech}} parameter.
> updateref ldap://master.example.net
-H3: BDB Database Directives
+H3: BDB and HDB 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
+Directives in this category only apply to both the {{TERM:BDB}}
+and the {{TERM:HDB}} database.
+That is, they must follow a "database bdb" or "database hdb" line
+and come before any
subsequent "backend" or "database" line. For a complete reference
-of BDB configuration directives, see {{slapd-bdb}}(5).
+of BDB/HDB configuration directives, see {{slapd-bdb}}(5).
H4: directory <directory>
> directory /usr/local/var/openldap-data
-H4: sessionlog <sid> <limit>
-
-This directive specifies a session log store in the syncrepl
-replication provider site which contains information on
-the entries that have been scoped out of the content of the
-replication session identified by {{EX:<sid>}}.
-The first syncrepl search request having the same sid value in the
-cookie establishes the session log store in the provider site.
-The number of the entries in the session log store is limited
-by {{EX:<limit>}}. Excessive entries are removed from the store
-in the FIFO order. Both {{EX:<sid>}} and {{EX:<limit>}} are
-non-negative integers. {{EX:<sid>}} has no more than three digits.
-
-The LDAP Content Synchronization operation that falls into a pre-existing
-session uses the session log store in order to reduce the amount
-of synchronization traffic. If the replica is not so outdated that
-it can be made up-to-date by the information in the session store,
-the provider slapd will send the consumer slapd the identities of the
-scoped-out entries together with the in-scope entries added to or
-modified within the replication content. If the replica status is
-beyond the coverage of the history store, then the provider slapd will
-send the identities of the unchanged in-scope entries along with the
-changed in-scope entries. The consumer slapd will then remove those
-entries in the replica which are not identified as present in the
-master content.
-
-An access control mechanism is to be further provided to
-make the session joining controllable.
-
-
H3: LDBM Database Directives
Directives in this category only apply to a {{TERM:LDBM}} database.
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 for descriptive purposes.
+
+A simple example:
> access to * by * read
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.
+The following example shows the use of a style specifiers to select
+the entries by DN in two access directives where ordering is
+significant.
> access to dn.children="dc=example,dc=com"
> by * search
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
+> access to dn.subtree="dc=example,dc=com" attrs=homePhone
> by self write
-> by dn.children=dc=example,dc=com" search
-> by peername=IP:10\..+ read
+> by dn.children="dc=example,dc=com" search
+> by peername.regex=IP:10\..+ read
> access to dn.subtree="dc=example,dc=com"
> by self write
> by dn.children="dc=example,dc=com" search
their own DN from the member attribute, you could accomplish
it with an access directive like this:
-> access to attr=member,entry
+> access to attrs=member,entry
> by dnattr=member selfwrite
The dnattr {{EX:<who>}} selector says that the access applies to
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: 24. access to attrs=userPassword
E: 25. by self write
E: 26. by anonymous auth
E: 27. by dn.base="cn=Admin,dc=example,dc=com" write
projects / openldap / blobdiff