1999-10-01 00:57:45 +08:00
|
|
|
# $OpenLDAP$
|
2000-07-23 02:59:40 +08:00
|
|
|
# Copyright 1999-2000, 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
|
|
|
|
|
|
|
Once the software has been built and installed, you are ready to configure it
|
|
|
|
for use at your site. All slapd runtime configuration is accomplished through
|
2000-07-23 15:35:40 +08:00
|
|
|
the {{I:slapd.conf}}(5) file, normally installed in the
|
|
|
|
{{EX:/usr/local/etc/openldap}} directory.
|
1999-04-24 07:00:44 +08:00
|
|
|
|
|
|
|
An alternate configuration file can be specified via a
|
|
|
|
command-line option to slapd or slurpd (see Sections 5 and 8,
|
|
|
|
respectively). This section describes the general format of the config file,
|
2000-08-10 09:38:36 +08:00
|
|
|
followed by a detailed description of each config file directive.
|
1999-04-24 07:00:44 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
H2: Configuration File Format
|
|
|
|
|
2000-08-10 09:38:36 +08:00
|
|
|
The {{slapd.conf}}(5) file consists three types of configuration
|
|
|
|
information: global, backend specific, database specific. Global
|
|
|
|
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
|
|
|
|
be overridden in a backend and/or database directives, backend directives
|
|
|
|
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
|
1999-04-24 07:00:44 +08:00
|
|
|
continuation of the previous line. The general format of slapd.conf is
|
|
|
|
as follows:
|
|
|
|
|
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.
|
|
|
|
A number of files containing schema definition (attribute types
|
|
|
|
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
|
|
|
|
a complete list, see {{slapd.conf}}(5) manual page. This section
|
|
|
|
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-10 09:38:36 +08:00
|
|
|
Directives described in this section apply to all backends,
|
|
|
|
unless specifically overridden in a backend definition.
|
|
|
|
Arguments to directives should be replaced 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
|
|
|
|
more requesters (specified by <who>). See Section 5.3 on
|
|
|
|
access control for more details and examples.
|
|
|
|
|
|
|
|
|
2000-08-10 09:38:36 +08:00
|
|
|
H4: attributetype <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.
|
1999-04-24 07:00:44 +08:00
|
|
|
|
|
|
|
H4: defaultaccess { none | compare | search | read | write }
|
|
|
|
|
2000-08-10 09:38:36 +08:00
|
|
|
This directive specifies the default access to grant requesters
|
1999-04-24 07:00:44 +08:00
|
|
|
not matched by any other access line (see Section 5.3). Note
|
|
|
|
that an access level implies all lesser access levels (e.g.,
|
|
|
|
write access implies read, search and compare).
|
|
|
|
|
|
|
|
\Default:
|
|
|
|
|
|
|
|
E: defaultaccess read
|
|
|
|
|
|
|
|
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
|
|
|
|
follow the normal slapd config file format.
|
|
|
|
|
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
|
1999-04-24 07:00:44 +08:00
|
|
|
and operation statistics should be syslogged (currently
|
2000-08-10 13:23:38 +08:00
|
|
|
logged to the {{syslogd}}(8) LOG_LOCAL4 facility). You must
|
|
|
|
have compiled slapd with -DLDAP_DEBUG for this to work
|
1999-04-24 07:00:44 +08:00
|
|
|
(except for the two stats levels, which are always enabled).
|
|
|
|
Log levels are additive. To display what numbers correspond
|
|
|
|
to what kind of debugging, invoke slapd with the ? flag or
|
|
|
|
consult the table below. The possible values for <integer> are:
|
|
|
|
|
|
|
|
*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
|
|
|
|
|
|
|
|
\Example:
|
|
|
|
|
|
|
|
E: loglevel 255
|
|
|
|
|
|
|
|
This will cause lots and lots of debugging information to be
|
|
|
|
syslogged.
|
|
|
|
|
|
|
|
\Default:
|
|
|
|
|
|
|
|
E: loglevel 256
|
|
|
|
|
2000-08-10 09:38:36 +08:00
|
|
|
H4: objectclass <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.
|
1999-04-24 07:00:44 +08:00
|
|
|
|
|
|
|
H4: referral <url>
|
|
|
|
|
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: schemacheck { on | off }
|
|
|
|
|
2000-08-10 09:38:36 +08:00
|
|
|
This directive turns schema checking on or off. If schema
|
1999-04-30 02:10:40 +08:00
|
|
|
checking is on, entries added or modified through LDAP operations
|
|
|
|
will be checked to ensure they obey the schema rules implied
|
|
|
|
by their object class(es) as defined by the corresponding objectclass
|
2000-08-10 09:38:36 +08:00
|
|
|
directive(s). If schema checking is off this check is not done.
|
1999-04-24 07:00:44 +08:00
|
|
|
|
|
|
|
\Default:
|
|
|
|
|
2000-08-10 13:23:38 +08:00
|
|
|
> schemacheck on
|
1999-04-24 07:00:44 +08:00
|
|
|
|
|
|
|
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: srvtab <filename>
|
|
|
|
|
2000-08-10 09:38:36 +08:00
|
|
|
This directive specifies the srvtab file in which slapd can find the
|
1999-04-24 07:00:44 +08:00
|
|
|
kerberos keys necessary for authenticating clients using
|
2000-08-10 09:38:36 +08:00
|
|
|
kerberos. This directive is only meaningful if you are using
|
1999-04-24 07:00:44 +08:00
|
|
|
kerberos authentication, which must be enabled at compile
|
|
|
|
time by including the appropriate definitions in the
|
2000-08-10 13:23:38 +08:00
|
|
|
{{EX:Make-common}} file.
|
1999-04-24 07:00:44 +08:00
|
|
|
|
|
|
|
\Default:
|
|
|
|
|
2000-08-10 13:23:38 +08:00
|
|
|
> srvtab /etc/srvtab
|
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-08-10 09:38:36 +08:00
|
|
|
H3: General Database Directives
|
1999-04-24 07:00:44 +08:00
|
|
|
|
2000-08-10 09:38:36 +08:00
|
|
|
Directives in this section only apply to the database in which
|
|
|
|
they are defined. They are supported by every type of database.
|
1999-04-24 07:00:44 +08:00
|
|
|
|
|
|
|
H4: database <databasetype>
|
|
|
|
|
2000-08-10 09:38:36 +08:00
|
|
|
This directive marks the beginning of a new database instance
|
1999-04-24 07:00:44 +08:00
|
|
|
definition. <databasetype> should be one of ldbm, shell, or
|
|
|
|
passwd, depending on which backend will serve the
|
|
|
|
database.
|
|
|
|
|
|
|
|
\Example:
|
|
|
|
|
2000-08-10 13:23:38 +08:00
|
|
|
> database ldbm
|
1999-04-24 07:00:44 +08:00
|
|
|
|
|
|
|
This marks the beginning of a new LDBM backend database
|
|
|
|
instance definition.
|
|
|
|
|
|
|
|
H4: lastmod { on | off }
|
|
|
|
|
2000-08-10 09:38:36 +08:00
|
|
|
This directive controls whether slapd will automatically maintain
|
1999-04-24 07:00:44 +08:00
|
|
|
the modifiersName, modifyTimestamp, creatorsName, and
|
|
|
|
createTimestamp attributes for entries.
|
|
|
|
|
|
|
|
\Default:
|
|
|
|
|
2000-08-10 13:23:38 +08:00
|
|
|
> lastmod on
|
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
|
|
|
|
|
2000-08-10 13:23:38 +08:00
|
|
|
> replica host=<hostname>[:<port>]
|
|
|
|
> "binddn=<DN>"
|
|
|
|
> [bindmethod={ simple | kerberos }]
|
|
|
|
> [credentials=<password>]
|
|
|
|
> [srvtab=<filename>]
|
2000-08-10 09:38:36 +08:00
|
|
|
|
|
|
|
This directive specifies a replication site for this database. The
|
2000-08-10 13:23:38 +08:00
|
|
|
{{EX:host=}} parameter specifies 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
|
1999-04-25 06:31:03 +08:00
|
|
|
given, the standard LDAP port number (389) is used.
|
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-10 09:38:36 +08:00
|
|
|
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-10 13:23:38 +08:00
|
|
|
The {{EX:bindmethod}} is either simple or kerberos, depending on
|
1999-04-24 07:00:44 +08:00
|
|
|
whether simple password-based authentication or kerberos
|
|
|
|
authentication is to be used when connecting to the slave
|
|
|
|
slapd. Simple authentication requires a valid password be
|
1999-04-25 06:31:03 +08:00
|
|
|
given. Kerberos authentication requires a valid srvtab file.
|
1999-04-24 07:00:44 +08:00
|
|
|
|
2000-08-10 13:23:38 +08:00
|
|
|
The {{EX:credentials=}} parameter, which is only required if using
|
|
|
|
simple authentication, gives the password for {{EX:binddn}} on the
|
1999-04-24 07:00:44 +08:00
|
|
|
slave slapd.
|
|
|
|
|
2000-08-10 13:23:38 +08:00
|
|
|
The {{EX:srvtab=}} parameter, which is only required if using
|
1999-04-24 07:00:44 +08:00
|
|
|
kerberos, specifies the filename which holds the kerberos key
|
2000-08-10 13:23:38 +08:00
|
|
|
for the slave slapd. If omitted, {{F:/etc/srvtab}} is used.
|
1999-04-24 07:00:44 +08:00
|
|
|
|
|
|
|
See Section 10 for more details on replication.
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
See Section 10 for more details on replication.
|
|
|
|
|
|
|
|
H4: rootdn <dn>
|
|
|
|
|
2000-08-10 09:38:36 +08:00
|
|
|
This directive specifies the DN of an entry that is not subject to
|
1999-04-24 07:00:44 +08:00
|
|
|
access control or administrative limit restrictions for
|
|
|
|
operations on this database.
|
|
|
|
|
|
|
|
\Example:
|
|
|
|
|
2000-08-10 13:23:38 +08:00
|
|
|
> rootdn "cn=Manager, dc=example, dc=com"
|
1999-04-24 07:00:44 +08:00
|
|
|
|
|
|
|
H4: rootkrbname <kerberosname>
|
|
|
|
|
2000-08-10 09:38:36 +08:00
|
|
|
This directive specifies a kerberos name for the DN given above
|
1999-04-24 07:00:44 +08:00
|
|
|
that will always work, regardless of whether an entry with the
|
2000-08-10 13:23:38 +08:00
|
|
|
given DN exists or has a {{EX:krbName}} attribute. This directive is
|
1999-04-24 07:00:44 +08:00
|
|
|
useful when creating a database and also when using slurpd
|
|
|
|
to provide replication service (see Section 10).
|
|
|
|
|
|
|
|
\Example:
|
|
|
|
|
2000-08-10 13:23:38 +08:00
|
|
|
> rootkrbname admin@openldap.org
|
1999-04-24 07:00:44 +08:00
|
|
|
|
|
|
|
H4: rootpw <password>
|
|
|
|
|
2000-08-10 09:38:36 +08:00
|
|
|
This directive specifies a password for the DN given above that
|
1999-04-24 07:00:44 +08:00
|
|
|
will always work, regardless of whether an entry with the given
|
2000-08-10 09:38:36 +08:00
|
|
|
DN exists or has a password. This directive is useful when
|
1999-04-24 07:00:44 +08:00
|
|
|
creating a database and also when using slurpd to provide
|
|
|
|
replication service (see Section 10).
|
|
|
|
|
|
|
|
\Example:
|
|
|
|
|
2000-08-10 13:23:38 +08:00
|
|
|
> rootpw secret
|
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-08-10 13:23:38 +08:00
|
|
|
> suffix "dc=example, dc=com"
|
1999-04-24 07:00:44 +08:00
|
|
|
|
2000-08-10 09:38:36 +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.
|
|
|
|
|
|
|
|
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: updatedn <dn>
|
|
|
|
|
2000-08-10 09:38:36 +08:00
|
|
|
This directive is only applicable in a slave slapd. It specifies the
|
1999-04-24 07:00:44 +08:00
|
|
|
DN allowed to make changes to the replica (typically, this is
|
|
|
|
the DN slurpd binds as when making changes to the replica).
|
|
|
|
|
|
|
|
|
|
|
|
|
2000-08-10 09:38:36 +08:00
|
|
|
H3: LDBM Backend-Specific Directives
|
1999-04-24 07:00:44 +08:00
|
|
|
|
2000-08-10 09:38:36 +08:00
|
|
|
Directives in this category only apply to the LDBM backend
|
1999-04-24 07:00:44 +08:00
|
|
|
database. That is, they must follow a "database ldbm" line and
|
|
|
|
come before any other "database" line.
|
|
|
|
|
|
|
|
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
|
|
|
|
modifies or when building indexes.
|
|
|
|
|
|
|
|
\Default:
|
|
|
|
|
2000-08-10 13:23:38 +08:00
|
|
|
> dbcachesize 100000
|
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
|
1999-04-24 07:00:44 +08:00
|
|
|
containing the database and associated indexes live.
|
|
|
|
|
|
|
|
\Default:
|
|
|
|
|
2000-08-10 13:23:38 +08:00
|
|
|
> directory /usr/local/var/openldap-ldbm
|
1999-04-24 07:00:44 +08:00
|
|
|
|
|
|
|
|
|
|
|
H4: index {<attrlist> | default} [pres,eq,approx,sub,none]
|
|
|
|
|
2000-08-10 09:38:36 +08:00
|
|
|
This directive specifies the indexes to maintain for the given
|
1999-04-24 07:00:44 +08:00
|
|
|
attribute. If only an <attrlist> is given, all possible indexes are
|
|
|
|
maintained.
|
|
|
|
|
|
|
|
\Example:
|
|
|
|
|
2000-08-10 13:23:38 +08:00
|
|
|
> index default pres,eq
|
|
|
|
> index objectclass,uid
|
|
|
|
> index cn,sn eq,sub,approx
|
1999-04-24 07:00:44 +08:00
|
|
|
|
2000-08-10 09:38:36 +08:00
|
|
|
The first line sets the default to indices to maintain to present
|
|
|
|
and equality. The second line causes the default (pres,eq) set
|
|
|
|
of indices to be maintained for objectclass and uid. The third
|
|
|
|
line causes equality, substring, and approximate filters to be
|
|
|
|
maintained for cn and sn attributes.
|
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
|
|
|
|
|
|
|
|
|
|
|
|
2000-08-10 09:38:36 +08:00
|
|
|
H3: Shell Backend-Specific Directives
|
1999-04-24 07:00:44 +08:00
|
|
|
|
2000-08-10 13:23:38 +08:00
|
|
|
> bind <pathname>
|
|
|
|
> unbind <pathname>
|
|
|
|
> search <pathname>
|
|
|
|
> compare <pathname>
|
|
|
|
> modify <pathname>
|
|
|
|
> modrdn <pathname>
|
|
|
|
> add <pathname>
|
|
|
|
> delete <pathname>
|
|
|
|
> abandon <pathname>
|
1999-04-24 07:00:44 +08:00
|
|
|
|
2000-08-10 09:38:36 +08:00
|
|
|
These directives specify the pathname of the command to
|
1999-04-24 07:00:44 +08:00
|
|
|
execute in response to the given LDAP operation. The
|
|
|
|
command given should understand and follow the input/output
|
|
|
|
conventions described in Appendix B.
|
|
|
|
|
|
|
|
\Example:
|
|
|
|
|
2000-08-10 13:23:38 +08:00
|
|
|
> search /usr/local/bin/search.sh
|
1999-04-24 07:00:44 +08:00
|
|
|
|
|
|
|
Note that you need only supply those commands you want the
|
|
|
|
backend to handle. Operations for which a command is not
|
|
|
|
supplied will be refused with an "unwilling to perform" error.
|
|
|
|
|
|
|
|
|
|
|
|
|
2000-08-10 09:38:36 +08:00
|
|
|
H3: Password Backend-Specific Directives
|
1999-04-24 07:00:44 +08:00
|
|
|
|
2000-08-10 09:38:36 +08:00
|
|
|
Directives in this category only apply to the PASSWD backend
|
1999-04-24 07:00:44 +08:00
|
|
|
database. That is, they must follow a "database passwd" line
|
|
|
|
and come before any other "database" line.
|
|
|
|
|
|
|
|
H4: file <filename>
|
|
|
|
|
2000-08-10 09:38:36 +08:00
|
|
|
This directive specifies an alternate passwd file to use.
|
1999-04-24 07:00:44 +08:00
|
|
|
|
|
|
|
\Default:
|
|
|
|
|
2000-08-10 13:23:38 +08:00
|
|
|
> file /etc/passwd
|
1999-04-24 07:00:44 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
2000-08-10 13:23:38 +08:00
|
|
|
H3: TCL Backend-Specific Directives
|
1999-04-25 06:31:03 +08:00
|
|
|
|
|
|
|
H4: scriptpath <pathname>
|
|
|
|
|
2000-08-10 13:23:38 +08:00
|
|
|
This is the full path to a file containing the TCL command(s) to handle
|
1999-04-25 06:31:03 +08:00
|
|
|
the LDAP operations.
|
|
|
|
|
|
|
|
H4: Proc specifiers
|
|
|
|
|
2000-08-10 13:23:38 +08:00
|
|
|
> bind <proc>
|
|
|
|
> unbind <proc>
|
|
|
|
> search <proc>
|
|
|
|
> compare <proc>
|
|
|
|
> modify <proc>
|
|
|
|
> modrdn <proc>
|
|
|
|
> add <proc>
|
|
|
|
> delete <proc>
|
|
|
|
> abandon <proc>
|
1999-04-25 06:31:03 +08:00
|
|
|
|
2000-08-10 13:23:38 +08:00
|
|
|
These directives specify the name of the proc (function) in the
|
|
|
|
TCL script specified in {{EX:scriptpath}} to execute in response to
|
|
|
|
the given LDAP operation.
|
1999-04-25 06:31:03 +08:00
|
|
|
|
|
|
|
\Example:
|
|
|
|
|
2000-08-10 13:23:38 +08:00
|
|
|
> search proc_search
|
1999-04-25 06:31:03 +08:00
|
|
|
|
|
|
|
Note that you need only supply those commands you want the
|
2000-08-10 13:23:38 +08:00
|
|
|
TCL backend to handle. Operations for which a command is not
|
1999-04-25 06:31:03 +08:00
|
|
|
supplied will be refused with an "unwilling to perform" error.
|
|
|
|
|
|
|
|
H4: tclrealm <name>
|
|
|
|
|
2000-08-10 13:23:38 +08:00
|
|
|
This is one of the biggest pluses of using the TCL backend.
|
1999-04-25 06:31:03 +08:00
|
|
|
The realm let's you group several databases to the same interpretor.
|
|
|
|
This basically means they share the same global variables and proc
|
|
|
|
space. So global variables, as well as all the procs are callable
|
2000-08-10 13:23:38 +08:00
|
|
|
between databases. If no {{EX:tclrealm}} is specified, it is put into the
|
1999-04-25 06:31:03 +08:00
|
|
|
"default" realm.
|
|
|
|
|
|
|
|
|
|
|
|
|
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>]+
|
|
|
|
> <what> ::= * | [ dn[.<target style>]=<regex>]
|
|
|
|
> [filter=<ldapfilter>] [attrs=<attrlist>]
|
|
|
|
> <target style> ::= regex | base | one | subtree | children
|
|
|
|
> <attrlist> ::= <attr> | <attr> , <attrlist>
|
|
|
|
> <attr> ::= <attrname> | entry | children
|
|
|
|
> <who> ::= [* | anonymous | users | self |
|
|
|
|
> dn[.<subject style>]=<regex>]
|
|
|
|
> [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>]
|
|
|
|
> <subject style> ::= regex | exact | base | one | subtree | children
|
|
|
|
> <basic style> ::= regex | exact
|
|
|
|
> <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
|
|
|
|
|
|
|
where the <what> part selects the entries and/or attributes to
|
2000-08-10 13:23:38 +08:00
|
|
|
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
|
1999-04-24 07:00:44 +08:00
|
|
|
access to the same set of entries and attributes.
|
|
|
|
|
|
|
|
|
|
|
|
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 can be selected in two ways: by a regular expression
|
|
|
|
matching the entry's distinguished name:
|
|
|
|
|
2000-08-10 13:23:38 +08:00
|
|
|
> dn=<regular expression>
|
1999-04-24 07:00:44 +08:00
|
|
|
|
|
|
|
Note: The DN pattern specified should be "normalized",
|
|
|
|
meaning that there should be no extra spaces, and commas
|
|
|
|
should be used to separate components. An example
|
2000-08-10 09:38:36 +08:00
|
|
|
normalized DN is "cn=Babs Jensen,dc=example,dc=com".
|
1999-04-25 07:11:27 +08:00
|
|
|
An example of a non-normalized DN is
|
2000-08-10 09:38:36 +08:00
|
|
|
"cn=Babs Jensen; dc=example, dc=com".
|
1999-04-24 07:00:44 +08:00
|
|
|
|
|
|
|
Or, entries may be selected by a filter matching some
|
|
|
|
attribute(s) in the entry:
|
|
|
|
|
2000-08-10 13:23:38 +08:00
|
|
|
> filter=<ldap filter>
|
1999-04-24 07:00:44 +08:00
|
|
|
|
|
|
|
where <ldap filter> is a string representation of an LDAP
|
2000-08-10 09:38:36 +08:00
|
|
|
search filter, as described in RFC 2254.
|
|
|
|
|
|
|
|
The special entry selector "*" is used to select any entry,
|
|
|
|
and is a convenient shorthand for the equivalent "dn=.*" selector.
|
1999-04-24 07:00:44 +08:00
|
|
|
|
|
|
|
Attributes within an entry are selected by including a
|
|
|
|
comma-separated list of attribute names in the <what>
|
|
|
|
selector:
|
|
|
|
|
2000-08-10 13:23:38 +08:00
|
|
|
> attrs=<attribute list>
|
1999-04-24 07:00:44 +08:00
|
|
|
|
|
|
|
Access to the entry itself must be granted or denied using the
|
2000-08-10 09:38:36 +08:00
|
|
|
special attribute name "{{EX:entry}}". Note that giving access to an
|
1999-04-24 07:00:44 +08:00
|
|
|
attribute is not enough; access to the entry itself through the
|
2000-08-10 09:38:36 +08:00
|
|
|
{{EX:entry}} attribute is also required. The complete examples at
|
1999-04-24 07:00:44 +08:00
|
|
|
the end of this section should help clear things up.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
H2: Who to grant access to
|
|
|
|
|
|
|
|
The <who> part identifies the entity or entities being granted
|
|
|
|
access. Note that access is granted to "entities" not "entries."
|
|
|
|
Entities can be specified by the special "*" identifier, matching
|
|
|
|
any entry, the keyword "self" matching the entry protected by
|
|
|
|
the access, or by a regular expression matching an entry's
|
|
|
|
distinguished name:
|
|
|
|
|
2000-08-10 13:23:38 +08:00
|
|
|
> dn=<regular expression>
|
1999-04-24 07:00:44 +08:00
|
|
|
|
|
|
|
Note: The DN pattern specified should be "normalized",
|
|
|
|
meaning that there should be no extra spaces, and commas
|
|
|
|
should be used to separate components.
|
|
|
|
|
|
|
|
Or entities can be specified by a regular expression matching
|
|
|
|
the client's IP address or domain name:
|
|
|
|
|
2000-08-10 13:23:38 +08:00
|
|
|
> addr=<regular expression>
|
|
|
|
> domain=<regular expression>
|
1999-04-24 07:00:44 +08:00
|
|
|
|
|
|
|
or by an entry listed in a DN-valued attribute in the entry to
|
|
|
|
which the access applies:
|
|
|
|
|
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).
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
H3: The access to grant
|
|
|
|
|
|
|
|
|
|
|
|
The kind of <access> granted can be one of the following:
|
|
|
|
|
2000-08-10 13:23:38 +08:00
|
|
|
> none | auth | compare | search | read | write
|
1999-04-24 07:00:44 +08:00
|
|
|
|
|
|
|
Note that each level implies all lower levels of access. So, for
|
|
|
|
example, granting someone write access to an entry also
|
2000-08-10 13:23:38 +08:00
|
|
|
grants them read, search, compare, and auth access.
|
1999-04-24 07:00:44 +08:00
|
|
|
|
|
|
|
|
|
|
|
H3: Access Control Evaluation
|
|
|
|
|
|
|
|
When evaluating whether some requester should be given
|
|
|
|
access to an entry and/or attribute, slapd compares the entry
|
2000-08-10 13:23:38 +08:00
|
|
|
and/or attribute to the {{EX:<what>}} selectors given in the
|
1999-04-24 07:00:44 +08:00
|
|
|
configuration file. Access directives local to the current
|
|
|
|
database are examined first, followed by global access
|
|
|
|
directives. Within this priority, access directives are
|
|
|
|
examined in the order in which they appear in the config file.
|
2000-08-10 13:23:38 +08:00
|
|
|
Slapd stops with the first {{EX:<what>}} selector that matches the
|
1999-04-24 07:00:44 +08:00
|
|
|
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
|
2000-08-10 13:23:38 +08:00
|
|
|
{{EX:<who>}} selectors within the access directive selected above,
|
|
|
|
in the order in which they appear. It stops with the first {{EX:<who>}}
|
1999-04-24 07:00:44 +08:00
|
|
|
selector that matches the requester. This determines the
|
|
|
|
access the entity requesting access has to the entry and/or
|
|
|
|
attribute.
|
|
|
|
|
|
|
|
Finally, slapd compares the access granted in the selected
|
2000-08-10 13:23:38 +08:00
|
|
|
{{EX:<access>}} clause to the access requested by the client. If it
|
1999-04-24 07:00:44 +08:00
|
|
|
allows greater or equal access, access is granted. Otherwise,
|
|
|
|
access is denied.
|
|
|
|
|
|
|
|
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
|
2000-08-10 13:23:38 +08:00
|
|
|
one {{EX:<who>}} selector is more specific than another it should
|
1999-04-24 07:00:44 +08:00
|
|
|
come first in the access directive. The access control
|
|
|
|
examples given below should help make this clear.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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
|
|
|
|
|
|
|
|
This directive allows users to modify their own entries,
|
|
|
|
allows authenticate, and allows authenticated users to read.
|
|
|
|
Note that only the first {{EX:by <who>}} clause which matches applies.
|
|
|
|
Hence, the anonymous users are granted {{EX:auth}}, not {{EX:read}}.
|
1999-04-24 07:00:44 +08:00
|
|
|
|
|
|
|
The following example shows the use of a regular expression
|
|
|
|
to select the entries by DN in two access directives where
|
|
|
|
ordering is significant.
|
|
|
|
|
2000-08-10 13:23:38 +08:00
|
|
|
> access to dn=".*,dc=example,dc=com"
|
|
|
|
> by * search
|
|
|
|
> access to dn=".*,dc=com"
|
|
|
|
> by * read
|
1999-04-24 07:00:44 +08:00
|
|
|
|
2000-08-10 09:38:36 +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. If the
|
1999-04-24 07:00:44 +08:00
|
|
|
order of these access directives was reversed, the
|
2000-08-10 09:38:36 +08:00
|
|
|
trailing directive would never be reached, since all
|
|
|
|
{{EX:dc=example,dc=com}} entries are also {{EX:dc=com}} entries.
|
1999-04-24 07:00:44 +08:00
|
|
|
|
2000-08-10 13:23:38 +08:00
|
|
|
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 a implicit {{EX:by * none}}
|
|
|
|
clause and access list itself ends with {{EX:access to * by * none}}
|
|
|
|
directive. Only if no access controls are specified, is the
|
|
|
|
defaultaccess granted.
|
|
|
|
|
1999-04-24 07:00:44 +08:00
|
|
|
The next example again shows the importance of ordering,
|
2000-08-10 13:23:38 +08:00
|
|
|
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 <who> selectors.
|
|
|
|
|
|
|
|
> access to dn="(.*,)?dc=example,dc=com" attr=homePhone
|
|
|
|
> by self write
|
|
|
|
> by dn="(.*,)?dc=example,dc=com" search
|
|
|
|
> by domain=.*\.example\.com read
|
|
|
|
> access to dn="(.*,)?dc=example,dc=com"
|
|
|
|
> by self write
|
|
|
|
> by dn=".*,dc=example,dc=com" search
|
|
|
|
> by anonymous auth
|
1999-04-24 07:00:44 +08:00
|
|
|
|
2000-08-10 09:38:36 +08:00
|
|
|
This example applies to entries in the "dc=example, dc=com"
|
1999-04-24 07:00:44 +08:00
|
|
|
subtree. To all attributes except homePhone, the entry itself
|
2000-08-10 09:38:36 +08:00
|
|
|
can write them, other Example.com entries can search by them,
|
2000-08-10 13:23:38 +08:00
|
|
|
anybody else has no access ((implicit {{EX:by * none}}) excepting for
|
|
|
|
authentication/authorization (which is always done anonymously).
|
|
|
|
The homePhone attribute is writable by the entry, searchable
|
|
|
|
by other Example.com entries, readable by clients connecting
|
|
|
|
from somewhere in the example.com domain, 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
|
|
|
|
create a group and allow people too add and remove only
|
|
|
|
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
|
1999-04-24 07:00:44 +08:00
|
|
|
entries listed in the member attribute. The selfwrite access
|
|
|
|
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-10 13:23:38 +08:00
|
|
|
Note that the attr=member construct in the {{EX:<what>}} clause is a
|
|
|
|
shorthand for the clause "{{EX:dn=.* attr=member}}" (i.e., it matches
|
1999-04-24 07:00:44 +08:00
|
|
|
the member attribute in all entries).
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
H2: Schema Enforcement
|
|
|
|
|
|
|
|
|
|
|
|
|
2000-08-10 13:23:38 +08:00
|
|
|
The {{EX:objectclass}} and schemacheck configuration file directives
|
1999-04-24 07:00:44 +08:00
|
|
|
can be used to enforce schema rules on entries in the
|
|
|
|
directory. The schema rules are defined by one or more
|
|
|
|
objectclass lines, and enforcement is turned on or off via the
|
2000-08-10 13:23:38 +08:00
|
|
|
schemacheck directives. The format of an {{EX:objectclass}} line is:
|
1999-04-24 07:00:44 +08:00
|
|
|
|
2000-08-10 13:23:38 +08:00
|
|
|
> objectclass <RFC2252 Object Class Description>
|
1999-04-24 07:00:44 +08:00
|
|
|
|
2000-08-10 09:38:36 +08:00
|
|
|
This directive defines the schema rules for the object class
|
2000-08-10 13:23:38 +08:00
|
|
|
given by {{EX:<name>}}. Schema rules consist of the attributes the
|
|
|
|
entry is required to have (given by the requires {{EX:<attrs>}}
|
1999-04-24 07:00:44 +08:00
|
|
|
clause) and those attributes that it may optionally have (given
|
2000-08-10 13:23:38 +08:00
|
|
|
by the allows {{EX:<attrs>}} clause). In both clauses, {{EX:<attrs>}} is a
|
1999-04-24 07:00:44 +08:00
|
|
|
comma-separated list of attribute names.
|
|
|
|
|
|
|
|
Note that object class inheritance (that is, defining one object
|
|
|
|
class in terms of another) is not supported directly. All of an
|
|
|
|
object class's required and allowed attributes must be listed
|
|
|
|
in the objectclass definition.
|
|
|
|
|
|
|
|
For example, to define an objectclass called myPerson, you
|
|
|
|
might include a definition like this:
|
|
|
|
|
2000-08-10 13:23:38 +08:00
|
|
|
> objectclass myperson
|
|
|
|
> requires cn, sn, objectclass
|
|
|
|
> allows mail, phone, fax
|
1999-04-24 07:00:44 +08:00
|
|
|
|
|
|
|
To then enforce this rule (i.e., to make sure an entry with an
|
|
|
|
objectclass of myperson contains the cn, sn and objectclass
|
|
|
|
attributes, and that it contains no other attributes besides
|
|
|
|
mail, phone, and fax), turn on schema checking with a line like
|
|
|
|
this:
|
|
|
|
|
2000-08-10 13:23:38 +08:00
|
|
|
> schemacheck on
|
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
|
|
|
|
different parts of the X.500 tree; both are LDBM database
|
|
|
|
instances. The line numbers shown are provided for
|
|
|
|
reference only and are not included in the actual file. First, the
|
|
|
|
global configuration section:
|
|
|
|
|
|
|
|
E: 1. # example config file - global configuration section
|
2000-08-10 09:38:36 +08:00
|
|
|
E: 2. include /usr/local/etc/schema/core.schema
|
|
|
|
E: 3. referral ldap://root.openldap.org
|
|
|
|
|
|
|
|
Line 1 is a comment. Lines 2 include another config file
|
|
|
|
which containing {{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
|
|
|
|
|
|
|
The next section of the configuration file defines an LDBM
|
|
|
|
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
|
|
|
|
truelies, the other on judgmentday. Indexes 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.
|
|
|
|
|
|
|
|
E: 1. # ldbm definition for the U-M database
|
|
|
|
E: 2. database ldbm
|
2000-08-10 09:38:36 +08:00
|
|
|
E: 3. suffix "dc=example, dc=com"
|
1999-04-25 07:11:27 +08:00
|
|
|
E: 4. directory /usr/local/var/openldap
|
2000-08-10 09:38:36 +08:00
|
|
|
E: 6. rootdn "cn=Manager, dc=example, dc=com"
|
1999-04-24 07:00:44 +08:00
|
|
|
E: 7. rootpw secret
|
1999-04-25 07:11:27 +08:00
|
|
|
E: 8. replogfile /usr/local/var/openldap/slapd.replog
|
2000-08-10 09:38:36 +08:00
|
|
|
E: 9. replica host=slave1.example.com:389
|
|
|
|
E: 10. binddn="cn=Replicator, dc=example, dc=com"
|
1999-04-24 07:00:44 +08:00
|
|
|
E: 11. bindmethod=simple credentials=secret
|
2000-08-10 09:38:36 +08:00
|
|
|
E: 12.replica host=slave2.example.com
|
|
|
|
E: 13. binddn="cn=Replicator, dc=example, dc=com"
|
1999-04-24 07:00:44 +08:00
|
|
|
E: 14. bindmethod=kerberos
|
1999-04-25 07:11:27 +08:00
|
|
|
E: 15. srvtab=/etc/srvtab.slave2
|
1999-04-24 07:00:44 +08:00
|
|
|
E: 16.# ldbm indexed attribute definitions
|
|
|
|
E: 17.index cn,sn,uid pres,eq,approx,sub
|
|
|
|
E: 18.index objectclass pres,eq
|
|
|
|
E: 19.index default none
|
|
|
|
E: 20.# ldbm access control definitions
|
2000-08-10 09:38:36 +08:00
|
|
|
E: 21.access to attr=userPassword
|
1999-04-24 07:00:44 +08:00
|
|
|
E: 23. by self write
|
2000-08-10 09:38:36 +08:00
|
|
|
E: 22. by anonymous auth
|
|
|
|
E: 23. by dn="cn=Admin,dc=example,dc=com" write
|
|
|
|
E: 25. by * none
|
|
|
|
E: 26.access to *
|
|
|
|
E: 27. by self write
|
|
|
|
E: 28. by anonymous auth
|
|
|
|
E: 29. by dn="cn=Admin,dc=example,dc=com" write
|
|
|
|
E: 30. by * read
|
1999-04-24 07:00:44 +08:00
|
|
|
|
|
|
|
Line 1 is a comment. The start of the database definition is
|
|
|
|
marked by the database keyword on line 2. Line 3 specifies
|
|
|
|
the DN suffix for queries to pass to this database. Line 4
|
|
|
|
specifies the directory in which the database files will live
|
|
|
|
|
|
|
|
Lines 6 and 7 identify the database "super user" entry and
|
|
|
|
associated password. This entry is not subject to access
|
|
|
|
control or size or time limit restrictions.
|
|
|
|
|
|
|
|
Lines 8 through 15 are for replication. Line 8 specifies the
|
|
|
|
replication log file (where changes to the database are logged
|
|
|
|
\- this file is written by slapd and read by slurpd). Lines 9
|
|
|
|
through 11 specify the hostname and port for a replicated
|
|
|
|
host, the DN to bind as when performing updates, the bind
|
|
|
|
method (simple) and the credentials (password) for the
|
|
|
|
binddn. Lines 12 through 15 specify a second replication site,
|
|
|
|
using kerberos instead of simple authentication. See Section
|
2000-08-10 09:38:36 +08:00
|
|
|
10 on slurpd for more information on these directives.
|
1999-04-24 07:00:44 +08:00
|
|
|
|
|
|
|
Lines 16 through 19 indicate the indexes to maintain for
|
|
|
|
various attributes. The default is not to maintain any indexes
|
|
|
|
(line 19).
|
|
|
|
|
2000-08-10 09:38:36 +08:00
|
|
|
Lines 20 through 30 specify access control for entries in the
|
2000-08-10 13:23:38 +08:00
|
|
|
database. For all entries, the {{EX:userPassword}} attribute is
|
2000-08-10 09:38:36 +08:00
|
|
|
writable by the entry and the "admin" entry, may be used for
|
|
|
|
authentication/authorization purposes, but is otherwise not
|
|
|
|
readable. All other attributes by writable by the entry and
|
|
|
|
the "admin" entry, may be used for authentication/authorization
|
|
|
|
purposes, but may be read by authenticated users.
|
1999-04-24 07:00:44 +08:00
|
|
|
|
|
|
|
The next section of the example configuration file defines
|
|
|
|
another LDBM database. This one handles queries involving
|
2000-08-10 09:38:36 +08:00
|
|
|
the {{EX:dc=example,dc=net}} subtree.
|
1999-04-24 07:00:44 +08:00
|
|
|
|
|
|
|
E: 1. # ldbm definition for Babs, Inc. database
|
|
|
|
E: 2. database ldbm
|
2000-08-10 09:38:36 +08:00
|
|
|
E: 3. suffix "dc=example, dc=net"
|
|
|
|
E: 4. directory /usr/local/var/ldbm-example-net
|
|
|
|
E: 5. rootdn "cn=Manager, dc=example, dc=net"
|
1999-04-24 07:00:44 +08:00
|
|
|
|