# $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.
> [sizelimit=<limit>]
> [timelimit=<limit>]
> [schemachecking=on|off]
-> [updatedn=<DN>]
> [bindmethod=simple|sasl]
> [binddn=<DN>]
> [saslmech=<mech>]
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}}.
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 5 300 3" lets the consumer
+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.
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 server which contains information on
-the entries that have been scoped out of the replication
-content identified by {{EX:<sid>}}.
-The first syncrepl search request having the same {{EX:<sid>}} value
-in the cookie establishes the session log store in the provider server.
-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 decimal digits.
-
-The LDAP Content Synchronization operation that falls into a pre-existing
-session can use 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
-outdated too much and 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 provider content.
-
-
H3: LDBM Database Directives
Directives in this category only apply to a {{TERM:LDBM}} database.
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 dn.children="dc=example,dc=com" search
> by peername.regex=IP:10\..+ read
> access to dn.subtree="dc=example,dc=com"
> by self write
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