Re: BUG #9818: LDAP Authentication subtree problem

(Sorry for getting back to this so late)

On Tue, Apr 22, 2014 at 6:33 AM, Sáreník Ján <jan(dot)sarenik(at)generali(dot)com>wrote:

> Hello Magnus!
>
> On Tue, Apr 18, 2014 at 3:51 PM, Magnus Hagander wrote:
> > That page is about about the ModifyObject() function, which we're
> > definitely not calling. And it's under the section about DFS replication
> > helper protocol. So either you posted the wrong URL, or you have
> > misdiagnosed it.
>
> Yes, I might have misdiagnosed it, but it was the closest match possible.
>

I think it is completely wrong actually. It may have a similar error
message, but that's like "file not found" being completely different things
depending on how you use it.

> Do you get anythign in the AD controller logs at this time? Or if
> > you can get a packet trace, does it show something clear about what's
> > actually going wrong?
>
> No, as AD is managed by another part of the company and there are no
> issues using Apache2 or ldapsearch against it, so I do not assume
> the problem resides on that side.
>

Wel, there might be a hint in the logs as to what went wrong.

When you are doing it with apache, are you using exactly the same user
(both for the search user through ldapbinddn and the actual user you are
logging in with)?

>
> > I wonder if it might be related to the use of an LDAP url, that somehow
> > gets the subtree search wrong. Can you check to see if it works if
> > you specify the individual parts without using an url, e.g.
> >
> > local all all ldap
> > ldapserver=aa00aaa001.aaaa.corp.local
> > ldapbasedn=DC=aaaa,DC=corp,DC=local ldapsearchattribute=sAMAccountName
> >
> ldapbinddn="CN=svcLDAPDWH,OU=Services,OU=UsersAdm,DC=aaaa,DC=corp,DC=local"
> > ldapbindpasswd="XXXXXX"
> >
> > For ldap auth not using the url syntax, subtree search is always used.
>
> I tried this on today's unpatched PostgreSQL (8d34f6862) and it does
> not work. It gives me the same error like when I use ldapurl in
> pg_hba.conf.
> Just note that I had to quote ldapbasedn's parameter - otherwise the
> database server wouldn't start.
>

That's kind of weird though. Even though you don't have any spaces on it?
What error message did you get when trying to start it?

As for the packets:
> 1. bindRequest(1) "CN=svcLDAPDWH,OU=Services,OU=UsersAdm,..."
> 2. bindResponse(1) success
> 3. searchRequest(2) "DC=aaaa,DC=corp,DC=local" wholeSubtree
> 4. searchResEntry(2) "CN=T912348,OU=UsersW7,DC=gpcz,DC=corp,DC=local" |
> searchResRef(2) | searchResDone(2) success [1 result]
> ----------------------------------------------------
>
> Then the two (patched and unpatched) start to diverge:
> Patched:
> ----------------------------------------------------
> 5. unbindRequest(6)
> 6. bindRequest(1) "CN=user,OU=subgroup,..." simple
> 7. bindResponse(1) success
> 8. unbindRequest(2)
> Unpatched:
> ----------------------------------------------------
> 5. bindRequest(4) "<ROOT>" simple
> 6. bindResponse(4) success
> 7. searchRequest(3) "DC=DomainDnsZones,DC=aaaa,..." wholeSubTree
> 8. searchResDone(3) operationsError (000004DC: LdapErr: DSID-0C0906E8,
> comment: In order to perform this operation a successful bind must be
> completed on the connection., data 0, v1db1) [0 results]
> 9. unbindRequest(5)
>
>
Well, that's indicative of you ignoring the error in the patched version.

That said, the thing you have under 7 certainly must be completely
unrelated. That's seraching for DNS stuff, that's not specified anywher ein
your configuration. I think that's something that's coming out of a
background process somewhere. In fact, I think all of the steps 5-9 under
"unpatched" are completely unrelated. If you run it multiple itmes, do they
really show up every time?

AFAICT, under step 4 it returns success on the search. But then the API
actually returns failure.

There's something strange going on though. When you look at
http://www.openldap.org/software/man.cgi?query=ldap_error&sektion=3&apropos=0&manpath=OpenLDAP+2.0-Releaseit
says you have to ldap_result2error() to get the error. Even though
http://www.openldap.org/software/man.cgi?query=ldap_search&apropos=0&sektion=3&manpath=OpenLDAP+2.0-Release&format=htmlsays
it already returns the error code.

Try something like the attached patch to see if it gives us more data.

--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/