ldap stronger authentication required error after upgrade

[Aaron Solochek]

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:

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

10.1.10.25  10.1.10.10  LDAP  73     unbindRequest(3)
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  168    searchRequest(2)
"CN=Schema,CN=Configuration,DC=foo,DC=com" singleLevel

10.1.10.10  10.1.10.25  LDAP  1240   searchResEntry(2)
"CN=Instance-Type,CN=Schema,CN=Configuration,DC=foo,DC=com"

... (many lines of schema response omitted)

10.1.10.25  10.1.10.10  LDAP  73     unbindRequest(3)
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  141    searchRequest(2) "DC=foo,DC=com" singleLevel

10.1.10.10  10.1.10.25  LDAP  1312   searchResEntry(2) "CN=Users,DC=foo,DC=com"
 | searchResEntry(2) "CN=Computers,DC=foo,DC=com"  | searchResEntry(2)
"CN=Builtin,DC=foo,DC=com"  | searchResEntry(2) "OU=Domain
Controllers,DC=foo,DC=com"  | searchResEntry(2)
"CN=ForeignSecurityPrincipals,DC=foo,DC=com"  | searchResEntry(2)
"CN=Infrastructure,DC=foo,DC=com"  | searchResEntry(2)
"CN=LostAndFound,DC=foo,DC=com"  | searchResEntry(2) "CN=NTDS
Quotas,DC=foo,DC=com"  | searchResEntry(2) "CN=Program Data,DC=foo,DC=com"  |
searchResEntry(2) "CN=System,DC=foo,DC=com"  | searchResEntry(2)
"OU=People,DC=foo,DC=com"  | searchResEntry(2)
"CN=defaultMigrationContainer30,DC=foo,DC=com"  | searchResEntry(2)
"OU=ma,DC=foo,DC=com"  | searchResEntry(2) "OU=ca,DC=foo,DC=com"  |
searchResRef(2)  | searchResDone(2) success

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)

10.1.10.25  10.1.10.10  LDAP  73     unbindRequest(5)
10.1.10.25  10.1.10.10  LDAP  73     unbindRequest(6)

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.


Next steps to debug this?

-Aaron