[Date Prev][Date Next]
Re: (ITS#6817) idassert-bind with SASL issues
> email@example.com wrote:
>> Full_Name: Pierangelo Masarati
>> Version: HEAD/re24
>> OS: irrelevant
>> URL: ftp://ftp.openldap.org/incoming/
>> Submission from: (NULL) (18.104.22.168)
>> 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 "binddn" is
>> 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.
> Also with the fixes that I made for #6711 I don't believe the issue exists
> more. Please describe the conditions where the problem occurs.
At the time I looked at this issue, there were places in the code where
after an idassert-bind the lc_bound_ndn would receive a copy of idassert's
authcDN. In case of SASL, this is empty/null; then back-ldap (and meta)
would fail from recognizing the connection as successfully bound. I
understand there are better solutions; for example, ldapconn_t could have
a "bound" flag, or so. I understand that code may need some reworking,
but I can't work at that now, sorry. p.
>> 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 "right"
>> 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/