masarati(a)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.

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/