Re: BUG #9818: LDAP Authentication subtree problem - Mailing list pgsql-bugs
| From | Magnus Hagander |
|---|---|
| Subject | Re: BUG #9818: LDAP Authentication subtree problem |
| Date | |
| Msg-id | CABUevEy78u9wYFXqiij6VmrQO2EuOG1KPwaybWfANQE=DxELrQ@mail.gmail.com Whole thread Raw |
| In response to | Re: BUG #9818: LDAP Authentication subtree problem (Sáreník Ján <jan.sarenik@generali.com>) |
| List | pgsql-bugs |
(Sorry for getting back to this so late)
On Tue, Apr 22, 2014 at 6:33 AM, Sáreník Ján <jan.sarenik@generali.com> wrote:
Hello Magnus!Yes, I might have misdiagnosed it, but it was the closest match possible.
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.
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 ifNo, as AD is managed by another part of the company and there are no
> you can get a packet trace, does it show something clear about what's
> actually going wrong?
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 tried this on today's unpatched PostgreSQL (8d34f6862) and it does
> 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.
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-Release it 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=html says 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/
Attachment
pgsql-bugs by date: