ldap stronger authentication required error after upgrade

[Andrew Bartlett]

On Thu, 2011-01-13 at 15:34 -0500, Aaron Solochek wrote:
> On 01/13/2011 03:20 PM, Andrew Bartlett wrote:
> > 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). 
> 
> Ok, so how to explicitly configure the default access behavior so it acts like
> it did before?  I'm using LDAP to authenticate users to a mediawiki, and that no
> longer works.

Can't you just configure it per the instructions at http://www.mediawiki.org/wiki/Extension:LDAP_Authentication/Options#Proxied_or_search_based_bind_options

ie, configure it like a real AD server, and it should just work.  

Otherwise, see the http://support.microsoft.com/kb/326690 for how
dsHuristics works (we honour this). 

> >> 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?
> 
> Yes, this is not an error.  All three client cases I've tested (the two
> previously mentioned + mediawiki) attempt an anonymous bind at some point, and
> that is what fails.

If the clients don't bind with a username (which clearly they have been
told, because it has used it in the previous bind), then they will be
denied.  This appears to be a client bug, unless you can show it's
somehow different when used against Microsoft's implementation.
(Perhaps we get an error code wrong, so a fallback doesn't happen). 

Andrew Bartlett

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