> Full_Name: Pierangelo Masarati
> Version: HEAD/re24
> OS: irrelevant
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (220.127.116.11)
> Submitted by: ando
> When idassert-bind is configured to use SASL bind, an "authcID" needs to
> provided, while the "binddn" is not needed. However, if a
> provided as well, in some cases the proxiedAuthz control may be used
> incorrectly. The need to configure the "binddn" is not documented, so
> this ITS
> is minimally addressed by documenting this requirement.
I tripped over this change while investigating #6711. Adding this
is certainly not the right solution; SASL Binds ordinarily don't require a
BindDN and requiring it here just makes things confusing.
I understand the fix I'm suggesting can sound counter-intuitive. The
documentation should clearly indicate that the binddn in case of SASL is
for *local* and *internal* issues, and will not be part of the
authentication process. As an alternative, lc_bound_ndn could receive a
dummy DN (e.g. "cn=auth") to merely indicate a successful bind (or receive
the actual identity from the remote server using the authid control along
with the bind or performing a whoami extop later, as already implemented).
Also with the fixes that I made for #6711 I don't believe the
more. Please describe the conditions where the problem occurs.
> If the "binddn" is provided, everything works as expected, with the only
> issue that the DN of the user as it is known to back-meta may not match
> actual identity the "authcID" assumed on the remote server. The
> way to
> address this problem consists in performing a "WhoAmI" (RFC 4532) right
> the bind, or better use a "authorization identity control" (RFC 3829)
> along with
> the bind operation. Both approaches should be implemented, but they
> should not
> be used unless explicitly requested.
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/