ldap stronger authentication required error after upgrade

Thu Jan 13 15:15:05 MST 2011

On 01/13/2011 04:05 PM, Andrew Bartlett wrote:
> 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). 

Ok, that looked like the "right" solution so I tried it and it works.  Thanks.

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

I did notice that the error code samba was sending changed between whatever
alpha14 version I had a deb of, and the git master.  It used to be 0208 I
believe, and now it's 0202.  That is just an aside, because I still wasn't able
to use luma either way.

Anyway, I tried luma, gq, and jxplorer.  None of them seem to be able to talk to
the samba4 ldap server.  Of course, even with dsHuristics set gq and jxplorer
seem pretty buggy, so I guess it might be that all the clients are broken.

Thanks again for the help.  That's one off my list.

-Aaron