[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: (ITS#6817) idassert-bind with SASL issues

masarati@aero.polimi.it wrote:
> Full_Name: Pierangelo Masarati
> Version: HEAD/re24
> OS: irrelevant
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (
> 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/