[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/