slapd.conf.5

ldap服务器源码

particular, it is not possible to use moddn to move an entry from
one subordinate to another subordinate within the namingContext.

If the optional \fBadvertise\fP flag is supplied, the naming context of
this database is advertised in the root DSE. The default is to hide this
database context, so that only the superior context is visible.

If the slap tools
.BR slapcat (8),
.BR slapadd (8),
or
.BR slapindex (8)
are used on the superior database, any glued subordinates that support
these tools are opened as well.

Databases that are glued together should usually be configured with the
same indices (assuming they support indexing), even for attributes that
only exist in some of these databases. In general, all of the glued
databases should be configured as similarly as possible, since the intent
is to provide the appearance of a single directory.

Note that the \fIsubordinate\fP functionality is implemented internally
by the \fIglue\fP overlay and as such its behavior will interact with other
overlays in use. By default, the glue overlay is automatically configured as
the last overlay on the superior backend. Its position on the backend
can be explicitly configured by setting an \fBoverlay glue\fP directive
at the desired position. This explicit configuration is necessary e.g.
when using the \fIsyncprov\fP overlay, which needs to follow \fIglue\fP
in order to work over all of the glued databases. E.g.
.RS
.nf
	database bdb
	suffix dc=example,dc=com
	...
	overlay glue
	overlay syncprov
