masarati(a)aero.polimi.it wrote:
Full_Name: Pierangelo Masarati
Version: HEAD/re24
OS: irrelevant
URL:
ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (2.40.14.92)
Submitted by: ando
When idassert-bind is configured to use SASL bind, an "authcID" needs to be
provided, while the "binddn" is not needed. However, if a "binddn"
is not
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 requirement
is certainly not the right solution; SASL Binds ordinarily don't require a
BindDN and requiring it here just makes things confusing.
Also with the fixes that I made for #6711 I don't believe the issue exists any
more. Please describe the conditions where the problem occurs.
If the "binddn" is provided, everything works as expected,
with the only minor
issue that the DN of the user as it is known to back-meta may not match the
actual identity the "authcID" assumed on the remote server. The
"right" way to
address this problem consists in performing a "WhoAmI" (RFC 4532) right after
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/