mirror of
https://git.openldap.org/openldap/openldap.git
synced 2024-12-21 03:10:25 +08:00
294 lines
8.5 KiB
Groff
294 lines
8.5 KiB
Groff
.TH SLAPD-LDAP 5 "RELEASEDATE" "OpenLDAP LDVERSION"
|
|
.\" Copyright 1998-2004 The OpenLDAP Foundation All Rights Reserved.
|
|
.\" Copying restrictions apply. See COPYRIGHT/LICENSE.
|
|
.\" $OpenLDAP$
|
|
.SH NAME
|
|
slapd-ldap \- LDAP backend to slapd
|
|
.SH SYNOPSIS
|
|
ETCDIR/slapd.conf
|
|
.SH DESCRIPTION
|
|
The LDAP backend to
|
|
.BR slapd (8)
|
|
is not an actual database; instead it acts as a proxy to forward incoming
|
|
requests to another LDAP server. While processing requests it will also
|
|
chase referrals, so that referrals are fully processed instead of being
|
|
returned to the slapd client.
|
|
|
|
Sessions that explicitly Bind to the back-ldap database always create their
|
|
own private connection to the remote LDAP server. Anonymous sessions will
|
|
share a single anonymous connection to the remote server. For sessions bound
|
|
through other mechanisms, all sessions with the same DN will share the
|
|
same connection. This connection pooling strategy can enhance the proxy's
|
|
efficiency by reducing the overhead of repeatedly making/breaking multiple
|
|
connections.
|
|
|
|
The ldap database can also act as an information service, i.e. the identity
|
|
of locally authenticated clients is asserted to the remote server, possibly
|
|
in some modified form.
|
|
For this purpose, the proxy binds to the remote server with some
|
|
administrative identity, and, if required, authorizes the asserted identity.
|
|
See the
|
|
.IR idassert- *
|
|
rules below.
|
|
The administrative identity of the proxy, on the remote server, must be
|
|
allowed to authorize by means of appropriate
|
|
.B authzTo
|
|
rules; see
|
|
.BR slapd.conf (5)
|
|
for details.
|
|
|
|
.SH CONFIGURATION
|
|
These
|
|
.B slapd.conf
|
|
options apply to the LDAP backend database.
|
|
That is, they must follow a "database ldap" line and come before any
|
|
subsequent "backend" or "database" lines.
|
|
Other database options are described in the
|
|
.BR slapd.conf (5)
|
|
manual page.
|
|
.LP
|
|
Note: It is strongly recommended to set
|
|
.LP
|
|
.RS
|
|
.nf
|
|
lastmod off
|
|
.fi
|
|
.RE
|
|
.LP
|
|
for every
|
|
.B ldap
|
|
and
|
|
.B meta
|
|
database.
|
|
This is because operational attributes related to entry creation and
|
|
modification should not be used, as they could be passed to the target
|
|
servers, generating an error.
|
|
.TP
|
|
.B uri <ldapurl>
|
|
LDAP server to use. Multiple URIs can be set in in a single
|
|
.B ldapurl
|
|
argument, resulting in the underlying library automatically
|
|
call the first server of the list that responds, e.g.
|
|
|
|
\fBuri "ldap://host/ ldap://backup-host"\fP
|
|
|
|
The URI list is space- or comma-separated.
|
|
.TP
|
|
.B server <hostport>
|
|
Obsolete option; same as `uri ldap://<hostport>/'.
|
|
.TP
|
|
.B acl-authcDN "<administrative DN for access control purposes>"
|
|
DN which is used to query the target server for acl checking; it
|
|
should have read access on the target server to attributes used on the
|
|
proxy for acl checking.
|
|
There is no risk of giving away such values; they are only used to
|
|
check permissions.
|
|
.B The acl-authcDN identity is by no means implicitly used by the proxy
|
|
.B when the client connects anonymously, so it cannot be used to
|
|
.B anonymously query Active Directory.
|
|
.TP
|
|
.B acl-passwd <password>
|
|
Password used with the bind DN above.
|
|
.TP
|
|
.B idassert-authcdn "<administrative DN for proxyAuthz purposes>"
|
|
DN which is used to propagate the client's identity to the target
|
|
by means of the proxyAuthz control when the client does not
|
|
belong to the DIT fragment that is being proxyied by back-ldap.
|
|
This is useful when operations performed by users bound to another
|
|
backend are propagated through back-ldap.
|
|
This requires the entry with
|
|
.B idassert-authcdn
|
|
identity on the remote server to have
|
|
.B proxyAuthz
|
|
privileges on a wide set of DNs, e.g.
|
|
.BR authzTo=dn.subtree:"" ,
|
|
and the remote server to have
|
|
.B authz-policy
|
|
set to
|
|
.B to
|
|
or
|
|
.BR both .
|
|
See
|
|
.BR slapd.conf (5)
|
|
for details on these statements and for remarks and drawbacks about
|
|
their usage.
|
|
.TP
|
|
.B idassert-passwd <password>
|
|
Password used with the proxy authzDN above.
|
|
.TP
|
|
.B idassert-mode <mode>
|
|
defines what type of
|
|
.I identity assertion
|
|
is used.
|
|
The supported modes are:
|
|
.RS
|
|
.RS
|
|
.TP
|
|
.B <mode>={legacy|anonymous|none|<id>|self}
|
|
.RE
|
|
.RS
|
|
.B <id>={u:<ID>|[dn:]<DN>}
|
|
.RE
|
|
|
|
The default is
|
|
.BR legacy ,
|
|
which implies that the proxy will bind as
|
|
.I idassert-authcdn
|
|
and assert the client's identity when it is not anonymous.
|
|
Direct binds are always proxied.
|
|
The other modes imply that the proxy will always bind as
|
|
.IR idassert-authcdn ,
|
|
unless restricted by
|
|
.BR idassert-authzFrom
|
|
rules (see below), in which case the operation will fail;
|
|
eventually, it will assert some other identity according to
|
|
.BR <mode> .
|
|
Other identity assertion modes are
|
|
.BR anonymous
|
|
and
|
|
.BR self ,
|
|
which respectively mean that the
|
|
.I empty
|
|
or the
|
|
.IR client 's
|
|
identity
|
|
will be asserted;
|
|
.BR none ,
|
|
which means that no proxyAuthz control will be used, so the
|
|
.I idassert-authcdn
|
|
identity will be asserted.
|
|
Moreover, if a string prefixed with
|
|
.B u:
|
|
or
|
|
.B dn:
|
|
is used as
|
|
.BR <mode> ,
|
|
that identity will be asserted.
|
|
Ths string is also treated as a DN if it is not prefixed
|
|
by any recognized type indicator. Whether or not the
|
|
.B dn:
|
|
prefix is present, the string must pass DN validation and normalization.
|
|
For all modes that require the use of the
|
|
.I proxyAuthz
|
|
control, on the remote server the proxy identity must have appropriate
|
|
.I authzTo
|
|
permissions, or the asserted identities must have appropriate
|
|
.I authzFrom
|
|
permissions. Note, however, that the ID assertion feature is mostly
|
|
useful when the asserted identities do not exist on the remote server.
|
|
.RE
|
|
.TP
|
|
.B idassert-authzFrom <authz>
|
|
if defined, selects what
|
|
.I local
|
|
identities are authorized to exploit the identity assertion feature.
|
|
The string
|
|
.B authz
|
|
follows the rules defined for the
|
|
.I authzFrom
|
|
attribute.
|
|
See
|
|
.BR slapd.conf (5),
|
|
section related to
|
|
.BR authz-policy ,
|
|
for details on the supported syntaxes.
|
|
.TP
|
|
.B idassert-method <method> [<saslargs>]
|
|
where valid method values are
|
|
.RS
|
|
.TP
|
|
.B <method>={none|simple|sasl}
|
|
.RE
|
|
.RS
|
|
.B <saslargs>=[mech=<mech>] [realm=<realm>] [authcid=<authcid>] [cred=<cred>]
|
|
|
|
.RE
|
|
.RS
|
|
If method is
|
|
.IR sasl ,
|
|
extra parameters can be given a described above.
|
|
The default is
|
|
.BR simple ;
|
|
.B none
|
|
inhibits proxy authorization;
|
|
.B sasl
|
|
uses a SASL bind with the above parameters; if required,
|
|
.I authorization
|
|
is performed by means of native SASL mechanism, and no proxyAuthz
|
|
is used for subsequent operations.
|
|
.RE
|
|
.TP
|
|
.B proxy-whoami
|
|
Turns on proxying of the WhoAmI extended operation. If this option is
|
|
given, back-ldap will replace slapd's original WhoAmI routine with its
|
|
own. On slapd sessions that were authenticated by back-ldap, the WhoAmI
|
|
request will be forwarded to the remote LDAP server. Other sessions will
|
|
be handled by the local slapd, as before. This option is mainly useful
|
|
in conjunction with Proxy Authorization.
|
|
.TP
|
|
.B rebind-as-user
|
|
If this option is given, the client's bind credentials are remembered
|
|
for rebinds when chasing referrals.
|
|
.TP
|
|
.B suffixmassage <suffix> <massaged (remote) suffix>
|
|
DNs ending with <suffix> in a request are changed to end with <remote
|
|
suffix> before sending the request to the remote server, and <remote
|
|
suffix> in the results are changed back to <suffix> before returning
|
|
them to the client.
|
|
The <suffix> field must be defined as a valid suffix
|
|
for the current database.
|
|
.TP
|
|
.B map "{attribute | objectclass} [<local name> | *] {<foreign name> | *}"
|
|
Map attribute names and object classes from the foreign server to
|
|
different values on the local slapd.
|
|
The reason is that some attributes might not be part of the local
|
|
slapd's schema, some attribute names might be different but serve the
|
|
same purpose, etc.
|
|
If local or foreign name is `*', the name is preserved.
|
|
If local name is omitted, the foreign name is removed.
|
|
Unmapped names are preseved if both local and foreign name are `*',
|
|
and removed if local name is omitted and foreign name is `*'.
|
|
.TP
|
|
.B rewrite*
|
|
The rewrite options are described in the "REWRITING" section of the
|
|
.BR slapd-meta (5)
|
|
manual page.
|
|
.SH EXAMPLES
|
|
This maps the OpenLDAP objectclass `groupOfNames' to the Active
|
|
Directory objectclass `group':
|
|
.LP
|
|
.RS
|
|
.nf
|
|
map objectclass groupOfNames group
|
|
.fi
|
|
.RE
|
|
.LP
|
|
This presents a limited attribute set from the foreign
|
|
server:
|
|
.LP
|
|
.RS
|
|
.nf
|
|
map attribute cn *
|
|
map attribute sn *
|
|
map attribute manager *
|
|
map attribute description *
|
|
map attribute *
|
|
.fi
|
|
.RE
|
|
.LP
|
|
These lines map cn, sn, manager, and description to themselves, and
|
|
any other attribute gets "removed" from the object before it is sent
|
|
to the client (or sent up to the LDAP server). This is obviously a
|
|
simplistic example, but you get the point.
|
|
.SH FILES
|
|
.TP
|
|
ETCDIR/slapd.conf
|
|
default slapd configuration file
|
|
.SH SEE ALSO
|
|
.BR slapd.conf (5),
|
|
.BR slapd-meta (5),
|
|
.BR slapd (8),
|
|
.BR ldap (3).
|
|
.SH AUTHOR
|
|
Howard Chu, with enhancements by Pierangelo Masarati
|