.fi
.RE
.HP
.hy 0
.B syncrepl rid=<replica ID>
.B provider=ldap[s]://<hostname>[:port]
.B [type=refreshOnly|refreshAndPersist]
.B [interval=dd:hh:mm:ss]
.B [retry=[<retry interval> <# of retries>]+]
.B searchbase=<base DN>
.B [filter=<filter str>]
.B [scope=sub|one|base]
.B [attrs=<attr list>]
.B [attrsonly]
.B [sizelimit=<limit>]
.B [timelimit=<limit>]
.B [schemachecking=on|off]
.B [starttls=yes|critical]
.B [bindmethod=simple|sasl]
.B [binddn=<dn>]
.B [saslmech=<mech>]
.B [authcid=<identity>]
.B [authzid=<identity>]
.B [credentials=<passwd>]
.B [realm=<realm>]
.B [secprops=<properties>]
.B [logbase=<base DN>]
.B [logfilter=<filter str>]
.B [syncdata=default|accesslog|changelog]
.RS
Specify the current database as a replica which is kept up-to-date with the 
master content by establishing the current
.BR slapd (8)
as a replication consumer site running a
.B syncrepl
replication engine.
The replica content is kept synchronized to the master content using
the LDAP Content Synchronization protocol. Refer to the
"OpenLDAP Administrator's Guide" for detailed information on
setting up a replicated
.B slapd
directory service using the 
.B syncrepl
replication engine.
.B rid
identifies the current
.B syncrepl
directive within the replication consumer site.
It is a non-negative integer having no more than three digits.
.B provider
specifies the replication provider site containing the master content
as an LDAP URI. If <port> is not given, the standard LDAP port number
(389 or 636) is used. The content of the
.B syncrepl
replica is defined using a search
specification as its result set. The consumer
.B slapd
will send search requests to the provider
.B slapd
according to the search specification. The search specification includes
.B searchbase, scope, filter, attrs, attrsonly, sizelimit,
and
.B timelimit
parameters as in the normal search specification. 
The \fBscope\fP defaults to \fBsub\fP, the \fBfilter\fP defaults to
\fB(objectclass=*)\fP, and there is no default \fBsearchbase\fP. The
\fBattrs\fP list defaults to \fB"*,+"\fP to return all user and operational
attributes, and \fBattrsonly\fP is unset by default.
The \fBsizelimit\fP and \fBtimelimit\fP only
accept "unlimited" and positive integers, and both default to "unlimited".
The LDAP Content Synchronization protocol has two operation types.
In the
.B refreshOnly
operation, the next synchronization search operation
is periodically rescheduled at an interval time (specified by 
.B interval
parameter; 1 day by default)
after each synchronization operation finishes.
In the
.B refreshAndPersist
operation, a synchronization search remains persistent in the provider slapd.
Further updates to the master replica will generate
.B searchResultEntry
to the consumer slapd as the search responses to the persistent
synchronization search.
If an error occurs during replication, the consumer will attempt to
reconnect according to the
.B retry
parameter which is a list of the <retry interval> and <# of retries> pairs.
For example, retry="60 10 300 3" lets the consumer retry every 60 seconds
for the first 10 times and then retry every 300 seconds for the next 3
times before stop retrying. The `+' in <# of retries> means indefinite
number of retries until success.
The schema checking can be enforced at the LDAP Sync
consumer site by turning on the
.B schemachecking
parameter. The default is off.
The
.B starttls
parameter specifies use of the StartTLS extended operation
to establish a TLS session before Binding to the provider. If the
StartTLS request fails and the
.B critical
argument was used, the session will be aborted. Otherwise the syncrepl
session continues without TLS.
A
.B bindmethod
of 
.B simple
requires the options 
.B binddn
and 
.B credentials
and should only be used when adequate security services
(e.g. TLS or IPSEC) are in place.
A
.B bindmethod
of
.B sasl
requires the option
.B saslmech.
Depending on the mechanism, an authentication identity and/or
credentials can be specified using
.B authcid
and
.B credentials.
The
.B authzid
parameter may be used to specify an authorization identity.
Specific security properties (as with the
.B sasl-secprops
keyword above) for a SASL bind can be set with the
.B secprops
option. A non default SASL realm can be set with the
.B realm 
option.

Rather than replicating whole entries, the consumer can query logs of
data modifications. This mode of operation is referred to as \fIdelta
syncrepl\fP. In addition to the above parameters, the
.B logbase
and
.B logfilter
parameters must be set appropriately for the log that will be used. The
.B syncdata
parameter must be set to either "accesslog" if the log conforms to the
.BR slapo-accesslog (5)
log format, or "changelog" if the log conforms
to the obsolete \fIchangelog\fP format. If the
.B syncdata
parameter is omitted or set to "default" then the log parameters are
ignored.
.RE
.TP
.B updatedn <dn>
This option is only applicable in a slave
database updated using
.BR slurpd(8). 
It specifies the DN permitted to update (subject to access controls)
the replica (typically, this is the DN
.BR slurpd (8)
binds to update the replica).  Generally, this DN
.I should not
be the same as the
.B rootdn 
used at the master.
.TP
.B updateref <url>
Specify the referral to pass back when
.BR slapd (8)
is asked to modify a replicated local database.
If specified multiple times, each url is provided.

.SH DATABASE-SPECIFIC OPTIONS
Each database may allow specific configuration options; they are
documented separately in the backends' manual pages.
.SH BACKENDS
The following backends can be compiled into slapd.
They are documented in the
.BR slapd-<backend> (5)
manual pages.
.TP
.B bdb
This is the recommended primary backend for a normal slapd database.
It takes care to configure it properly.
It uses the transactional database interface of the Sleepycat Berkeley
DB (BDB) package to store data.
.TP
.B config
This backend is used to manage the configuration of slapd run-time.
.TP
.B dnssrv
This backend is experimental.
It serves up referrals based upon SRV resource records held in the
Domain Name System.
.TP
.B hdb
This is a variant of the BDB backend that uses a hierarchical database
layout which supports subtree renames.
.TP
.B ldap
This backend acts as a proxy to forward incoming requests to another
LDAP server.
.TP
.B ldbm
This is an easy-to-configure but obsolete database backend. It
does not offer the data durability features of the BDB and HDB
backends and hence is deprecated in favor of these robust backends.
LDBM uses lightweight non-transactional DB interfaces,
such as those providing by GDBM or Berkeley DB, to store data.
.TP
.B ldif
This database uses the filesystem to build the tree structure
of the database, using plain ascii files to store data.
Its usage should be limited to very simple databases, where performance
is not a requirement.
.TP
.B meta
This backend performs basic LDAP proxying with respect to a set of
remote LDAP servers. It is an enhancement of the ldap backend.
.TP
.B monitor
This backend provides information about the running status of the slapd
daemon.
.TP
.B null
Operations in this backend succeed but do nothing.
.TP
.B passwd
This backend is provided for demonstration purposes only.
It serves up user account information from the system
.BR passwd (5)
file.
.TP
.B perl
This backend embeds a
.BR perl (1)
interpreter into slapd.
It runs Perl subroutines to implement LDAP operations.
.TP
.B relay
This backend is experimental.
It redirects LDAP operations to another database
in the same server, based on the naming context of the request.
Its use requires the 
.B rwm
overlay (see
.BR slapo-rwm (5)
for details) to rewrite the naming context of the request.
It is primarily intended to implement virtual views on databases
that actually store data.
.TP
.B shell
This backend executes external programs to implement LDAP operations.
It is primarily intended to be used in prototypes.
.TP
.B sql
This backend is experimental.
It services LDAP requests from an SQL database.
.SH OVERLAYS
The following overlays can be compiled into slapd.
They are documented in the
.BR slapo-<overlay> (5)
manual pages.
.TP
.B accesslog
Access Logging.
This overlay can record accesses to a given backend database on another
database.
.TP
.B auditlog
Audit Logging.
This overlay records changes on a given backend database to an LDIF log
file.
By default it is not built.
.TP
.B chain
Chaining.
This overlay allows automatic referral chasing when a referral would
have been returned, either when configured by the server or when 
requested by the client.
.TP
.B denyop
Deny Operation.
This overlay allows selected operations to be denied, similar to the
\fBrestrict\fP option.
.TP
.B dyngroup
Dynamic Group.
This is a demo overlay which extends the Compare operation to detect
members of a dynamic group.
It has no effect on any other operations.
.TP
.B dynlist
Dynamic List.
This overlay allows expansion of dynamic groups and more.
.TP
.B lastmod
Last Modification.
This overlay maintains a service entry in the database with the DN,
modification type, modifiersName and modifyTimestamp of the last write
operation performed on that database.
.TP
.B pcache
Proxycache.
This overlay allows caching of LDAP search requests in a local database.
It is most often used with the ldap or meta backends.
.TP
.B ppolicy
Password Policy.
This overlay provides a variety of password control mechanisms,
e.g. password aging, password reuse and duplication control, mandatory
password resets, etc.
.TP
.B refint
Referential Integrity.
This overlay can be used with a backend database such as
.BR slapd-bdb (5)
to maintain the cohesiveness of a schema which utilizes reference
attributes.
.TP
.B retcode
Return Code.
This overlay is useful to test the behavior of clients when
server-generated erroneous and/or unusual responses occur.
.TP
.B rwm
Rewrite/remap.
This overlay is experimental.
It performs basic DN/data rewrite and
objectClass/attributeType mapping.
.TP
.B syncprov
Syncrepl Provider.
This overlay implements the provider-side support for
.B syncrepl
replication, including persistent search functionality.
.TP
.B translucent
Translucent Proxy.
This overlay can be used with a backend database such as
.BR slapd-bdb (5)
to create a "translucent proxy".
Content of entries retrieved from a remote LDAP server can be partially
overridden by the database.
.TP
.B unique
Attribute Uniqueness.
This overlay can be used with a backend database such as
.BR slapd-bdb (5)
to enforce the uniqueness of some or all attributes within a subtree.
.SH EXAMPLES
.LP
Here is a short example of a configuration file:
.LP
.RS
.nf
include   SYSCONFDIR/schema/core.schema
pidfile   LOCALSTATEDIR/slapd.pid

# Subtypes of "name" (e.g. "cn" and "ou") with the
# option ";x-hidden" can be searched for/compared,
# but are not shown.  See \fBslapd.access\fP(5).
attributeoptions x-hidden lang-
access to attr=name;x-hidden by * =cs

# Protect passwords.  See \fBslapd.access\fP(5).
access    to attrs=userPassword  by * auth
# Read access to other attributes and entries.
access    to *  by * read

database  bdb
suffix    "dc=our-domain,dc=com"
# The database directory MUST exist prior to
# running slapd AND should only be accessible
# by the slapd/tools. Mode 0700 recommended.
directory LOCALSTATEDIR/openldap-data
# Indices to maintain
index     objectClass  eq
index     cn,sn,mail   pres,eq,approx,sub

# We serve small clients that do not handle referrals,
# so handle remote lookups on their behalf.
database  ldap
suffix    ""
uri       ldap://ldap.some-server.com/
lastmod   off
.fi
.RE
.LP
"OpenLDAP Administrator's Guide" contains a longer annotated
example of a configuration file.
The original ETCDIR/slapd.conf is another example.
.SH FILES
.TP
ETCDIR/slapd.conf
default slapd configuration file
.SH SEE ALSO
.BR ldap (3),
.BR slapd\-bdb (5),
.BR slapd\-dnssrv (5),
.BR slapd\-hdb (5),
.BR slapd\-ldap (5),
.BR slapd\-ldbm (5),
.BR slapd\-ldif (5),
.BR slapd\-meta (5),
.BR slapd\-monitor (5),
.BR slapd\-null (5),
.BR slapd\-passwd (5),
.BR slapd\-perl (5),
.BR slapd\-relay (5),
.BR slapd\-shell (5),
.BR slapd\-sql (5),
.BR slapd.access (5),
.BR slapd.plugin (5),
.BR slapd.replog (5),
.BR slapd (8),
.BR slapacl (8),
.BR slapadd (8),
.BR slapauth (8),
.BR slapcat (8),
.BR slapdn (8),
.BR slapindex (8),
.BR slappasswd (8),
.BR slaptest (8),
.BR slurpd (8).

Known overlays are documented in
.BR slapo\-accesslog (5),
.BR slapo\-auditlog (5),
.BR slapo\-chain (5),
.BR slapo\-dynlist (5),
.BR slapo\-lastmod (5),
.BR slapo\-pcache (5),
.BR slapo\-ppolicy (5),
.BR slapo\-refint (5),
.BR slapo\-retcode (5),
.BR slapo\-rwm (5),
.BR slapo\-syncprov (5),
.BR slapo\-translucent (5),
.BR slapo\-unique (5).
.LP
"OpenLDAP Administrator's Guide" (http://www.OpenLDAP.org/doc/admin/)
.SH ACKNOWLEDGEMENTS
.B OpenLDAP
is developed and maintained by The OpenLDAP Project (http://www.openldap.org/).
.B OpenLDAP
is derived from University of Michigan LDAP 3.3 Release.