ldap stronger authentication required error after upgrade
Andrew Bartlett
abartlet at samba.org
Thu Jan 13 14:05:19 MST 2011
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.
More information about the samba-technical
mailing list