.TH SLAPD-LDAP 5 "RELEASEDATE" "OpenLDAP LDVERSION"
-.\" Copyright 1998-2003 The OpenLDAP Foundation All Rights Reserved.
+.\" Copyright 1998-2004 The OpenLDAP Foundation All Rights Reserved.
.\" Copying restrictions apply. See COPYRIGHT/LICENSE.
.\" $OpenLDAP$
.SH NAME
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
manual page.
.LP
Note: It is strongly recommended to set
+.LP
.RS
+.nf
lastmod off
+.fi
.RE
+.LP
for every
.B ldap
and
.B server <hostport>
Obsolete option; same as `uri ldap://<hostport>/'.
.TP
-.B
binddn "<administrative DN for access control purposes>"
+.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
.BR slapd-meta (5),
.BR slapd (8),
.BR ldap (3).
-
+.SH AUTHOR
+Howard Chu, with enhancements by Pierangelo Masarati
projects / openldap / blobdiff