[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: (ITS#6817) idassert-bind with SASL issues
masarati@aero.polimi.it wrote:
>> masarati@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.
>
> 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).
Using a dummy DN here sounds OK.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/