1999-10-01 00:57:45 +08:00
|
|
|
# $OpenLDAP$
|
2003-01-04 04:04:17 +08:00
|
|
|
# Copyright 1999-2003, The OpenLDAP Foundation, All Rights Reserved.
|
1999-04-24 07:41:45 +08:00
|
|
|
# COPYING RESTRICTIONS APPLY, see COPYRIGHT.
|
2000-07-23 02:59:40 +08:00
|
|
|
|
2000-07-23 15:35:40 +08:00
|
|
|
H1: The slapd Configuration File
|
1999-04-24 07:00:44 +08:00
|
|
|
|
2000-08-11 06:31:41 +08:00
|
|
|
Once the software has been built and installed, you are ready
|
2000-08-12 14:35:08 +08:00
|
|
|
to configure {{slapd}}(8) for use at your site. The slapd
|
|
|
|
runtime configuration is primarily accomplished through the
|
2000-08-24 07:23:16 +08:00
|
|
|
{{slapd.conf}}(5) file, normally installed in the
|
2000-08-12 14:35:08 +08:00
|
|
|
{{EX:/usr/local/etc/openldap}} directory.
|
1999-04-24 07:00:44 +08:00
|
|
|
|
|
|
|
An alternate configuration file can be specified via a
|
2000-08-11 06:31:41 +08:00
|
|
|
command-line option to {{slapd}}(8) or {{slurpd}}(8). This chapter
|
|
|
|
describes the general format of the config file, followed by a
|
|
|
|
detailed description of commonly used config file directives.
|
1999-04-24 07:00:44 +08:00
|
|
|
|
|
|
|
|
|
|
|
H2: Configuration File Format
|
|
|
|
|
2000-08-30 13:05:26 +08:00
|
|
|
The {{slapd.conf}}(5) file consists of three types of configuration
|
|
|
|
information: global, backend specific, and database specific. Global
|
2000-08-10 09:38:36 +08:00
|
|
|
information is specified first, followed by information associated
|
|
|
|
with a particular backend type, which is then followed by information
|
|
|
|
associated with a particular database instance. Global directives can
|
2002-06-15 09:00:50 +08:00
|
|
|
be overridden in backend and/or database directives, and backend directives
|
2000-08-10 09:38:36 +08:00
|
|
|
can be overridden by database directives.
|
1999-04-24 07:00:44 +08:00
|
|
|
|
2000-08-10 09:38:36 +08:00
|
|
|
Blank lines and comment lines beginning with a '{{EX:#}}' character
|
|
|
|
are ignored. If a line begins with white space, it is considered a
|
2003-11-25 04:34:45 +08:00
|
|
|
continuation of the previous line (even if the previous line is a
|
|
|
|
comment).
|
|
|
|
|
|
|
|
The general format of slapd.conf is as follows:
|
1999-04-24 07:00:44 +08:00
|
|
|
|
2000-08-10 13:23:38 +08:00
|
|
|
> # global configuration directives
|
|
|
|
> <global config directives>
|
|
|
|
>
|
|
|
|
> # backend definition
|
|
|
|
> backend <typeA>
|
|
|
|
> <backend-specific directives>
|
|
|
|
>
|
|
|
|
> # first database definition & config directives
|
|
|
|
> database <typeA>
|
|
|
|
> <database-specific directives>
|
|
|
|
>
|
|
|
|
> # second database definition & config directives
|
|
|
|
> database <typeB>
|
|
|
|
> <database-specific directives>
|
|
|
|
>
|
|
|
|
> # second database definition & config directives
|
|
|
|
> database <typeA>
|
|
|
|
> <database-specific directives>
|
|
|
|
>
|
|
|
|
> # subsequent backend & database definitions & config directives
|
|
|
|
> ...
|
1999-04-24 07:00:44 +08:00
|
|
|
|
2000-08-10 09:38:36 +08:00
|
|
|
A configuration directive may take arguments. If so, they are
|
|
|
|
separated by white space. If an argument contains white space,
|
2000-08-10 13:23:38 +08:00
|
|
|
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:\}}'.
|
1999-04-24 07:00:44 +08:00
|
|
|
|
|
|
|
The distribution contains an example configuration file that will
|
2000-08-10 09:38:36 +08:00
|
|
|
be installed in the {{F: /usr/local/etc/openldap}} directory.
|
2000-08-30 13:05:26 +08:00
|
|
|
A number of files containing schema definitions (attribute types
|
2000-08-10 09:38:36 +08:00
|
|
|
and object classes) are also provided in the
|
|
|
|
{{F: /usr/local/etc/openldap/schema}} directory.
|
1999-04-24 07:00:44 +08:00
|
|
|
|
|
|
|
|
2000-08-10 09:38:36 +08:00
|
|
|
H2: Configuration File Directives
|
1999-04-24 07:00:44 +08:00
|
|
|
|
2000-08-10 09:38:36 +08:00
|
|
|
This section details commonly used configuration directives. For
|
2002-06-15 09:00:50 +08:00
|
|
|
a complete list, see the {{slapd.conf}}(5) manual page. This section
|
2000-08-10 09:38:36 +08:00
|
|
|
separates the configuration file directives into global,
|
|
|
|
backend-specific and data-specific categories, describing each
|
|
|
|
directive and its default value (if any), and giving an example of
|
1999-04-24 07:00:44 +08:00
|
|
|
its use.
|
|
|
|
|
|
|
|
|
|
|
|
|
2000-08-10 09:38:36 +08:00
|
|
|
H3: Global Directives
|
1999-04-24 07:00:44 +08:00
|
|
|
|
2000-08-11 08:23:10 +08:00
|
|
|
Directives described in this section apply to all backends
|
2000-08-30 13:05:26 +08:00
|
|
|
and databases unless specifically overridden in a backend or
|
2000-09-01 02:36:01 +08:00
|
|
|
database definition. Arguments that should be replaced
|
2000-08-11 08:23:10 +08:00
|
|
|
by actual text are shown in brackets {{EX:<>}}.
|
1999-04-24 07:00:44 +08:00
|
|
|
|
|
|
|
|
2000-07-18 18:30:54 +08:00
|
|
|
H4: access to <what> [ by <who> <accesslevel> <control> ]+
|
1999-04-24 07:00:44 +08:00
|
|
|
|
2000-08-10 09:38:36 +08:00
|
|
|
This directive grants access (specified by <accesslevel>) to a
|
1999-04-24 07:00:44 +08:00
|
|
|
set of entries and/or attributes (specified by <what>) by one or
|
2000-08-11 06:31:41 +08:00
|
|
|
more requesters (specified by <who>).
|
2000-08-11 08:23:10 +08:00
|
|
|
See the {{SECT:Access Control}} section of this chapter for a
|
|
|
|
summary of basic usage.
|
2002-09-09 14:53:11 +08:00
|
|
|
|
2000-08-11 08:23:10 +08:00
|
|
|
!if 0
|
|
|
|
More details discussion of this directive can be found in the
|
|
|
|
{{SECT:Advanced Access Control}} chapter.
|
|
|
|
!endif
|
1999-04-24 07:00:44 +08:00
|
|
|
|
2002-09-09 14:53:11 +08:00
|
|
|
Note: If no {{EX:access}} directives are specified, the default
|
|
|
|
access control policy, {{EX:access to * by * read}}, allows all
|
|
|
|
both authenticated and anonymous users read access.
|
|
|
|
|
1999-04-24 07:00:44 +08:00
|
|
|
|
2000-08-11 08:23:10 +08:00
|
|
|
H4: attributetype <{{REF:RFC2252}} Attribute Type Description>
|
1999-04-24 07:00:44 +08:00
|
|
|
|
2000-08-10 09:38:36 +08:00
|
|
|
This directive defines an attribute type.
|
2000-08-11 10:52:27 +08:00
|
|
|
Please see the {{SECT:Schema Specification}} chapter
|
|
|
|
for information regarding how to use this directive.
|
1999-04-24 07:00:44 +08:00
|
|
|
|
2000-08-12 14:35:08 +08:00
|
|
|
H4: idletimeout <integer>
|
|
|
|
|
|
|
|
Specify the number of seconds to wait before forcibly closing
|
2000-08-30 13:05:26 +08:00
|
|
|
an idle client connection. An idletimeout of 0, the default,
|
2000-08-12 14:35:08 +08:00
|
|
|
disables this feature.
|
|
|
|
|
|
|
|
|
1999-04-24 07:00:44 +08:00
|
|
|
H4: include <filename>
|
|
|
|
|
2000-08-10 09:38:36 +08:00
|
|
|
This directive specifies that slapd should read additional
|
1999-04-24 07:00:44 +08:00
|
|
|
configuration information from the given file before continuing
|
|
|
|
with the next line of the current file. The included file should
|
2000-08-11 06:31:41 +08:00
|
|
|
follow the normal slapd config file format. The file is commonly
|
|
|
|
used to include files containing schema specifications.
|
1999-04-24 07:00:44 +08:00
|
|
|
|
2000-08-10 09:38:36 +08:00
|
|
|
Note: You should be careful when using this directive - there is
|
|
|
|
no small limit on the number of nested include directives, and no
|
1999-04-24 07:00:44 +08:00
|
|
|
loop detection is done.
|
|
|
|
|
|
|
|
H4: loglevel <integer>
|
|
|
|
|
2000-08-10 09:38:36 +08:00
|
|
|
This directive specifies the level at which debugging statements
|
2000-08-24 07:23:16 +08:00
|
|
|
and operation statistics should be syslogged (currently logged to
|
2002-06-14 21:01:48 +08:00
|
|
|
the {{syslogd}}(8) {{EX:LOG_LOCAL4}} facility). You must have
|
2000-08-24 07:23:16 +08:00
|
|
|
configured OpenLDAP {{EX:--enable-debug}} (the default) for this
|
|
|
|
to work (except for the two statistics levels, which are always
|
|
|
|
enabled). Log levels are additive. To display what numbers
|
|
|
|
correspond to what kind of debugging, invoke slapd with {{EX:-?}}
|
|
|
|
or consult the table below. The possible values for <integer> are:
|
1999-04-24 07:00:44 +08:00
|
|
|
|
2000-08-10 15:17:54 +08:00
|
|
|
!block table; colaligns="RL"; align=Center; \
|
|
|
|
title="Table 5.1: Debugging Levels"
|
|
|
|
Level Description
|
|
|
|
-1 enable all debugging
|
|
|
|
0 no debugging
|
|
|
|
1 trace function calls
|
|
|
|
2 debug packet handling
|
|
|
|
4 heavy trace debugging
|
|
|
|
8 connection management
|
|
|
|
16 print out packets sent and received
|
|
|
|
32 search filter processing
|
|
|
|
64 configuration file processing
|
|
|
|
128 access control list processing
|
|
|
|
256 stats log connections/operations/results
|
|
|
|
512 stats log entries sent
|
|
|
|
1024 print communication with shell backends
|
|
|
|
2048 print entry parsing debugging
|
|
|
|
!endblock
|
1999-04-24 07:00:44 +08:00
|
|
|
|
|
|
|
\Example:
|
|
|
|
|
2000-08-10 15:17:54 +08:00
|
|
|
E: loglevel -1
|
1999-04-24 07:00:44 +08:00
|
|
|
|
|
|
|
This will cause lots and lots of debugging information to be
|
2000-08-10 15:17:54 +08:00
|
|
|
logged.
|
1999-04-24 07:00:44 +08:00
|
|
|
|
|
|
|
\Default:
|
|
|
|
|
|
|
|
E: loglevel 256
|
|
|
|
|
2000-08-11 08:23:10 +08:00
|
|
|
|
|
|
|
H4: objectclass <{{REF:RFC2252}} Object Class Description>
|
1999-04-24 07:00:44 +08:00
|
|
|
|
2000-08-10 09:38:36 +08:00
|
|
|
This directive defines an object class.
|
2000-08-11 10:52:27 +08:00
|
|
|
Please see the {{SECT:Schema Specification}} chapter for
|
|
|
|
information regarding how to use this directive.
|
2000-08-11 08:23:10 +08:00
|
|
|
|
1999-04-24 07:00:44 +08:00
|
|
|
|
2000-08-11 01:49:29 +08:00
|
|
|
H4: referral <URI>
|
1999-04-24 07:00:44 +08:00
|
|
|
|
2000-08-10 09:38:36 +08:00
|
|
|
This directive specifies the referral to pass back when slapd
|
1999-04-24 07:00:44 +08:00
|
|
|
cannot find a local database to handle a request.
|
|
|
|
|
|
|
|
\Example:
|
|
|
|
|
2000-08-10 13:23:38 +08:00
|
|
|
> referral ldap://root.openldap.org
|
1999-04-24 07:00:44 +08:00
|
|
|
|
2000-08-10 09:38:36 +08:00
|
|
|
This will refer non-local queries to the global root LDAP server
|
|
|
|
at the OpenLDAP Project. Smart LDAP clients can re-ask their
|
1999-04-24 07:00:44 +08:00
|
|
|
query at that server, but note that most of these clients are
|
|
|
|
only going to know how to handle simple LDAP URLs that
|
|
|
|
contain a host part and optionally a distinguished name part.
|
|
|
|
|
|
|
|
|
|
|
|
H4: sizelimit <integer>
|
|
|
|
|
2000-08-10 09:38:36 +08:00
|
|
|
This directive specifies the maximum number of entries to return
|
1999-04-24 07:00:44 +08:00
|
|
|
from a search operation.
|
|
|
|
|
|
|
|
\Default:
|
|
|
|
|
2000-08-10 13:23:38 +08:00
|
|
|
> sizelimit 500
|
1999-04-24 07:00:44 +08:00
|
|
|
|
|
|
|
|
|
|
|
H4: timelimit <integer>
|
|
|
|
|
2000-08-10 09:38:36 +08:00
|
|
|
This directive specifies the maximum number of seconds (in real
|
1999-04-24 07:00:44 +08:00
|
|
|
time) slapd will spend answering a search request. If a
|
|
|
|
request is not finished in this time, a result indicating an
|
|
|
|
exceeded timelimit will be returned.
|
|
|
|
|
|
|
|
\Default:
|
|
|
|
|
2000-08-10 13:23:38 +08:00
|
|
|
> timelimit 3600
|
1999-04-24 07:00:44 +08:00
|
|
|
|
|
|
|
|
2000-08-10 09:38:36 +08:00
|
|
|
H3: General Backend Directives
|
1999-04-24 07:00:44 +08:00
|
|
|
|
2000-09-01 02:36:01 +08:00
|
|
|
Directives in this section apply only to the backend in which
|
|
|
|
they are defined. They are supported by every type of backend.
|
|
|
|
Backend directives apply to all databases instances of the
|
|
|
|
same type and, depending on the directive, may be overridden
|
|
|
|
by database directives.
|
|
|
|
|
|
|
|
H4: backend <type>
|
|
|
|
|
2002-06-15 05:19:42 +08:00
|
|
|
This directive marks the beginning of a backend declaration.
|
2002-06-15 09:00:50 +08:00
|
|
|
{{EX:<type>}} should be one of the
|
2002-06-15 05:19:42 +08:00
|
|
|
supported backend types listed in Table 5.2.
|
|
|
|
|
|
|
|
!block table; align=Center; coltags="EX,N"; \
|
|
|
|
title="Table 5.2: Database Backends"
|
|
|
|
Types Description
|
|
|
|
bdb Berkeley DB transactional backend
|
|
|
|
dnssrv DNS SRV backend
|
|
|
|
ldap Lightweight Directory Access Protocol (Proxy) backend
|
2002-09-09 14:53:11 +08:00
|
|
|
ldbm Lightweight DBM backend
|
2002-06-15 05:19:42 +08:00
|
|
|
meta Meta Directory backend
|
|
|
|
monitor Monitor backend
|
|
|
|
passwd Provides read-only access to {{passwd}}(5)
|
|
|
|
perl Perl Programmable backend
|
|
|
|
shell Shell (extern program) backend
|
|
|
|
sql SQL Programmable backend
|
|
|
|
!endblock
|
|
|
|
|
|
|
|
\Example:
|
|
|
|
|
2002-06-15 09:00:50 +08:00
|
|
|
> backend bdb
|
2002-06-15 05:19:42 +08:00
|
|
|
|
|
|
|
This marks the beginning of a new {{TERM:BDB}} backend
|
|
|
|
definition.
|
2000-09-01 02:36:01 +08:00
|
|
|
|
|
|
|
|
2000-08-10 09:38:36 +08:00
|
|
|
H3: General Database Directives
|
1999-04-24 07:00:44 +08:00
|
|
|
|
2000-09-01 02:36:01 +08:00
|
|
|
Directives in this section apply only to the database in which
|
2000-08-10 09:38:36 +08:00
|
|
|
they are defined. They are supported by every type of database.
|
1999-04-24 07:00:44 +08:00
|
|
|
|
2000-09-01 02:36:01 +08:00
|
|
|
H4: database <type>
|
1999-04-24 07:00:44 +08:00
|
|
|
|
2002-06-15 05:19:42 +08:00
|
|
|
This directive marks the beginning of a database instance
|
|
|
|
declaration.
|
2002-06-15 09:00:50 +08:00
|
|
|
{{EX:<type>}} should be one of the
|
2002-06-15 05:19:42 +08:00
|
|
|
supported backend types listed in Table 5.2.
|
1999-04-24 07:00:44 +08:00
|
|
|
|
|
|
|
\Example:
|
|
|
|
|
2002-06-15 05:19:42 +08:00
|
|
|
> database bdb
|
1999-04-24 07:00:44 +08:00
|
|
|
|
2002-06-15 05:19:42 +08:00
|
|
|
This marks the beginning of a new {{TERM:BDB}} database instance
|
|
|
|
declaration.
|
1999-04-24 07:00:44 +08:00
|
|
|
|
|
|
|
|
|
|
|
H4: readonly { on | off }
|
|
|
|
|
2000-08-10 09:38:36 +08:00
|
|
|
This directive puts the database into "read-only" mode. Any
|
1999-04-24 07:00:44 +08:00
|
|
|
attempts to modify the database will return an "unwilling to
|
|
|
|
perform" error.
|
|
|
|
|
|
|
|
\Default:
|
|
|
|
|
2000-08-10 13:23:38 +08:00
|
|
|
> readonly off
|
1999-04-24 07:00:44 +08:00
|
|
|
|
|
|
|
H4: replica
|
|
|
|
|
2003-09-27 15:14:29 +08:00
|
|
|
> replica uri=ldap[s]://<hostname>[:<port>] | host=<hostname>[:<port>]
|
2003-09-16 12:39:14 +08:00
|
|
|
> [bindmethod={simple|kerberos|sasl}]
|
2000-08-24 07:23:16 +08:00
|
|
|
> ["binddn=<DN>"]
|
2003-09-16 12:39:14 +08:00
|
|
|
> [saslmech=<mech>]
|
2000-08-24 07:23:16 +08:00
|
|
|
> [authcid=<identity>]
|
|
|
|
> [authzid=<identity>]
|
2000-08-10 13:23:38 +08:00
|
|
|
> [credentials=<password>]
|
|
|
|
> [srvtab=<filename>]
|
2000-08-10 09:38:36 +08:00
|
|
|
|
|
|
|
This directive specifies a replication site for this database. The
|
2003-09-27 15:14:29 +08:00
|
|
|
{{EX:uri=}} parameter specifies a scheme, a host and optionally a port where
|
1999-04-24 07:00:44 +08:00
|
|
|
the slave slapd instance can be found. Either a domain name
|
|
|
|
or IP address may be used for <hostname>. If <port> is not
|
2003-09-27 15:14:29 +08:00
|
|
|
given, the standard LDAP port number (389 or 636) is used.
|
|
|
|
|
|
|
|
{{EX:host}} is deprecated in favor of the {{EX:uri}} parameter.
|
|
|
|
|
|
|
|
{{EX:uri}} allows the replica LDAP server to be specified as an LDAP
|
|
|
|
URI such as {{EX:ldap://slave.example.com:389}} or
|
|
|
|
{{EX:ldaps://slave.example.com:636}}.
|
1999-04-24 07:00:44 +08:00
|
|
|
|
2000-08-10 13:23:38 +08:00
|
|
|
The {{EX:binddn=}} parameter gives the DN to bind as for updates to
|
1999-04-24 07:00:44 +08:00
|
|
|
the slave slapd. It should be a DN which has read/write
|
|
|
|
access to the slave slapd's database, typically given as a
|
2000-08-10 13:23:38 +08:00
|
|
|
{{EX:rootdn}} in the slave's config file. It must also match the
|
2000-08-24 07:23:16 +08:00
|
|
|
{{EX:updatedn}} directive in the slave slapd's config file. Since DNs are
|
2000-08-10 13:23:38 +08:00
|
|
|
likely to contain embedded spaces, the entire {{EX:"binddn=<DN>"}}
|
|
|
|
string should be enclosed in double quotes.
|
1999-04-24 07:00:44 +08:00
|
|
|
|
2000-08-24 07:23:16 +08:00
|
|
|
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.
|
|
|
|
|
|
|
|
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
|
2000-09-05 06:51:48 +08:00
|
|
|
mechanisms, in particular the {{EX:KERBEROS_V4}} and {{EX:GSSAPI}}
|
2000-08-24 07:23:16 +08:00
|
|
|
mechanisms. Kerberos authentication requires {{EX:binddn}} and
|
|
|
|
{{EX:srvtab}} parameters.
|
|
|
|
|
|
|
|
SASL authentication is generally recommended. SASL authentication
|
2003-09-16 12:39:14 +08:00
|
|
|
requires specification of a mechanism using the {{EX:saslmech}} parameter.
|
2000-08-24 07:23:16 +08:00
|
|
|
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.
|
2000-08-11 06:31:41 +08:00
|
|
|
|
2000-09-05 06:51:48 +08:00
|
|
|
See the chapter entitled {{SECT:Replication with slurpd}} for more
|
|
|
|
information on how to use this directive.
|
1999-04-24 07:00:44 +08:00
|
|
|
|
|
|
|
|
|
|
|
H4: replogfile <filename>
|
|
|
|
|
2000-08-10 09:38:36 +08:00
|
|
|
This directive specifies the name of the replication log file to
|
1999-04-24 07:00:44 +08:00
|
|
|
which slapd will log changes. The replication log is typically
|
2000-08-10 09:38:36 +08:00
|
|
|
written by slapd and read by slurpd. Normally, this directive is
|
1999-04-24 07:00:44 +08:00
|
|
|
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.
|
|
|
|
|
2000-09-05 06:51:48 +08:00
|
|
|
See the chapter entitled {{SECT:Replication with slurpd}} for more
|
|
|
|
information on how to use this directive.
|
2000-08-11 06:31:41 +08:00
|
|
|
|
1999-04-24 07:00:44 +08:00
|
|
|
|
2003-11-25 07:18:06 +08:00
|
|
|
H4: rootdn <DN>
|
1999-04-24 07:00:44 +08:00
|
|
|
|
2000-08-11 06:31:41 +08:00
|
|
|
This directive specifies the DN that is not subject to
|
1999-04-24 07:00:44 +08:00
|
|
|
access control or administrative limit restrictions for
|
2000-08-11 06:31:41 +08:00
|
|
|
operations on this database. The DN need not refer to
|
2002-06-17 13:33:32 +08:00
|
|
|
an entry in this database or even in the directory. The
|
|
|
|
DN may refer to a SASL identity.
|
1999-04-24 07:00:44 +08:00
|
|
|
|
2000-08-11 06:31:41 +08:00
|
|
|
Entry-based Example:
|
1999-04-24 07:00:44 +08:00
|
|
|
|
2000-10-24 03:00:05 +08:00
|
|
|
> rootdn "cn=Manager,dc=example,dc=com"
|
1999-04-24 07:00:44 +08:00
|
|
|
|
2000-08-11 06:31:41 +08:00
|
|
|
SASL-based Example:
|
|
|
|
|
2002-06-15 09:00:50 +08:00
|
|
|
> rootdn "uid=root,cn=example.com,cn=digest-md5,cn=auth"
|
2000-08-11 06:31:41 +08:00
|
|
|
|
2002-06-18 08:23:40 +08:00
|
|
|
See the {{SECT:SASL Authentication}} section for information on
|
|
|
|
SASL authentication identities.
|
|
|
|
|
2000-08-11 06:31:41 +08:00
|
|
|
|
1999-04-24 07:00:44 +08:00
|
|
|
H4: rootpw <password>
|
|
|
|
|
2002-06-17 13:33:32 +08:00
|
|
|
This directive can be used to specifies a password for the DN for
|
2002-09-01 10:54:56 +08:00
|
|
|
the rootdn (when the rootdn is set to a DN within the database).
|
1999-04-24 07:00:44 +08:00
|
|
|
|
|
|
|
\Example:
|
|
|
|
|
2000-08-10 13:23:38 +08:00
|
|
|
> rootpw secret
|
1999-04-24 07:00:44 +08:00
|
|
|
|
2002-09-01 10:54:56 +08:00
|
|
|
It is also permissible to provide hash of the password in RFC 2307
|
|
|
|
form. {{slappasswd}}(8) may be used to generate the password hash.
|
2002-06-17 13:33:32 +08:00
|
|
|
|
|
|
|
\Example:
|
|
|
|
|
|
|
|
> rootpw {SSHA}ZKKuqbEKJfKSXhUbHG3fG8MDn9j1v4QN
|
|
|
|
|
|
|
|
The hash was generated using the command {{EX:slappasswd -s secret}}.
|
|
|
|
|
2000-08-11 06:31:41 +08:00
|
|
|
|
1999-04-24 07:00:44 +08:00
|
|
|
H4: suffix <dn suffix>
|
|
|
|
|
2000-08-10 09:38:36 +08:00
|
|
|
This directive specifies the DN suffix of queries that will be
|
1999-04-24 07:00:44 +08:00
|
|
|
passed to this backend database. Multiple suffix lines can be
|
|
|
|
given, and at least one is required for each database
|
|
|
|
definition.
|
|
|
|
|
|
|
|
\Example:
|
|
|
|
|
2000-10-24 03:00:05 +08:00
|
|
|
> suffix "dc=example,dc=com"
|
1999-04-24 07:00:44 +08:00
|
|
|
|
2000-10-24 03:00:05 +08:00
|
|
|
Queries with a DN ending in "dc=example,dc=com"
|
1999-04-24 07:00:44 +08:00
|
|
|
will be passed to this backend.
|
|
|
|
|
2000-08-30 13:05:26 +08:00
|
|
|
Note: When the backend to pass a query to is selected, slapd
|
1999-04-24 07:00:44 +08:00
|
|
|
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.
|
|
|
|
|
2003-11-24 22:44:30 +08:00
|
|
|
|
2003-09-16 13:16:33 +08:00
|
|
|
H4: syncrepl
|
|
|
|
|
|
|
|
> syncrepl id=<replica ID>
|
|
|
|
> provider=ldap[s]://<hostname>[:port]
|
2003-11-25 02:57:22 +08:00
|
|
|
> [type=refreshOnly|refreshAndPersist]
|
|
|
|
> [interval=dd:hh:mm:ss]
|
2003-09-16 13:16:33 +08:00
|
|
|
> [searchbase=<base DN>]
|
|
|
|
> [filter=<filter str>]
|
|
|
|
> [scope=sub|one|base]
|
2003-11-25 02:57:22 +08:00
|
|
|
> [attrs=<attr list>]
|
|
|
|
> [attrsonly]
|
2003-11-24 22:44:30 +08:00
|
|
|
> [sizelimit=<limit>]
|
|
|
|
> [timelimit=<limit>]
|
2003-09-16 13:16:33 +08:00
|
|
|
> [schemachecking=on|off]
|
2003-11-25 07:18:06 +08:00
|
|
|
> [updatedn=<DN>]
|
2003-11-25 02:57:22 +08:00
|
|
|
> [bindmethod=simple|sasl]
|
2003-11-25 07:18:06 +08:00
|
|
|
> [binddn=<DN>]
|
2003-11-25 02:57:22 +08:00
|
|
|
> [saslmech=<mech>]
|
|
|
|
> [authcid=<identity>]
|
|
|
|
> [authzid=<identity>]
|
|
|
|
> [credentials=<passwd>]
|
|
|
|
> [realm=<realm>]
|
|
|
|
> [secprops=<properties>]
|
2003-11-24 22:44:30 +08:00
|
|
|
|
2003-11-25 07:18:06 +08:00
|
|
|
|
2003-11-24 22:44:30 +08:00
|
|
|
This directive specifies the current database as a replica of the
|
2003-11-25 07:18:06 +08:00
|
|
|
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.
|
2003-11-24 22:44:30 +08:00
|
|
|
|
|
|
|
The {{EX:id}} parameter is used for identification of the current
|
2003-11-25 07:18:06 +08:00
|
|
|
{{EX:syncrepl}} directive in the database, 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.
|
2003-11-24 22:44:30 +08:00
|
|
|
|
|
|
|
The {{EX:provider}} parameter specifies the replication provider site
|
2003-11-25 07:18:06 +08:00
|
|
|
containing the master content as an LDAP URI. The {{EX:provider}}
|
2003-11-24 22:44:30 +08:00
|
|
|
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.
|
2003-11-25 07:18:06 +08:00
|
|
|
Note that the syncrepl uses a consumer-initiated protocol, and hence its
|
2003-11-24 22:44:30 +08:00
|
|
|
specification is located at the consumer site, whereas the {{EX:replica}}
|
|
|
|
specification is located at the provider site. {{EX:syncrepl}} and
|
2003-11-25 07:18:06 +08:00
|
|
|
{{EX:replica}} directives define two independent replication
|
|
|
|
mechanisms. They do not represent the replication peers of each other.
|
2003-11-24 22:44:30 +08:00
|
|
|
|
2003-11-25 07:18:06 +08:00
|
|
|
The content of the syncrepl replica is defined using a search
|
|
|
|
specification as its result set. The consumer slapd will
|
2003-11-25 04:50:23 +08:00
|
|
|
send search requests to the provider slapd according to the search
|
2003-11-25 02:57:22 +08:00
|
|
|
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
|
2003-11-25 07:18:06 +08:00
|
|
|
search specification. The syncrepl search specification has
|
2003-11-25 04:50:23 +08:00
|
|
|
the same value syntax and the same default values as in the
|
|
|
|
{{ldapsearch}}(1) client search tool.
|
2003-11-25 02:57:22 +08:00
|
|
|
|
|
|
|
The LDAP Content Synchronization protocol has two operation
|
|
|
|
types: {{EX:refreshOnly}} and {{EX:refreshAndPersist}}.
|
2003-11-24 22:44:30 +08:00
|
|
|
The operation type is specified by the {{EX:type}} parameter.
|
2003-11-25 07:18:06 +08:00
|
|
|
In the {{EX:refreshOnly}} operation, the next synchronization search operation
|
2003-11-25 02:57:22 +08:00
|
|
|
is periodically rescheduled at an interval time after each
|
2003-11-24 22:44:30 +08:00
|
|
|
synchronization operation finishes. The interval is specified
|
|
|
|
by the {{EX:interval}} parameter. It is set to one day by default.
|
2003-11-25 07:18:06 +08:00
|
|
|
In the {{EX:refreshAndPersist}} operation, a synchronization search
|
2003-11-24 22:44:30 +08:00
|
|
|
remains persistent in the provider slapd. Further updates to the
|
2003-11-25 07:18:06 +08:00
|
|
|
master replica will generate {{EX:searchResultEntry}} to the consumer slapd
|
2003-11-25 02:57:22 +08:00
|
|
|
as the search responses to the persistent synchronization search.
|
2003-09-16 13:16:33 +08:00
|
|
|
|
|
|
|
The schema checking can be enforced at the LDAP Sync consumer site
|
2003-11-25 07:18:06 +08:00
|
|
|
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:updatedn}} parameter specifies the DN in the consumer site
|
2003-11-25 02:57:22 +08:00
|
|
|
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.
|
|
|
|
It is typically given as a {{EX:rootdn}} in the consumer site's
|
|
|
|
config file.
|
|
|
|
|
|
|
|
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.
|
2003-09-16 13:16:33 +08:00
|
|
|
|
|
|
|
Simple authentication should not be used unless adequate integrity
|
2003-11-25 02:57:22 +08:00
|
|
|
and privacy protections are in place (e.g. TLS or IPSEC). Simple
|
|
|
|
authentication requires specification of {{EX:binddn}} and
|
2003-09-16 13:16:33 +08:00
|
|
|
{{EX:credentials}} parameters.
|
|
|
|
|
2003-11-25 02:57:22 +08:00
|
|
|
SASL authentication is generally recommended. SASL authentication
|
|
|
|
requires specification of a mechanism using the {{EX:saslmech}} parameter.
|
2003-09-16 13:16:33 +08:00
|
|
|
Depending on the mechanism, an authentication identity and/or
|
2003-11-25 02:57:22 +08:00
|
|
|
credentials can be specified using {{EX:authcid}} and {{EX:credentials}},
|
2003-09-16 13:16:33 +08:00
|
|
|
respectively. The {{EX:authzid}} parameter may be used to specify
|
2003-11-25 02:57:22 +08:00
|
|
|
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.
|
2003-09-16 13:16:33 +08:00
|
|
|
|
2003-11-25 02:57:22 +08:00
|
|
|
The syncrepl replication mechanism is supported by the
|
|
|
|
three native backends: back-bdb, back-hdb, and back-ldbm.
|
2003-09-16 13:16:33 +08:00
|
|
|
|
2003-11-24 22:44:30 +08:00
|
|
|
See the {{SECT:LDAP Sync Replication}} chapter of the admin guide
|
|
|
|
for more information on how to use this directive.
|
2000-08-12 14:35:08 +08:00
|
|
|
|
1999-04-24 07:00:44 +08:00
|
|
|
|
2003-11-25 07:18:06 +08:00
|
|
|
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
|
|
|
|
|
|
|
|
|
2002-06-15 05:19:42 +08:00
|
|
|
H3: BDB Database Directives
|
|
|
|
|
2002-06-17 02:59:17 +08:00
|
|
|
Directives in this category only apply to a {{TERM:BDB}} database.
|
|
|
|
That is, they must follow a "database bdb" line and come before any
|
|
|
|
subsequent "backend" or "database" line. For a complete reference
|
|
|
|
of BDB configuration directives, see {{slapd-bdb}}(5).
|
2002-06-15 05:19:42 +08:00
|
|
|
|
2003-11-25 03:43:43 +08:00
|
|
|
|
2002-06-15 05:19:42 +08:00
|
|
|
H4: directory <directory>
|
|
|
|
|
|
|
|
This directive specifies the directory where the BDB files
|
2002-06-15 09:00:50 +08:00
|
|
|
containing the database and associated indices live.
|
2002-06-15 05:19:42 +08:00
|
|
|
|
|
|
|
\Default:
|
|
|
|
|
|
|
|
> directory /usr/local/var/openldap-data
|
|
|
|
|
|
|
|
|
2003-11-25 03:43:43 +08:00
|
|
|
H4: sessionlog <sid> <limit>
|
|
|
|
|
2003-11-25 07:18:06 +08:00
|
|
|
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>}}.
|
2003-11-25 03:43:43 +08:00
|
|
|
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
|
2003-11-25 07:18:06 +08:00
|
|
|
in the FIFO order. Both {{EX:<sid>}} and {{EX:<limit>}} are
|
|
|
|
non-negative integers. {{EX:<sid>}} has no more than three digits.
|
2003-11-25 03:43:43 +08:00
|
|
|
|
2003-11-25 07:18:06 +08:00
|
|
|
The LDAP Content Synchronization operation that falls into a pre-existing
|
2003-11-25 03:43:43 +08:00
|
|
|
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,
|
2003-11-25 07:18:06 +08:00
|
|
|
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
|
2003-11-25 03:43:43 +08:00
|
|
|
beyond the coverage of the history store, then the provider slapd will
|
2003-11-25 07:18:06 +08:00
|
|
|
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
|
2003-11-25 03:43:43 +08:00
|
|
|
master content.
|
|
|
|
|
|
|
|
An access control mechanism is to be further provided to
|
|
|
|
make the session joining controllable.
|
|
|
|
|
|
|
|
|
2002-06-15 05:19:42 +08:00
|
|
|
H3: LDBM Database Directives
|
1999-04-24 07:00:44 +08:00
|
|
|
|
2002-06-17 02:59:17 +08:00
|
|
|
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).
|
1999-04-24 07:00:44 +08:00
|
|
|
|
|
|
|
H4: cachesize <integer>
|
|
|
|
|
2000-08-10 09:38:36 +08:00
|
|
|
This directive specifies the size in entries of the in-memory
|
1999-04-24 07:00:44 +08:00
|
|
|
cache maintained by the LDBM backend database instance.
|
|
|
|
|
|
|
|
\Default:
|
|
|
|
|
2000-08-10 13:23:38 +08:00
|
|
|
> cachesize 1000
|
1999-04-24 07:00:44 +08:00
|
|
|
|
|
|
|
|
|
|
|
H4: dbcachesize <integer>
|
|
|
|
|
2000-08-10 09:38:36 +08:00
|
|
|
This directive specifies the size in bytes of the in-memory cache
|
1999-04-24 07:00:44 +08:00
|
|
|
associated with each open index file. If not supported by the
|
2000-08-10 09:38:36 +08:00
|
|
|
underlying database method, this directive is ignored without
|
1999-04-24 07:00:44 +08:00
|
|
|
comment. Increasing this number uses more memory but can
|
|
|
|
cause a dramatic performance increase, especially during
|
2002-06-15 09:00:50 +08:00
|
|
|
modifies or when building indices.
|
1999-04-24 07:00:44 +08:00
|
|
|
|
|
|
|
\Default:
|
|
|
|
|
2000-08-10 13:23:38 +08:00
|
|
|
> dbcachesize 100000
|
1999-04-24 07:00:44 +08:00
|
|
|
|
|
|
|
|
2000-08-12 14:35:08 +08:00
|
|
|
H4: dbnolocking
|
|
|
|
|
|
|
|
This option, if present, disables database locking.
|
|
|
|
Enabling this option may improve performance at the expense
|
|
|
|
of data security.
|
|
|
|
|
|
|
|
|
|
|
|
H4: dbnosync
|
|
|
|
|
2002-06-15 09:00:50 +08:00
|
|
|
This option causes on-disk database contents to not be immediately
|
2000-08-12 14:35:08 +08:00
|
|
|
synchronized with in memory changes upon change. Enabling this option
|
2002-06-15 09:00:50 +08:00
|
|
|
may improve performance at the expense of data integrity.
|
2000-08-12 14:35:08 +08:00
|
|
|
|
|
|
|
|
1999-04-24 07:00:44 +08:00
|
|
|
H4: directory <directory>
|
|
|
|
|
2000-08-10 09:38:36 +08:00
|
|
|
This directive specifies the directory where the LDBM files
|
2002-06-15 09:00:50 +08:00
|
|
|
containing the database and associated indices live.
|
1999-04-24 07:00:44 +08:00
|
|
|
|
|
|
|
\Default:
|
|
|
|
|
2002-06-15 05:19:42 +08:00
|
|
|
> directory /usr/local/var/openldap-data
|
1999-04-24 07:00:44 +08:00
|
|
|
|
|
|
|
|
|
|
|
H4: index {<attrlist> | default} [pres,eq,approx,sub,none]
|
|
|
|
|
2002-06-15 09:00:50 +08:00
|
|
|
This directive specifies the indices to maintain for the given
|
2000-08-11 06:31:41 +08:00
|
|
|
attribute. If only an {{EX:<attrlist>}} is given, the default
|
2002-06-15 09:00:50 +08:00
|
|
|
indices are maintained.
|
2000-08-11 06:31:41 +08:00
|
|
|
|
1999-04-24 07:00:44 +08:00
|
|
|
\Example:
|
|
|
|
|
2000-08-10 13:23:38 +08:00
|
|
|
> index default pres,eq
|
2001-06-13 04:57:19 +08:00
|
|
|
> 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.
|
1999-04-24 07:00:44 +08:00
|
|
|
|
2001-09-02 01:49:27 +08:00
|
|
|
By default, no indices are maintained. It is generally advised
|
|
|
|
that minimally an equality index upon objectClass be maintained.
|
|
|
|
|
|
|
|
> index objectClass eq
|
|
|
|
|
|
|
|
|
|
|
|
|
1999-04-24 07:00:44 +08:00
|
|
|
H4: mode <integer>
|
|
|
|
|
2000-08-10 09:38:36 +08:00
|
|
|
This directive specifies the file protection mode that newly
|
1999-04-24 07:00:44 +08:00
|
|
|
created database index files should have.
|
|
|
|
|
|
|
|
\Default:
|
|
|
|
|
2000-08-10 13:23:38 +08:00
|
|
|
> mode 0600
|
1999-04-24 07:00:44 +08:00
|
|
|
|
|
|
|
|
|
|
|
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:
|
|
|
|
|
2000-08-10 13:23:38 +08:00
|
|
|
> <access directive> ::= access to <what>
|
|
|
|
> [by <who> <access> <control>]+
|
2002-09-09 14:53:11 +08:00
|
|
|
> <what> ::= * |
|
|
|
|
> [dn[.<basic-style>]=<regex> | dn.<scope-style>=<DN>]
|
2000-08-10 13:23:38 +08:00
|
|
|
> [filter=<ldapfilter>] [attrs=<attrlist>]
|
2002-09-09 14:53:11 +08:00
|
|
|
> <basic-style> ::= regex | exact
|
|
|
|
> <scope-style> ::= base | one | subtree | children
|
2003-09-21 19:07:32 +08:00
|
|
|
> <attrlist> ::= <attr> [val[.<basic-style>]=<regex>] | <attr> , <attrlist>
|
2000-08-10 13:23:38 +08:00
|
|
|
> <attr> ::= <attrname> | entry | children
|
2002-09-09 14:53:11 +08:00
|
|
|
> <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>]
|
2000-08-10 13:23:38 +08:00
|
|
|
> [set=<setspec>]
|
|
|
|
> [aci=<attrname>]
|
|
|
|
> <access> ::= [self]{<level>|<priv>}
|
|
|
|
> <level> ::= none | auth | compare | search | read | write
|
|
|
|
> <priv> ::= {=|+|-}{w|r|s|c|x}+
|
|
|
|
> <control> ::= [stop | continue | break]
|
1999-04-24 07:00:44 +08:00
|
|
|
|
2002-09-09 14:53:11 +08:00
|
|
|
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.
|
1999-04-24 07:00:44 +08:00
|
|
|
|
|
|
|
|
|
|
|
H3: What to control access to
|
|
|
|
|
2002-09-09 14:53:11 +08:00
|
|
|
The <what> part of an access specification determines the entries
|
|
|
|
and attributes to which the access control applies. Entries are
|
2002-09-09 14:59:51 +08:00
|
|
|
commonly selected in two ways: by DN and by filter. The following
|
|
|
|
qualifiers select entries by DN:
|
2002-09-09 14:53:11 +08:00
|
|
|
|
|
|
|
> by *
|
|
|
|
> by dn[.<basic-style>]=<regex>
|
|
|
|
> by dn.<scope-style>=<DN>
|
1999-04-24 07:00:44 +08:00
|
|
|
|
2002-09-09 14:53:11 +08:00
|
|
|
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
|
2002-09-09 15:01:51 +08:00
|
|
|
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}}.
|
1999-04-24 07:00:44 +08:00
|
|
|
|
2002-09-09 14:53:11 +08:00
|
|
|
The scope can be either {{EX:base}}, {{EX:one}}, {{EX:subtree}},
|
|
|
|
or {{EX:children}}. Where {{EX:base}} matches only the entry with
|
|
|
|
provided DN, {{EX:one}} matches the entries whose parent is the
|
|
|
|
provided DN, {{EX:subtree}} matches all entries in the subtree whose
|
|
|
|
root is the provided DN, and {{EX:children}} matches all entries
|
|
|
|
under the DN (but not the entry named by the DN).
|
1999-04-24 07:00:44 +08:00
|
|
|
|
2002-09-09 14:53:11 +08:00
|
|
|
For example, if the directory contained entries named:
|
1999-04-24 07:00:44 +08:00
|
|
|
|
2002-09-09 14:53:11 +08:00
|
|
|
> 0: o=suffix
|
|
|
|
> 1: cn=Manager,o=suffix
|
|
|
|
> 2: ou=people,o=suffix
|
|
|
|
> 3: uid=kdz,ou=people,o=suffix
|
|
|
|
> 4: cn=addresses,uid=kdz,ou=people,o=suffix
|
|
|
|
> 5: uid=hyc,ou=people,o=suffix
|
|
|
|
|
|
|
|
\Then:
|
|
|
|
. {{EX:dn.base="ou=people,o=suffix"}} match 2;
|
|
|
|
. {{EX:dn.one="ou=people,o=suffix"}} match 3, and 5;
|
|
|
|
. {{EX:dn.subtree="ou=people,o=suffix"}} match 2, 3, 4, and 5; and
|
|
|
|
. {{EX:dn.children="ou=people,o=suffix"}} match 3, 4, and 5.
|
|
|
|
|
|
|
|
|
|
|
|
Entries may also be selected using a filter:
|
|
|
|
|
|
|
|
> by filter=<ldap filter>
|
1999-04-24 07:00:44 +08:00
|
|
|
|
|
|
|
where <ldap filter> is a string representation of an LDAP
|
2002-09-09 14:53:11 +08:00
|
|
|
search filter, as described in {{REF:RFC2254}}. For example:
|
|
|
|
|
|
|
|
> by filter=(objectClass=person)
|
|
|
|
|
2003-04-07 19:13:57 +08:00
|
|
|
Note that entries may be selected by both DN and filter by
|
|
|
|
including both qualifiers in the <what> clause.
|
1999-04-24 07:00:44 +08:00
|
|
|
|
2002-09-09 14:53:11 +08:00
|
|
|
> by dn.one="ou=people,o=suffix" filter=(objectClass=person)
|
|
|
|
|
|
|
|
Attributes within an entry are selected by including a comma-separated
|
|
|
|
list of attribute names in the <what> selector:
|
1999-04-24 07:00:44 +08:00
|
|
|
|
2000-08-10 13:23:38 +08:00
|
|
|
> attrs=<attribute list>
|
1999-04-24 07:00:44 +08:00
|
|
|
|
2003-09-21 19:07:32 +08:00
|
|
|
A specific value of an attribute is selected by using a single
|
|
|
|
attribute name and also using a value selector:
|
|
|
|
|
|
|
|
> attrs=<attribute> val[.<style>]=<regex>
|
|
|
|
|
2003-04-07 19:35:58 +08:00
|
|
|
There are two special {{pseudo}} attributes {{EX:entry}} and
|
2003-09-21 19:07:32 +08:00
|
|
|
{{EX:children}}. To read (and hence return) a target entry, the
|
2002-09-09 08:47:01 +08:00
|
|
|
subject must have {{EX:read}} access to the target's {{entry}}
|
|
|
|
attribute. To add or delete an entry, the subject must have
|
2002-10-10 12:27:23 +08:00
|
|
|
{{EX:write}} access to the entry's {{EX:entry}} attribute AND must
|
|
|
|
have {{EX:write}} access to the entry's parent's {{EX:children}}
|
|
|
|
attribute. To rename an entry, the subject must have {{EX:write}}
|
|
|
|
access to entry's {{EX:entry}} attribute AND have {{EX:write}}
|
|
|
|
access to both the old parent's and new parent's {{EX:children}}
|
|
|
|
attributes. The complete examples at the end of this section should
|
|
|
|
help clear things up.
|
1999-04-24 07:00:44 +08:00
|
|
|
|
2000-08-30 13:05:26 +08:00
|
|
|
Lastly, there is a special entry selector {{EX:"*"}} that is used to
|
2000-08-11 09:21:14 +08:00
|
|
|
select any entry. It is used when no other {{EX:<what>}}
|
|
|
|
selector has been provided. It's equivalent to "{{EX:dn=.*}}"
|
1999-04-24 07:00:44 +08:00
|
|
|
|
|
|
|
|
2000-08-11 03:20:11 +08:00
|
|
|
H3: Who to grant access to
|
1999-04-24 07:00:44 +08:00
|
|
|
|
|
|
|
The <who> part identifies the entity or entities being granted
|
|
|
|
access. Note that access is granted to "entities" not "entries."
|
2000-08-30 13:05:26 +08:00
|
|
|
The following table summarizes entity specifiers:
|
2000-08-11 09:21:14 +08:00
|
|
|
|
2000-08-13 15:48:13 +08:00
|
|
|
!block table; align=Center; coltags="EX,N"; \
|
2000-08-12 14:35:08 +08:00
|
|
|
title="Table 5.3: Access Entity Specifiers"
|
2002-09-09 14:53:11 +08:00
|
|
|
Specifier|Entities
|
|
|
|
*|All, including anonymous and authenticated users
|
|
|
|
anonymous|Anonymous (non-authenticated) users
|
|
|
|
users|Authenticated users
|
|
|
|
self|User associated with target entry
|
|
|
|
dn[.<basic-style>]=<regex>|Users matching a regular expression
|
|
|
|
dn.<scope-style>=<DN>|Users within scope of a DN
|
2000-08-11 09:21:14 +08:00
|
|
|
!endblock
|
|
|
|
|
2002-09-09 14:53:11 +08:00
|
|
|
The DN specifier behaves much like <what> clause DN specifiers.
|
1999-04-24 07:00:44 +08:00
|
|
|
|
2003-02-09 15:07:39 +08:00
|
|
|
Other control factors are also supported. For example, a {{EX:<who>}}
|
|
|
|
can be restricted by an entry listed in a DN-valued attribute in
|
|
|
|
the entry to which the access applies:
|
1999-04-24 07:00:44 +08:00
|
|
|
|
2000-08-10 13:23:38 +08:00
|
|
|
> dnattr=<dn-valued attribute name>
|
1999-04-24 07:00:44 +08:00
|
|
|
|
|
|
|
The dnattr specification is used to give access to an entry
|
|
|
|
whose DN is listed in an attribute of the entry (e.g., give
|
|
|
|
access to a group entry to whoever is listed as the owner of
|
|
|
|
the group entry).
|
|
|
|
|
2003-02-09 15:07:39 +08:00
|
|
|
Some factors may not be appropriate in all environments (or any).
|
|
|
|
For example, the domain factor relies on IP to domain name lookups.
|
|
|
|
As these can easily spoofed, the domain factor should not be avoided.
|
|
|
|
|
1999-04-24 07:00:44 +08:00
|
|
|
|
|
|
|
H3: The access to grant
|
|
|
|
|
|
|
|
|
|
|
|
The kind of <access> granted can be one of the following:
|
|
|
|
|
|
|
|
|
2000-08-13 15:48:13 +08:00
|
|
|
!block table; colaligns="LRL"; coltags="EX,EX,N"; align=Center; \
|
2000-08-12 14:35:08 +08:00
|
|
|
title="Table 5.4: Access Levels"
|
2000-08-30 13:05:26 +08:00
|
|
|
Level Privileges Description
|
2000-08-10 15:17:54 +08:00
|
|
|
none 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
|
|
|
|
!endblock
|
|
|
|
|
|
|
|
Each level implies all lower levels of access. So, for
|
2000-08-30 13:05:26 +08:00
|
|
|
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
|
|
|
|
to grant specific permissions.
|
1999-04-24 07:00:44 +08:00
|
|
|
|
|
|
|
|
|
|
|
H3: Access Control Evaluation
|
|
|
|
|
2001-05-18 10:45:46 +08:00
|
|
|
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.
|
2002-06-15 09:00:50 +08:00
|
|
|
For each entry, access controls provided in the database which holds
|
2001-05-18 10:45:46 +08:00
|
|
|
the entry (or the first database if not held in any database) apply
|
2002-06-15 09:00:50 +08:00
|
|
|
first, followed by the global access directives. Within this
|
2001-05-18 10:45:46 +08:00
|
|
|
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.
|
|
|
|
|
|
|
|
Next, slapd compares the entity requesting access to the {{EX:<who>}}
|
|
|
|
selectors within the access directive selected above in the order
|
|
|
|
in which they appear. It stops with the first {{EX:<who>}} selector
|
|
|
|
that matches the requester. This determines the access the entity
|
|
|
|
requesting access has to the entry and/or attribute.
|
1999-04-24 07:00:44 +08:00
|
|
|
|
|
|
|
Finally, slapd compares the access granted in the selected
|
2001-05-18 10:45:46 +08:00
|
|
|
{{EX:<access>}} clause to the access requested by the client. If
|
|
|
|
it allows greater or equal access, access is granted. Otherwise,
|
1999-04-24 07:00:44 +08:00
|
|
|
access is denied.
|
|
|
|
|
2001-05-18 10:45:46 +08:00
|
|
|
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>}}
|
|
|
|
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.
|
1999-04-24 07:00:44 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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:
|
|
|
|
|
2000-08-10 13:23:38 +08:00
|
|
|
> access to * by * read
|
1999-04-24 07:00:44 +08:00
|
|
|
|
2000-08-10 13:23:38 +08:00
|
|
|
This access directive grants read access to everyone.
|
1999-04-24 07:00:44 +08:00
|
|
|
|
2000-08-10 13:23:38 +08:00
|
|
|
> access to *
|
|
|
|
> by self write
|
|
|
|
> by anonymous auth
|
|
|
|
> by * read
|
|
|
|
|
2003-03-13 00:25:20 +08:00
|
|
|
This directive allows the user to modify their entry, allows anonymous
|
|
|
|
to authentication 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
|
|
|
|
have been "{{EX:by users read}}".
|
2002-06-16 08:11:51 +08:00
|
|
|
|
|
|
|
It is often desirable to restrict operations based upon the level
|
|
|
|
of protection in place. The following shows how security strength
|
|
|
|
factors (SSF) can be used.
|
|
|
|
|
|
|
|
> access 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,
|
2003-03-13 00:25:20 +08:00
|
|
|
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
|
|
|
|
implicit {{EX:by * none}} clause would be applied.
|
1999-04-24 07:00:44 +08:00
|
|
|
|
2003-03-13 00:25:20 +08:00
|
|
|
The following example shows the use of a style specifiers
|
1999-04-24 07:00:44 +08:00
|
|
|
to select the entries by DN in two access directives where
|
|
|
|
ordering is significant.
|
|
|
|
|
2002-09-09 14:53:11 +08:00
|
|
|
> access to dn.children="dc=example,dc=com"
|
2000-08-10 13:23:38 +08:00
|
|
|
> by * search
|
2002-09-09 14:53:11 +08:00
|
|
|
> access to dn.children="dc=com"
|
2000-08-10 13:23:38 +08:00
|
|
|
> by * read
|
1999-04-24 07:00:44 +08:00
|
|
|
|
2002-09-09 14:53:11 +08:00
|
|
|
Read access is granted to entries under the {{EX:dc=com}} subtree,
|
|
|
|
except for those entries under the {{EX:dc=example,dc=com}} subtree,
|
|
|
|
to which search access is granted. No access is granted to
|
|
|
|
{{EX:dc=com}} as neither access directive matches this DN. If the
|
|
|
|
order of these access directives was reversed, the trailing directive
|
|
|
|
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
|
|
|
|
to}} directive ends with an implicit {{EX:by * none}} clause and
|
|
|
|
every access list ends with an implicit {{EX:access to * by * none}}
|
|
|
|
directive.
|
|
|
|
|
|
|
|
The next example again shows the importance of ordering, both of
|
|
|
|
the access directives and the {{EX:by <who>}} clauses. It also
|
|
|
|
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
|
2000-08-10 13:23:38 +08:00
|
|
|
> by self write
|
2002-09-09 14:53:11 +08:00
|
|
|
> by dn.children=dc=example,dc=com" search
|
2003-02-09 15:07:39 +08:00
|
|
|
> by peername=IP:10\..+ read
|
2002-09-09 14:53:11 +08:00
|
|
|
> access to dn.subtree="dc=example,dc=com"
|
2000-08-10 13:23:38 +08:00
|
|
|
> by self write
|
2002-09-09 14:53:11 +08:00
|
|
|
> by dn.children="dc=example,dc=com" search
|
2000-08-10 13:23:38 +08:00
|
|
|
> by anonymous auth
|
1999-04-24 07:00:44 +08:00
|
|
|
|
2000-10-24 03:00:05 +08:00
|
|
|
This example applies to entries in the "{{EX:dc=example,dc=com}}"
|
2002-09-09 14:53:11 +08:00
|
|
|
subtree. To all attributes except {{EX:homePhone}}, an entry can
|
|
|
|
write to itself, entries under {{EX:example.com}} entries can search
|
|
|
|
by them, anybody else has no access (implicit {{EX:by * none}})
|
|
|
|
excepting for authentication/authorization (which is always done
|
|
|
|
anonymously). The {{EX:homePhone}} attribute is writable by the
|
|
|
|
entry, searchable by entries under {{EX:example.com}}, readable by
|
2003-02-09 15:07:39 +08:00
|
|
|
clients connecting from network 10, and otherwise not readable
|
|
|
|
(implicit {{EX:by * none}}). All other access is denied by the
|
|
|
|
implicit {{EX:access to * by * none}}.
|
1999-04-24 07:00:44 +08:00
|
|
|
|
|
|
|
Sometimes it is useful to permit a particular DN to add or
|
|
|
|
remove itself from an attribute. For example, if you would like to
|
2000-08-30 02:56:29 +08:00
|
|
|
create a group and allow people to add and remove only
|
1999-04-24 07:00:44 +08:00
|
|
|
their own DN from the member attribute, you could accomplish
|
|
|
|
it with an access directive like this:
|
|
|
|
|
2000-08-10 13:23:38 +08:00
|
|
|
> access to attr=member,entry
|
|
|
|
> by dnattr=member selfwrite
|
1999-04-24 07:00:44 +08:00
|
|
|
|
2000-08-10 13:23:38 +08:00
|
|
|
The dnattr {{EX:<who>}} selector says that the access applies to
|
2000-08-10 15:17:54 +08:00
|
|
|
entries listed in the {{EX:member}} attribute. The {{EX:selfwrite}} access
|
1999-04-24 07:00:44 +08:00
|
|
|
selector says that such members can only add or delete their
|
|
|
|
own DN from the attribute, not other values. The addition of
|
|
|
|
the entry attribute is required because access to the entry is
|
|
|
|
required to access any of the entry's attributes.
|
|
|
|
|
2000-08-11 09:21:14 +08:00
|
|
|
!if 0
|
|
|
|
For more details on how to use the {{EX:access}} directive,
|
|
|
|
consult the {{Advanced Access Control}} chapter.
|
|
|
|
!endif
|
2000-08-10 15:17:54 +08:00
|
|
|
|
1999-04-24 07:00:44 +08:00
|
|
|
|
|
|
|
H2: Configuration File Example
|
|
|
|
|
|
|
|
The following is an example configuration file, interspersed
|
|
|
|
with explanatory text. It defines two databases to handle
|
2002-06-15 05:19:42 +08:00
|
|
|
different parts of the {{TERM:X.500}} tree; both are {{TERM:BDB}}
|
2000-08-10 15:17:54 +08:00
|
|
|
database instances. The line numbers shown are provided for
|
1999-04-24 07:00:44 +08:00
|
|
|
reference only and are not included in the actual file. First, the
|
|
|
|
global configuration section:
|
|
|
|
|
2000-08-12 01:07:41 +08:00
|
|
|
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
|
|
|
|
|
2000-08-30 13:05:26 +08:00
|
|
|
Line 1 is a comment. Line 2 includes another config file
|
2002-06-15 09:00:50 +08:00
|
|
|
which contains {{core}} schema definitions.
|
2000-08-10 13:23:38 +08:00
|
|
|
The {{EX:referral}} directive on line 3
|
1999-04-24 07:00:44 +08:00
|
|
|
means that queries not local to one of the databases defined
|
|
|
|
below will be referred to the LDAP server running on the
|
2000-08-10 13:23:38 +08:00
|
|
|
standard port (389) at the host {{EX:root.openldap.org}}.
|
1999-04-24 07:00:44 +08:00
|
|
|
|
2001-05-18 10:45:46 +08:00
|
|
|
Line 4 is a global access control. It applies to all
|
|
|
|
entries (after any applicable database-specific access
|
|
|
|
controls).
|
2000-08-12 01:07:41 +08:00
|
|
|
|
2002-06-15 09:00:50 +08:00
|
|
|
The next section of the configuration file defines a BDB
|
1999-04-24 07:00:44 +08:00
|
|
|
backend that will handle queries for things in the
|
2000-08-10 09:38:36 +08:00
|
|
|
"dc=example,dc=com" portion of the tree. The
|
1999-04-24 07:00:44 +08:00
|
|
|
database is to be replicated to two slave slapds, one on
|
2002-06-15 09:00:50 +08:00
|
|
|
truelies, the other on judgmentday. Indices are to be
|
2000-08-10 13:23:38 +08:00
|
|
|
maintained for several attributes, and the {{EX:userPassword}}
|
1999-04-24 07:00:44 +08:00
|
|
|
attribute is to be protected from unauthorized access.
|
|
|
|
|
2002-06-15 05:19:42 +08:00
|
|
|
E: 5. # BDB definition for the example.com
|
|
|
|
E: 6. database bdb
|
2000-10-24 03:00:05 +08:00
|
|
|
E: 7. suffix "dc=example,dc=com"
|
2002-06-15 05:19:42 +08:00
|
|
|
E: 8. directory /usr/local/var/openldap-data
|
2000-10-24 03:00:05 +08:00
|
|
|
E: 9. rootdn "cn=Manager,dc=example,dc=com"
|
2000-08-12 01:07:41 +08:00
|
|
|
E: 10. rootpw secret
|
|
|
|
E: 11. # replication directives
|
|
|
|
E: 12. replogfile /usr/local/var/openldap/slapd.replog
|
2003-09-27 15:14:29 +08:00
|
|
|
E: 13. replica uri=ldap://slave1.example.com:389
|
2000-10-24 03:00:05 +08:00
|
|
|
E: 14. binddn="cn=Replicator,dc=example,dc=com"
|
2000-08-12 01:07:41 +08:00
|
|
|
E: 15. bindmethod=simple credentials=secret
|
2003-09-27 15:14:29 +08:00
|
|
|
E: 16. replica uri=ldaps://slave2.example.com:636
|
2000-10-24 03:00:05 +08:00
|
|
|
E: 17. binddn="cn=Replicator,dc=example,dc=com"
|
2000-08-12 01:07:41 +08:00
|
|
|
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
|
2002-06-15 05:19:42 +08:00
|
|
|
E: 23. # database access control definitions
|
2000-08-12 01:07:41 +08:00
|
|
|
E: 24. access to attr=userPassword
|
|
|
|
E: 25. by self write
|
|
|
|
E: 26. by anonymous auth
|
2002-09-09 14:53:11 +08:00
|
|
|
E: 27. by dn.base="cn=Admin,dc=example,dc=com" write
|
2000-08-12 01:07:41 +08:00
|
|
|
E: 28. by * none
|
|
|
|
E: 29. access to *
|
|
|
|
E: 30. by self write
|
2002-09-09 14:53:11 +08:00
|
|
|
E: 31. by dn.base="cn=Admin,dc=example,dc=com" write
|
2000-09-06 10:46:53 +08:00
|
|
|
E: 32. by * read
|
2000-08-12 01:07:41 +08:00
|
|
|
|
2001-05-18 10:45:46 +08:00
|
|
|
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
|
|
|
|
in which the database files will live.
|
1999-04-24 07:00:44 +08:00
|
|
|
|
2002-06-15 09:00:50 +08:00
|
|
|
Lines 9 and 10 identify the database {{super-user}} entry and associated
|
2001-05-18 10:45:46 +08:00
|
|
|
password. This entry is not subject to access control or size or
|
|
|
|
time limit restrictions.
|
1999-04-24 07:00:44 +08:00
|
|
|
|
2001-09-02 01:49:27 +08:00
|
|
|
Lines 11 through 18 are for replication. Line 12 specifies the
|
2002-06-15 09:00:50 +08:00
|
|
|
replication log file (where changes to the database are logged -
|
2001-09-02 01:49:27 +08:00
|
|
|
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
|
2001-05-18 10:45:46 +08:00
|
|
|
bind as when performing updates, the bind method (simple) and the
|
2001-09-02 01:49:27 +08:00
|
|
|
credentials (password) for the binddn. Lines 16 through 18 specify
|
2001-05-18 10:45:46 +08:00
|
|
|
a second replication site. See the {{SECT:Replication with slurpd}}
|
|
|
|
chapter for more information on these directives.
|
|
|
|
|
2002-06-15 09:00:50 +08:00
|
|
|
Lines 20 through 22 indicate the indices to maintain for various
|
2001-05-18 10:45:46 +08:00
|
|
|
attributes.
|
|
|
|
|
2002-06-15 09:00:50 +08:00
|
|
|
Lines 24 through 32 specify access control for entries in this
|
2001-05-18 10:45:46 +08:00
|
|
|
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
|
|
|
|
by the entry itself and by the "admin" entry. It may be used for
|
|
|
|
authentication/authorization purposes, but is otherwise not readable.
|
|
|
|
All other attributes are writable by the entry and the "admin"
|
2001-06-13 04:57:19 +08:00
|
|
|
entry, but may be read by all users (authenticated or not).
|
2001-05-18 10:45:46 +08:00
|
|
|
|
|
|
|
The next section of the example configuration file defines another
|
2002-06-15 05:19:42 +08:00
|
|
|
BDB database. This one handles queries involving the
|
2001-09-02 01:49:27 +08:00
|
|
|
{{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.
|
1999-04-24 07:00:44 +08:00
|
|
|
|
2002-06-15 05:19:42 +08:00
|
|
|
E: 33. # BDB definition for example.net
|
|
|
|
E: 34. database bdb
|
2000-10-24 03:00:05 +08:00
|
|
|
E: 35. suffix "dc=example,dc=net"
|
2002-06-15 05:19:42 +08:00
|
|
|
E: 36. directory /usr/local/var/openldap-data-net
|
2000-10-24 03:00:05 +08:00
|
|
|
E: 37. rootdn "cn=Manager,dc=example,dc=com"
|
2001-09-02 01:49:27 +08:00
|
|
|
E: 38. index objectClass eq
|
|
|
|
E: 39. access to * by users read
|