On 11/6/04 6:44 am, Quanah Gibson-Mount <[EMAIL PROTECTED]> wrote: > > > --On Friday, June 11, 2004 6:36 AM +0100 Chris Ridd <[EMAIL PROTECTED]> > wrote: > >> This isn't really a bug, as LDAP does require a DN to be passed in all >> forms of bind operation. RFC 2251: >> >> ---- >> - name: The name of the directory object that the client wishes to >> bind as. This field may take on a null value (a zero length >> string) for the purposes of anonymous binds, when authentication >> has been performed at a lower layer, or when using SASL credentials >> with a mechanism that includes the LDAPDN in the credentials. >> ---- >> >> So it technically makes sense if you're doing a SASL bind, even if most >> mechanisms will ignore it. >> >> The fact they ignore it means you could very simply pass "", as you're >> doing with the ldapsearch tool. > > I'm going to be a little more clear here, since you just exactly made my > point: > > Net::LDAP *fails* to ignore the bind dn. Net::LDAP *REQUIRES* that the > Bind DN *BE* your real BIND DN or the BIND fails. I'm not trying to bind > to the server *without* a bind DN, I'm trying to bind to the server > *without a valid* DN. > > *That* is a bug, and a failure to meet RFC 2251.
You're confusing a syntactically valid DN with the DN being appropriate for the user. OK, I understand what you're saying now. > What I get back from Net::LDAP when I use a SASL bind with an invalid DN is: > > ./sasl-notwork.pl > SASL(-14): authorization failure: not authorized at ./sasl-notwork.pl line > 15, <DATA> line 283. Does this happen with other mechanisms, and with the latest versions of Net::LDAP/Authen::SASL? As far as I can see the current Net::LDAP::bind code doesn't do much with the supplied DN except hand it down (inside %stash) to the SASL code. You could try setting $ldap->debug(12) before the bind to see exactly what goes across the wire to your directory server, and how it differs when you change the DN. Cheers, Chris
