ldap stronger authentication required error after upgrade

[Andrew Bartlett]

On Thu, 2011-01-13 at 11:55 -0500, Aaron Solochek wrote:
> On 01/08/2011 12:41 AM, Andrew Bartlett wrote:
> > On Fri, 2011-01-07 at 20:02 -0500, Aaron Solochek wrote:
> >> On 01/07/2011 06:51 PM, Brad Hards wrote:
> >>> On Saturday, January 08, 2011 10:29:01 am Aaron Solochek wrote:
> >>>> So what changed that would cause this, and how to fix it?  I have a wiki
> >>>> that was authenticating against ldap, and now no one can log in.
> >>> It might have been easier to tell if you could have described which version 
> >>> worked and which version didn't, but you're probably using an anonymous bind, 
> >>> which isn't allowed in more recent samba versions. 
> >>>
> >>> To fix it, authenticate the ldap bind.
> >>>
> >>
> >> No, it's not an anonymous bind, I'm authenticating as an admin.
> >>
> >> The version that worked was, I believe
> >>
> >> 4.0.0~alpha14~bzr14682~ppa170+191~maverick1
> >>
> >> The version that doesn't is
> >>
> >> 4.0.0~alpha14~bzr15953~ppa174+199~maverick
> > 
> > Sadly those versions don't mean anything.  We will need the GIT hashes
> > to be able to line these up to dates.  
> > 
> > However, I think you should confirm with a network capture that you are
> > not doing any searches or other operations before that administrative
> > bind.  These will now be rejected as they are anonymous. 
> > 
> > Andrew Bartlett
> > 
> 
> Ok, getting back to this.  I again pulled in the latest from git, and using
> luma, attempted to browse ldap.  I am biding as aarons at foo.com, no encryption,
> simple authentication.
> 
> I open up the browser and see:
> 
> CN=Configuration,DC=foo,DC=com
> CN=Schema,CN=Configuration,DC=foo,DC=com
> DC=foo,DC=com
> 
> I test and can successfully expand the Schema.  I attempt to expand the last
> entry in that list, and I get the error "Could not check if object is a leaf in
> the ldap tree.  Reason: {'info': '00002020: Operations error - Operation
> unavailable without authentication', 'desc': 'Operations error'}"
> 
> This is a dump of the LDAP traffic I saw:

See the difference between:

> 10.1.10.25  10.1.10.10  LDAP  106    bindRequest(1) "aarons at foo.com" simple
> 10.1.10.10  10.1.10.25  LDAP  80     bindResponse(1) success
> 10.1.10.25  10.1.10.10  LDAP  121    searchRequest(2) "<ROOT>" baseObject
> 10.1.10.10  10.1.10.25  LDAP  220    searchResEntry(2) "<ROOT>"  |
> searchResDone(2) success

and

> 10.1.10.25  10.1.10.10  LDAP  80     bindRequest(4) "<ROOT>" simple
> 10.1.10.10  10.1.10.25  LDAP  80     bindResponse(4) success
> 10.1.10.25  10.1.10.10  LDAP  158    searchRequest(3)
> "CN=Configuration,DC=foo,DC=com" baseObject
> 
> 10.1.10.10  10.1.10.25  LDAP  153    searchResDone(3) operationsError (00002020:
> Operations error - Operation unavailable without authentication)

> So I see that it does return some results after the second search request, but
> even using a different ldap browser, jxplorer, I'm getting the same behavior.
> 
> It seems these clients are expecting some slightly different LDAP behavior than
> the recent samba4 is exhibiting.  I know for sure that luma used to work for
> with samba4 ldap.

Yes, we changed the default anonymous access behaviour.  Many other LDAP
servers allow anonymous access in their default configuration
(particularly in unix environments, as these typcially do not have a
good way to have machines authenticate, and so need anonymous access to
bootstrap). 

> Next steps to debug this?

The problem looks like that in the second search, the bind isn't for a
username, and so is anonymous.  Can you confirm this isn't an error in
the way you have provided the trace?

Andrew Bartlett

-- 
Andrew Bartlett                                http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org
Samba Developer, Cisco Inc.