> masarati(a)aero.polimi.it 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
>> provided, while the "binddn" is not needed. However, if a
>> 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.
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.