ldap stronger authentication required error after upgrade

[Aaron Solochek]

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.


>> 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.

-Aaron