openldap/doc/guide/admin/slapdconfig.sdf

966 lines
31 KiB
Plaintext
Raw Normal View History

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
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
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:
> # 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,
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
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
logged to the {{syslogd}}(8) LOG_LOCAL4 facility). You must
have compiled slapd with -DLDAP_DEBUG for this to work
2000-08-11 01:49:29 +08:00
(except for the two statistics levels, which are always enabled).
1999-04-24 07:00:44 +08:00
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:
!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:
E: loglevel -1
1999-04-24 07:00:44 +08:00
This will cause lots and lots of debugging information to be
logged.
1999-04-24 07:00:44 +08:00
\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
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:
> 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:
> 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:
> 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
2000-08-11 01:49:29 +08:00
Kerberos keys necessary for authenticating clients using
Kerberos. This directive is only meaningful if you are using
Kerberos authentication, which must be enabled at compile
1999-04-24 07:00:44 +08:00
time by including the appropriate definitions in the
{{EX:Make-common}} file.
1999-04-24 07:00:44 +08:00
\Default:
> 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:
> 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:
> 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:
> 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:
> readonly off
1999-04-24 07:00:44 +08:00
H4: replica
> 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
{{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
given, the standard LDAP port number (389) is used.
1999-04-24 07:00:44 +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
{{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
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
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
given. Kerberos authentication requires a valid srvtab file.
1999-04-24 07:00:44 +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.
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
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:
> 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
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:
> rootkrbname admin@EXAMPLE.COM
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:
> 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:
> 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:
> 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:
> 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:
> 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:
> 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
2000-08-11 01:49:29 +08:00
of indices to be maintained for objectClass and uid attribute
types. The third line causes equality, substring, and approximate
filters to be maintained for cn and sn attribute types.
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:
> 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
> 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:
> 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:
> file /etc/passwd
1999-04-24 07:00:44 +08:00
H3: TCL Backend-Specific Directives
H4: scriptpath <pathname>
This is the full path to a file containing the TCL command(s) to handle
the LDAP operations.
H4: Proc specifiers
> bind <proc>
> unbind <proc>
> search <proc>
> compare <proc>
> modify <proc>
> modrdn <proc>
> add <proc>
> delete <proc>
> abandon <proc>
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.
\Example:
> 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 {{EX:tclrealm}} is specified, it is put into the
"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:
> <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
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:
> 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:
> 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:
> 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:
> 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:
> 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:
> 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:
!block table; colaligns="LRL"; align=Center; \
title="Table 5.2: Access Levels"
Level Privledges Description
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
1999-04-24 07:00:44 +08:00
example, granting someone write access to an entry also
grants them read, search, compare, and auth access. However,
one may use the privledges specify to grant specific permissions.
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
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.
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
{{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
{{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
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:
> access to * by * read
1999-04-24 07:00:44 +08:00
This access directive grants read access to everyone.
1999-04-24 07:00:44 +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.
> access to dn=".*,dc=example,dc=com"
> by * search
> access to dn=".*,dc=com"
> by * read
1999-04-24 07:00:44 +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 to
{{EX:dc=com}} as the neither access directive matches this DN.
If the 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
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
{{EX:defaultaccess}} granted.
1999-04-24 07:00:44 +08:00
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="(.*,)?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
This example applies to entries in the "{{EX:dc=example, dc=com}}"
subtree. To all attributes except {{EX:homePhone}}, the entry itself
can write them, other {{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 other {{EX:example.com}} entries, readable by clients connecting
from somewhere in the {{EX: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:
> access to attr=member,entry
> by dnattr=member selfwrite
1999-04-24 07:00:44 +08:00
The dnattr {{EX:<who>}} selector says that the access applies to
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.
Note that the {{EX:attr=member}} construct in the {{EX:<what>}}
clause is a shorthand for the clause "{{EX:dn=.* attr=member}}"
(i.e., it matches the {{EX:member}} attribute in all entries).
H2: Schema Specification
The {{EX:objectclass}} and {{attributeTypes}} configuration file
directives can be used to define schema rules on entries in the
directory.
H3: Object Identifiers
Each schema element is identified by a globally unique Object
Identifier (OID). OIDs are also used to identify other objects.
They are commonly found in protocols described by ASN.1. In
particular, they are heavy used by Simple Network Management
2000-08-11 01:49:29 +08:00
Protocol (SNMP). As OIDs are hierarchical, your organization
can obtain one OID and branch in as needed. For example,
if your organization were assigned OID 1.1, you could branch
the tree as follows:
!block table; colaligns="RL"; align=Center; \
title="Table 5.1: Debugging Levels"
OID Assignment
1.1 Organization's OID
1.1.1 SNMP Elements
1.1.2 LDAP Elements
1.1.2.1 AttributeTypes
1.1.2.1.1 myAttribute
1.1.2.2 ObjectClasses
1.1.2.2.1 myObjectClass
!endblock
1999-04-24 07:00:44 +08:00
2000-08-11 01:49:29 +08:00
You are, of course, free to design a hierarchy suitable to your
organizational needs under your organization's OID.
1999-04-24 07:00:44 +08:00
.{{Under no circumstances should you use a fictious OID!}}
1999-04-24 07:00:44 +08:00
To obtain a fully registered OID at {{no cost}}, apply for
2000-08-11 01:49:29 +08:00
a OID under {{ORG[expand]IANA}} maintained
{{Private Enterprise}} arch. Any private enterprise (organization)
may request an OID to be assigned under this arch. Just fill
2000-08-11 01:49:29 +08:00
out the form at {{URL: http://www.iana.org/cgi-bin/enterprise.pl}}
and your official OID will be sent to you usually within a few days.
1999-04-24 07:00:44 +08:00
H3: AttributeType Specification
1999-04-24 07:00:44 +08:00
{{B:To be specified.}}
1999-04-24 07:00:44 +08:00
H3: ObjectClass Specification
The schema rules are defined by one or more
1999-04-24 07:00:44 +08:00
objectclass lines, and enforcement is turned on or off via the
schemacheck directives. The format of an {{EX:objectclass}} line is:
1999-04-24 07:00:44 +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
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
by the allows {{EX:<attrs>}} clause). In both clauses, {{EX:<attrs>}}
is a comma-separated list of attribute names.
1999-04-24 07:00:44 +08:00
For example, to define an object class called {{myPerson}}, you
1999-04-24 07:00:44 +08:00
might include a definition like this:
> objectclass ( 1.2.3 NAME 'myPerson'
> DESC 'my person'
> MUST ( cn $ sn )
> MAY ( mail $ phone $ fax ) )
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 {{TERM:X.500}} tree; both are {{TERM:LDBM}}
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:
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.
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
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
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: 4. # ldbm definition for the example.com
E: 5. database ldbm
E: 6. suffix "dc=example, dc=com"
E: 7. directory /usr/local/var/openldap
E: 8. rootdn "cn=Manager, dc=example, dc=com"
E: 9. rootpw secret
E: 10. replogfile /usr/local/var/openldap/slapd.replog
E: 11. replica host=slave1.example.com:389
E: 12. binddn="cn=Replicator, dc=example, dc=com"
E: 13. bindmethod=simple credentials=secret
E: 14. replica host=slave2.example.com
E: 15. binddn="cn=Replicator, dc=example, dc=com"
E: 16. bindmethod=kerberos
E: 17. srvtab=/etc/srvtab.slave2
E: 18. # ldbm indexed attribute definitions
E: 19. index uid pres,eq
E: 20. index cn,sn,uid pres,eq,approx,sub
E: 21. index objectClass eq
E: 22. # ldbm access control definitions
E: 23. access to attr=userPassword
E: 24. by self write
E: 25. by anonymous auth
E: 26. by dn="cn=Admin,dc=example,dc=com" write
E: 27. by * none
E: 28. access to *
E: 29. by self write
E: 30. by anonymous auth
E: 31. by dn="cn=Admin,dc=example,dc=com" write
E: 32. by * read
Line 4 is a comment. The start of the database definition is
marked by the database keyword on line 5. Line 6 specifies
the DN suffix for queries to pass to this database. Line 7
1999-04-24 07:00:44 +08:00
specifies the directory in which the database files will live
Lines 8 and 9 identify the database "super user" entry and
1999-04-24 07:00:44 +08:00
associated password. This entry is not subject to access
control or size or time limit restrictions.
Lines 10 through 17 are for replication. Line 10 specifies the
1999-04-24 07:00:44 +08:00
replication log file (where changes to the database are logged
\- this file is written by slapd and read by slurpd). Lines 11
through 13 specify the hostname and port for a replicated
1999-04-24 07:00:44 +08:00
host, the DN to bind as when performing updates, the bind
method (simple) and the credentials (password) for the
binddn. Lines 14 through 17 specify a second replication site,
1999-04-24 07:00:44 +08:00
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 19 through 21 indicate the indexes to maintain for
various attributes.
1999-04-24 07:00:44 +08:00
Lines 23 through 32 specify access control for entries in the
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: 33. # ldbm definition for example.net
E: 34. database ldbm
E: 35. suffix "dc=example, dc=net"
E: 36. directory /usr/local/var/ldbm-example-net
E: 37. rootdn "cn=Manager, dc=example, dc=net"
1999-04-24 07:00:44 +08:00