mirror of
https://git.openldap.org/openldap/openldap.git
synced 2024-12-21 03:10:25 +08:00
b7b1f8e3ba
between documents. Add -2topics navigation.
911 lines
28 KiB
Plaintext
911 lines
28 KiB
Plaintext
# Copyright 1999, The OpenLDAP Foundation, All Rights Reserved.
|
|
# COPYING RESTRICTIONS APPLY, see COPYRIGHT.
|
|
H1: The {{I: slapd}} Configuration File
|
|
|
|
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
|
|
the {{EX: slapd.conf}} file, installed in the {{EX: ETCDIR}}
|
|
directory you specified in the {{EX: Make-common}} file.
|
|
|
|
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,
|
|
followed by a detailed description of each config file option.
|
|
|
|
|
|
|
|
H2: Configuration File Format
|
|
|
|
The {{EX: slapd.conf}} file consists of a series of global configuration options
|
|
that apply to slapd as a whole (including all backends), followed by
|
|
zero or more database backend definitions that contain information
|
|
specific to a backend instance.
|
|
|
|
Global options can be overridden in a backend (for options that
|
|
appear more than once, the last appearance in the slapd.conf file is
|
|
used). Blank lines and comment lines beginning with a `#' character
|
|
are ignored. If a line begins with white space, it is considered a
|
|
continuation of the previous line. The general format of slapd.conf is
|
|
as follows:
|
|
|
|
E: # comment - these options apply to every database
|
|
E: <global config options>
|
|
E: # first database definition & config options
|
|
E: database <backend 1 type>
|
|
E: <config options specific to backend 1>
|
|
E: # second database definition & config options
|
|
E: database <backend 2 type>
|
|
E: <config options specific to backend 2>
|
|
E: # subsequent database definitions & config options
|
|
E: ...
|
|
|
|
Configuration line arguments are separated by white space. If
|
|
an argument contains white space, the argument should be
|
|
enclosed in double quotes "like this". If an argument contains
|
|
a double quote or a backslash character `\', the character
|
|
should be preceded by a backslash character `\'.
|
|
|
|
The distribution contains an example configuration file that will
|
|
be installed in the {{EX: ETCDIR}} directory. Also provided are
|
|
{{EX: slapd.at.conf}}, which contains many commonly used attribute
|
|
definitions, and {{EX: slapd.oc.conf}}, which contains many commonly
|
|
used object class definitions. These files can be included from
|
|
the slapd configuration file (see below).
|
|
|
|
|
|
|
|
H2: Configuration File Options
|
|
|
|
This section separates the configuration file options into
|
|
global and backend-specific categories, describing each
|
|
option and its default value (if any), and giving an example of
|
|
its use.
|
|
|
|
|
|
|
|
H3: Global Options
|
|
|
|
Options described in this section apply to all backends,
|
|
unless specifically overridden in a backend definition. Option
|
|
arguments that should be replaced by actual text are shown
|
|
in brackets <>.
|
|
|
|
|
|
H4: access to <what> [ by <who> <accesslevel> ]+
|
|
|
|
This option grants access (specified by <accesslevel>) to a
|
|
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.
|
|
|
|
|
|
H4: attribute <name> [<name2>] { bin | ces | cis | tel | dn }
|
|
|
|
This option associates a syntax with an attribute name. By
|
|
default, an attribute is assumed to have syntax cis. An
|
|
optional alternate name can be given for an attribute. The
|
|
possible syntaxes and their meanings are
|
|
|
|
* {{EX: bin}} binary
|
|
* {{EX: ces}} case exact string (case must match during comparisons)
|
|
* {{EX: cis}} case ignore string (case is ignored during comparisons)
|
|
* {{EX: tel}} telephone number string (like cis but blanks and dashes ` '
|
|
are ignored during comparisons)
|
|
* {{EX: dn}} distinguished name
|
|
|
|
|
|
H4: defaultaccess { none | compare | search | read | write }
|
|
|
|
This option specifies the default access to grant requesters
|
|
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>
|
|
|
|
This option specifies that slapd should read additional
|
|
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.
|
|
|
|
Note: You should be careful when using this option - there is
|
|
no small limit on the number of nested include options, and no
|
|
loop detection is done.
|
|
|
|
H4: loglevel <integer>
|
|
|
|
This option specifies the level at which debugging statements
|
|
and operation statistics should be syslogged (currently
|
|
logged to the syslogd(8) LOG_LOCAL4 facility). You must
|
|
have compiled slapd with DLDAP_DEBUG for this to work
|
|
(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
|
|
|
|
H4: objectclass <name> [ requires <attrs> ] [ allows <attrs> ]
|
|
|
|
This option defines the schema rules for the given object
|
|
class. Used in conjunction with the schemacheck option. See
|
|
Section 5.4 for more details.
|
|
|
|
H4: referral <url>
|
|
|
|
This option specifies the referral to pass back when slapd
|
|
cannot find a local database to handle a request.
|
|
|
|
\Example:
|
|
|
|
E: referral ldap://ldap.openldap.org
|
|
|
|
This will refer non-local queries to the LDAP server at the
|
|
OpenLDAP Project. Smart LDAP clients can re-ask their
|
|
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 }
|
|
|
|
This option turns schema checking on or off. If schema
|
|
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
|
|
option(s). If schema checking is off this check is not done.
|
|
|
|
\Default:
|
|
|
|
E: schemacheck on
|
|
|
|
H4: sizelimit <integer>
|
|
|
|
This option specifies the maximum number of entries to return
|
|
from a search operation.
|
|
|
|
\Default:
|
|
|
|
E: sizelimit 500
|
|
|
|
|
|
H4: srvtab <filename>
|
|
|
|
This option specifies the srvtab file in which slapd can find the
|
|
kerberos keys necessary for authenticating clients using
|
|
kerberos. This option is only meaningful if you are using
|
|
kerberos authentication, which must be enabled at compile
|
|
time by including the appropriate definitions in the
|
|
{{EX: Make-common}} file.
|
|
|
|
\Default:
|
|
|
|
E: srvtab /etc/srvtab
|
|
|
|
H4: timelimit <integer>
|
|
|
|
This option specifies the maximum number of seconds (in real
|
|
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:
|
|
|
|
E: timelimit 3600
|
|
|
|
|
|
|
|
H3: General Backend Options
|
|
|
|
Options in this section only apply to the backend in which
|
|
they are defined. They are supported by every type of
|
|
backend.
|
|
|
|
H4: database <databasetype>
|
|
|
|
This option marks the beginning of a new database instance
|
|
definition. <databasetype> should be one of ldbm, shell, or
|
|
passwd, depending on which backend will serve the
|
|
database.
|
|
|
|
\Example:
|
|
|
|
E: database ldbm
|
|
|
|
This marks the beginning of a new LDBM backend database
|
|
instance definition.
|
|
|
|
H4: lastmod { on | off }
|
|
|
|
This option controls whether slapd will automatically maintain
|
|
the modifiersName, modifyTimestamp, creatorsName, and
|
|
createTimestamp attributes for entries.
|
|
|
|
\Default:
|
|
|
|
E: lastmod off
|
|
|
|
H4: readonly { on | off }
|
|
|
|
This option puts the database into "read-only" mode. Any
|
|
attempts to modify the database will return an "unwilling to
|
|
perform" error.
|
|
|
|
\Default:
|
|
|
|
E: readonly off
|
|
|
|
H4: replica
|
|
E: replica host=<hostname>[:<port>]
|
|
E: "binddn=<DN>"
|
|
E: bindmethod={ simple | kerberos }
|
|
E: \[credentials=<password>]
|
|
E: \[srvtab=<filename>]
|
|
|
|
This option specifies a replication site for this database. The
|
|
{{EX: host=}} parameter specifies a host and optionally a port where
|
|
the slave slapd instance can be found. Either a domain name
|
|
or IP address may be used for <hostname>. If <port> is not
|
|
given, the standard LDAP port number (389) is used.
|
|
|
|
The {{EX: binddn=}} parameter gives the DN to bind as for updates to
|
|
the slave slapd. It should be a DN which has read/write
|
|
access to the slave slapd's database, typically given as a
|
|
"rootdn" in the slave's config file. It must also match the
|
|
updatedn option in the slave slapd's config file. Since DNs are
|
|
likely to contain embedded spaces, the entire "{{EX: binddn=<DN>}}"
|
|
string should be enclosed in quotes.
|
|
|
|
{{EX: bindmethod}} is either simple or kerberos, depending on
|
|
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
|
|
given. Kerberos authentication requires a valid srvtab file.
|
|
|
|
The {{EX: credentials=}} parameter, which is only required if using
|
|
simple authentication, gives the password for binddn on the
|
|
slave slapd.
|
|
|
|
The {{EX: srvtab=}} parameter, which is only required if using
|
|
kerberos, specifies the filename which holds the kerberos key
|
|
for the slave slapd. If omitted, {{EX: /etc/srvtab}} is used.
|
|
|
|
See Section 10 for more details on replication.
|
|
|
|
H4: replogfile <filename>
|
|
|
|
This option specifies the name of the replication log file to
|
|
which slapd will log changes. The replication log is typically
|
|
written by slapd and read by slurpd. Normally, this option is
|
|
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>
|
|
|
|
This option specifies the DN of an entry that is not subject to
|
|
access control or administrative limit restrictions for
|
|
operations on this database.
|
|
|
|
\Example:
|
|
|
|
E: rootdn "cn=Manager, o=OpenLDAP Project, c=US"
|
|
|
|
H4: rootkrbname <kerberosname>
|
|
|
|
This option specifies a kerberos name for the DN given above
|
|
that will always work, regardless of whether an entry with the
|
|
given DN exists or has a {{EX: krbName}} attribute. This option is
|
|
useful when creating a database and also when using slurpd
|
|
to provide replication service (see Section 10).
|
|
|
|
\Example:
|
|
|
|
E: rootkrbname admin@openldap.org
|
|
|
|
H4: rootpw <password>
|
|
|
|
This option specifies a password for the DN given above that
|
|
will always work, regardless of whether an entry with the given
|
|
DN exists or has a password. This option is useful when
|
|
creating a database and also when using slurpd to provide
|
|
replication service (see Section 10).
|
|
|
|
\Example:
|
|
|
|
E: rootpw secret
|
|
|
|
H4: suffix <dn suffix>
|
|
|
|
This option specifies the DN suffix of queries that will be
|
|
passed to this backend database. Multiple suffix lines can be
|
|
given, and at least one is required for each database
|
|
definition.
|
|
|
|
\Example:
|
|
|
|
E: suffix "o=OpenLDAP Project, c=US"
|
|
|
|
Queries with a DN ending in "o=OpenLDAP Project, c=US"
|
|
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>
|
|
|
|
This option is only applicable in a slave slapd. It specifies the
|
|
DN allowed to make changes to the replica (typically, this is
|
|
the DN slurpd binds as when making changes to the replica).
|
|
|
|
|
|
|
|
H3: LDBM Backend-Specific Options
|
|
|
|
Options in this category only apply to the LDBM backend
|
|
database. That is, they must follow a "database ldbm" line and
|
|
come before any other "database" line.
|
|
|
|
H4: cachesize <integer>
|
|
|
|
This option specifies the size in entries of the in-memory
|
|
cache maintained by the LDBM backend database instance.
|
|
|
|
\Default:
|
|
|
|
E: cachesize 1000
|
|
|
|
|
|
H4: dbcachesize <integer>
|
|
|
|
This option specifies the size in bytes of the in-memory cache
|
|
associated with each open index file. If not supported by the
|
|
underlying database method, this option is ignored without
|
|
comment. Increasing this number uses more memory but can
|
|
cause a dramatic performance increase, especially during
|
|
modifies or when building indexes.
|
|
|
|
\Default:
|
|
|
|
E: dbcachesize 100000
|
|
|
|
|
|
H4: directory <directory>
|
|
|
|
This option specifies the directory where the LDBM files
|
|
containing the database and associated indexes live.
|
|
|
|
\Default:
|
|
|
|
E: directory /usr/tmp
|
|
|
|
|
|
H4: index {<attrlist> | default} [pres,eq,approx,sub,none]
|
|
|
|
This option specifies the indexes to maintain for the given
|
|
attribute. If only an <attrlist> is given, all possible indexes are
|
|
maintained.
|
|
|
|
\Example:
|
|
|
|
E: index cn
|
|
|
|
E: index sn,uid eq,sub,approx
|
|
|
|
E: index default none
|
|
|
|
This example causes all indexes to be maintained for the cn
|
|
attribute; equality, substring, and approximate indexes for the
|
|
sn and uid attributes; and no indexes for all other attributes.
|
|
|
|
|
|
H4: mode <integer>
|
|
|
|
This option specifies the file protection mode that newly
|
|
created database index files should have.
|
|
|
|
\Default:
|
|
|
|
E: mode 0600
|
|
|
|
|
|
|
|
H3: Shell Backend-Specific Options
|
|
|
|
E: bind <pathname>
|
|
|
|
E: unbind <pathname>
|
|
|
|
E: search <pathname>
|
|
|
|
E: compare <pathname>
|
|
|
|
E: modify <pathname>
|
|
|
|
E: modrdn <pathname>
|
|
|
|
E: add <pathname>
|
|
|
|
E: delete <pathname>
|
|
|
|
E: abandon <pathname>
|
|
|
|
These options specify the pathname of the command to
|
|
execute in response to the given LDAP operation. The
|
|
command given should understand and follow the input/output
|
|
conventions described in Appendix B.
|
|
|
|
\Example:
|
|
|
|
E: search /usr/local/bin/search.sh
|
|
|
|
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.
|
|
|
|
|
|
|
|
H3: Password Backend-Specific Options
|
|
|
|
Options in this category only apply to the PASSWD backend
|
|
database. That is, they must follow a "database passwd" line
|
|
and come before any other "database" line.
|
|
|
|
H4: file <filename>
|
|
|
|
This option specifies an alternate passwd file to use.
|
|
|
|
\Default:
|
|
|
|
E: file /etc/passwd
|
|
|
|
|
|
|
|
H3: Tcl Backend-Specific Options
|
|
|
|
H4: scriptpath <pathname>
|
|
|
|
This is the full path to a file containing the tcl command(s) to handle
|
|
the LDAP operations.
|
|
|
|
H4: Proc specifiers
|
|
|
|
E: bind <proc>
|
|
|
|
E: unbind <proc>
|
|
|
|
E: search <proc>
|
|
|
|
E: compare <proc>
|
|
|
|
E: modify <proc>
|
|
|
|
E: modrdn <proc>
|
|
|
|
E: add <proc>
|
|
|
|
E: delete <proc>
|
|
|
|
E: abandon <proc>
|
|
|
|
These options specify the name of the proc (function) in the tcl script
|
|
specified in 'scriptpath' to execute in response to the given LDAP
|
|
operation.
|
|
|
|
\Example:
|
|
|
|
E: search proc_search
|
|
|
|
Note that you need only supply those commands you want the
|
|
tcl backend to handle. Operations for which a command is not
|
|
supplied will be refused with an "unwilling to perform" error.
|
|
|
|
H4: tclrealm <name>
|
|
|
|
This is one of the biggest pluses of using the tcl backend.
|
|
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
|
|
between databases. If no tclrealm is specified, it is put into the
|
|
"default" realm.
|
|
|
|
|
|
|
|
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:
|
|
|
|
E: <access directive> ::= access to <what>
|
|
E: [ by <who> <access> ]+
|
|
E: <what> ::= * | [ dn=<regex> ] [ filter=<ldapfilter> ]
|
|
E: [ attrs=<attrlist> ]
|
|
E: <who> ::= * | self | dn=<regex> | addr=<regex> |
|
|
E: domain=<regex> | dnattr=<dn attribute>
|
|
E: <access> ::= [self]none | [self]compare | [self]search
|
|
E: | [self]read | [self]write
|
|
|
|
where the <what> part selects the entries and/or attributes to
|
|
which the access applies, the <who> part specifies which
|
|
entities are granted access, and the <access> part specifies
|
|
the access granted. Multiple <who> <access> pairs are
|
|
supported, allowing many entities to be granted different
|
|
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:
|
|
|
|
E: dn=<regular expression>
|
|
|
|
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
|
|
normalized DN is "cn=Babs Jensen,o=OpenLDAP Project,c=US".
|
|
An example of a non-normalized DN is
|
|
"cn=Babs Jensen; o=OpenLDAP Project, c=US".
|
|
|
|
Or, entries may be selected by a filter matching some
|
|
attribute(s) in the entry:
|
|
|
|
E: filter=<ldap filter>
|
|
|
|
where <ldap filter> is a string representation of an LDAP
|
|
search filter, as described in RFC 1588. The special entry
|
|
selector "*" is used to select any entry, and is a convenient
|
|
shorthand for the equivalent "dn=.*" selector.
|
|
|
|
Attributes within an entry are selected by including a
|
|
comma-separated list of attribute names in the <what>
|
|
selector:
|
|
|
|
E: attrs=<attribute list>
|
|
|
|
Access to the entry itself must be granted or denied using the
|
|
special attribute name "entry". Note that giving access to an
|
|
attribute is not enough; access to the entry itself through the
|
|
"entry" attribute is also required. The complete examples at
|
|
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:
|
|
|
|
E: dn=<regular expression>
|
|
|
|
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:
|
|
|
|
E: addr=<regular expression>
|
|
E: domain=<regular expression>
|
|
|
|
or by an entry listed in a DN-valued attribute in the entry to
|
|
which the access applies:
|
|
|
|
E: dnattr=<dn-valued attribute name>
|
|
|
|
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:
|
|
|
|
E: none | compare | search | read | write
|
|
|
|
Note that each level implies all lower levels of access. So, for
|
|
example, granting someone write access to an entry also
|
|
grants them read, search, and compare access.
|
|
|
|
|
|
|
|
H3: Access Control Evaluation
|
|
|
|
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. 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.
|
|
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.
|
|
|
|
Finally, slapd compares the access granted in the selected
|
|
{{EX: <access>}} clause to the access requested by the client. If it
|
|
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
|
|
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.
|
|
|
|
|
|
|
|
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:
|
|
|
|
E: access to * by * read
|
|
|
|
This access directive grants read access to everyone. If it
|
|
appears alone it is the same as the following defaultaccess
|
|
line.
|
|
|
|
E: defaultaccess read
|
|
|
|
The following example shows the use of a regular expression
|
|
to select the entries by DN in two access directives where
|
|
ordering is significant.
|
|
|
|
E: access to dn=".*, o=OpenLDAP Project, c=US"
|
|
E: by * search
|
|
E: access to dn=".*, c=US"
|
|
E: by * read
|
|
|
|
Read access is granted to entries under the c=US subtree,
|
|
except for those entries under the "o=OpenLDAP Project,
|
|
c=US" subtree, to which search access is granted. If the
|
|
order of these access directives was reversed, the
|
|
OpenLDAP-specific directive would never be matched, since all
|
|
OpenLDAP entries are also c=US entries.
|
|
|
|
The next example again shows the importance of ordering,
|
|
both of the access directives and the "by" clauses. It also
|
|
shows the use of an attribute selector to grant access to a
|
|
specific attribute and various <who> selectors.
|
|
|
|
E:access to dn=".*, o=OpenLDAP Project, c=US" attr=homePhone
|
|
E: by self write
|
|
E: by dn=".*, o=OpenLDAP Project, c=US" search
|
|
E: by domain=.*\.openldap\.org read
|
|
E: by * compare
|
|
E:access to dn=".*, o=OpenLDAP Project, c=US"
|
|
E: by self write
|
|
E: by dn=".*, o=OpenLDAP Project, c=US" search
|
|
E: by * none
|
|
|
|
This example applies to entries in the "o=OpenLDAP Project, c=US"
|
|
subtree. To all attributes except homePhone, the entry itself
|
|
can write them, other OpenLDAP entries can search by them,
|
|
anybody else has no access. The homePhone attribute is
|
|
writable by the entry, searchable by other OpenLDAP entries,
|
|
readable by clients connecting from somewhere in the
|
|
OpenLDAP.org domain, and comparable by everybody else.
|
|
|
|
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:
|
|
|
|
E: access to attr=member,entry
|
|
E: by dnattr=member selfwrite
|
|
|
|
The dnattr {{EX: <who>}} selector says that the access applies to
|
|
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.
|
|
|
|
Note that the attr=member construct in the {{EX: <what>}} clause is a
|
|
shorthand for the clause "dn=* attr=member" (i.e., it matches
|
|
the member attribute in all entries).
|
|
|
|
|
|
|
|
H2: Schema Enforcement
|
|
|
|
|
|
|
|
The {{EX: objectclass}} and schemacheck configuration file options
|
|
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
|
|
schemacheck option. The format of an {{EX: objectclass}} line is:
|
|
|
|
E: objectclass <name>
|
|
E: [ requires <attrs> ]
|
|
E: [ allows <attrs> ]
|
|
|
|
This option defines the schema rules for the object class
|
|
given by {{EX: <name>}}. Schema rules consist of the attributes the
|
|
entry is required to have (given by the requires {{EX: <attrs>}}
|
|
clause) and those attributes that it may optionally have (given
|
|
by the allows {{EX: <attrs>}} clause). In both clauses, {{EX: <attrs>}} is a
|
|
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:
|
|
|
|
E: objectclass myperson
|
|
E: requires cn, sn, objectclass
|
|
E: allows mail, phone, fax
|
|
|
|
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:
|
|
|
|
E: schemacheck on
|
|
|
|
|
|
|
|
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
|
|
E: 2. include /usr/local/etc/slapd.at.conf
|
|
E: 3. include /usr/local/etc/slapd.oc.conf
|
|
E: 4. schemacheck on
|
|
E: 5. referral ldap://ldap.openldap.org
|
|
|
|
Line 1 is a comment. Lines 2 and 3 include other config files
|
|
containing attribute and object class definitions, respectively.
|
|
Line 4 turns on schema checking. The {{EX: referral}} option on line 5
|
|
means that queries not local to one of the databases defined
|
|
below will be referred to the LDAP server running on the
|
|
standard port (389) at the host {{EX: ldap.openldap.org}}.
|
|
|
|
The next section of the configuration file defines an LDBM
|
|
backend that will handle queries for things in the
|
|
"o=OpenLDAP Project, c=US" portion of the tree. The
|
|
database is to be replicated to two slave slapds, one on
|
|
truelies, the other on judgmentday. Indexes are to be
|
|
maintained for several attributes, and the {{EX: userPassword}}
|
|
attribute is to be protected from unauthorized access.
|
|
|
|
E: 1. # ldbm definition for the U-M database
|
|
E: 2. database ldbm
|
|
E: 3. suffix "o=OpenLDAP Project, c=US"
|
|
E: 4. directory /usr/local/var/openldap
|
|
E: 6. rootdn "cn=Manager, o=OpenLDAP Project, c=US"
|
|
E: 7. rootpw secret
|
|
E: 8. replogfile /usr/local/var/openldap/slapd.replog
|
|
E: 9. replica host=slave1.openldap.org:389
|
|
E: 10. binddn="cn=Replicator, o=OpenLDAP Project, c=US"
|
|
E: 11. bindmethod=simple credentials=secret
|
|
E: 12.replica host=slave2.openldap.org
|
|
E: 13. binddn="cn=Replicator, o=OpenLDAP Project, c=US"
|
|
E: 14. bindmethod=kerberos
|
|
E: 15. srvtab=/etc/srvtab.slave2
|
|
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
|
|
E: 21.defaultaccess read
|
|
E: 22.access to attr=userpassword
|
|
E: 23. by self write
|
|
E: 24. by dn="cn=Admin, o=OpenLDAP Project, c=US" write
|
|
E: 25. by * compare
|
|
|
|
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
|
|
10 on slurpd for more information on these options.
|
|
|
|
Lines 16 through 19 indicate the indexes to maintain for
|
|
various attributes. The default is not to maintain any indexes
|
|
(line 19).
|
|
|
|
Lines 20 through 25 specify access control for entries in the
|
|
database. For all entries, the {{EX: userPassword}} attribute is
|
|
writable by the entry and the "admin" entry, comparable by
|
|
everyone else. All other attributes allow read access by
|
|
default (line 21). Note that the special "entry" attribute is not
|
|
required in the access directive beginning on line 22. This is
|
|
because the default access is read.
|
|
|
|
The next section of the example configuration file defines
|
|
another LDBM database. This one handles queries involving
|
|
the "o="Babs, Inc.", c=US" subtree.
|
|
|
|
E: 1. # ldbm definition for Babs, Inc. database
|
|
E: 2. database ldbm
|
|
E: 3. suffix "o=\"Babs, Inc.\", c=US"
|
|
E: 4. directory /usr/local/ldbm-babs
|
|
E: 5. rootdn "cn=Babs, o=\"Babs, Inc.\", c=US"
|
|
E: 6. index default
|
|
|
|
Note the use of `\' to escape the quotes necessary in the
|
|
distinguished names given on lines 3 and 5. By default, all
|
|
indexes are maintained for every attribute in an entry.
|
|
|