slapdconfig.sdf

OpenLdap是LDAP的开源项目

H4: rootpw <password>

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

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
passed to this backend database. Multiple suffix lines can be
given, and at least one is required for each database
definition.

\Example:

>	suffix "dc=example,dc=com"

Queries with a DN ending in "dc=example,dc=com"
will be passed to this backend.

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.


H4: syncrepl

>	syncrepl rid=<replica ID>
>		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]
>		[attrs=<attr list>]
>		[attrsonly]
>		[sizelimit=<limit>]
>		[timelimit=<limit>]
>		[schemachecking=on|off]
>		[bindmethod=simple|sasl]
>		[binddn=<DN>]
>		[saslmech=<mech>]
>		[authcid=<identity>]
>		[authzid=<identity>]
>		[credentials=<passwd>]
>		[realm=<realm>]
>		[secprops=<properties>]


This directive specifies the current database as a replica of the
master content by establishing the current {{slapd}}(8) as a
replication consumer site running a syncrepl replication engine.
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.

The {{EX:rid}} parameter is used for identification of the current
{{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 decimal digits in length.

The {{EX:provider}} parameter specifies the replication provider site
containing the master content as an LDAP URI. The {{EX:provider}}
parameter specifies a scheme, a host and optionally a port where the
provider slapd instance can be found. Either a domain name or IP
address may be used for <hostname>. Examples are
{{EX:ldap://provider.example.com:389}} or {{EX:ldaps://192.168.1.1:636}}.
If <port> is not given, the standard LDAP port number (389 or 636) is used.
Note that the syncrepl uses a consumer-initiated protocol, and hence its
specification is located at the consumer site, whereas the {{EX:replica}}
specification is located at the provider site. {{EX:syncrepl}} and
{{EX:replica}} directives define two independent replication
mechanisms. They do not represent the replication peers of each other.

The content of the syncrepl replica is defined using a search
specification as its result set. The consumer slapd will
send search requests to the provider slapd according to the search
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 {{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}}.
The operation type is specified by the {{EX:type}} parameter.
In the {{EX:refreshOnly}} operation, the next synchronization search operation
is periodically rescheduled at an interval time after each
synchronization operation finishes. The interval is specified
by the {{EX:interval}} parameter. It is set to one day by default.
In the {{EX:refreshAndPersist}} operation, a synchronization search
remains persistent in the provider slapd. Further updates to the
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
schema as the entry is stored into the replica content.
Every entry in the replica should contain those attributes
required by the schema definition.
If it is turned off, entries will be stored without checking
schema conformance. The default is off.

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
master database. 

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 provider slapd.

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

The {{EX:realm}} parameter specifies a realm which a certain
mechanisms authenticate the identity within. The {{EX:secprops}}
parameter specifies Cyrus SASL security properties.

The syncrepl replication mechanism is supported by the
three native backends: back-bdb, back-hdb, and back-ldbm.

See the {{SECT:LDAP Sync Replication}} chapter of the admin guide
for more information on how to use this directive.


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.

Entry-based Example:

>	updatedn "cn=Update Daemon,dc=example,dc=com"

SASL-based Example:

>	updatedn "uid=slurpd,cn=example.com,cn=digest-md5,cn=auth"

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

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.

\Example:

>	updateref	ldap://master.example.net


H3: BDB and HDB Database Directives

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/HDB configuration directives, see {{slapd-bdb}}(5).


H4: directory <directory>

This directive specifies the directory where the BDB files
containing the database and associated indices live.

\Default:

>	directory /usr/local/var/openldap-data


H3: LDBM Database Directives

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: cachesize <integer>

This directive specifies the size in entries of the in-memory
cache maintained by the LDBM backend database instance.

\Default:

>	cachesize 1000


H4: dbcachesize <integer>

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.

\Default:

>	dbcachesize 100000


H4: dbnolocking

This option, if present, disables database locking.
Enabling this option may improve performance at the expense
of data security.


H4: dbnosync

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.


H4: directory <directory>

This directive specifies the directory where the LDBM files
containing the database and associated indices live.

\Default:

>	directory /usr/local/var/openldap-data


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

This directive specifies the indices to maintain for the given
attribute. If only an {{EX:<attrlist>}} is given, the default
indices are maintained.

\Example:

>	index default pres,eq
>	index uid
>	index cn,sn pres,eq,sub
>	index objectClass eq

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.

By default, no indices are maintained.  It is generally advised
that minimally an equality index upon objectClass be maintained.

>	index objectClass eq



H4: mode <integer>

This directive specifies the file protection mode that newly
created database index files should have.

\Default:

>	mode 0600


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:

>	<access directive> ::= access to <what>
>		[by <who> <access> <control>]+
>	<what> ::= * |
>		[dn[.<basic-style>]=<regex> | dn.<scope-style>=<DN>]
>		[filter=<ldapfilter>] [attrs=<attrlist>]
>	<basic-style> ::= regex | exact
>	<scope-style> ::= base | one | subtree | children
>	<attrlist> ::= <attr> [val[.<basic-style>]=<regex>] | <attr> , <attrlist>
>	<attr> ::= <attrname> | entry | children
>	<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>]
>	<access> ::= [self]{<level>|<priv>}
>	<level> ::= none | auth | compare | search | read | write
>	<priv> ::= {=|+|-}{w|r|s|c|x|0}+
>	<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. 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

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:

>	to *
>	to dn[.<basic-style>]=<regex>
>	to dn.<scope-style>=<DN>

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

The scope can be either {{EX:base}}, {{EX:one}}, {{EX:subtree}},