ldap stronger authentication required error after upgrade
Aaron Solochek
aarons-samba at aberrant.org
Thu Jan 13 09:55:40 MST 2011
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
More information about the samba-technical
mailing list