Обсуждение: BUG #9818: LDAP Authentication subtree problem
The following bug has been logged on the website: Bug reference: 9818 Logged by: Ján SárenÃk Email address: jan.sarenik@generali.cz PostgreSQL version: Unsupported/Unknown Operating system: CentOS 6.5 Description: Hello! Following line is my only record in pg_hba.conf: local all all ldap ldapurl="ldap://aa00aaa001.aaaa.corp.local/DC=aaaa,DC=corp,DC=local?sAMAccountName?sub" ldapbinddn="CN=svcLDAPDWH,OU=Services,OU=UsersAdm,DC=aaaa,DC=corp,DC=local" ldapbindpasswd="XXXXXX" LDAP server is Microsoft Active Directory. I am testing on 554bb3beba27bf4a49edecc40f6c0f249974bc7c (today's git tree) Version of OpenLDAP does not influence it (I have linked it with current release, no change). All I want in the end is to log into postgres as both of following users CN=A000001,OU=UsersW7,DC=gpcz,DC=corp,DC=local CN=A000002,OU=UsersStd,DC=gpcz,DC=corp,DC=local Instead all I am getting is: LOG: could not search LDAP for filter "(CN=A000001)" on server "aa00aaa001.aaaa.corp.local": Operations error LOG: could not search LDAP for filter "(CN=A000002)" on server "aa00aaa001.aaaa.corp.local": Operations error If I specify ldapurl to contain OU=UsersW7, I can log in as A000001 but not A000002 (and vice versa). The only work around I was able to do so far is following, based on the idea that LDAP_OPERATIONS_ERROR produced by MS AD server is misleading. See end of http://msdn.microsoft.com/en-us/library/dd303696.aspx Thanks, Ján diff --git a/src/backend/libpq/auth.c b/src/backend/libpq/auth.c index 31ade0b..75255dd 100644 --- a/src/backend/libpq/auth.c +++ b/src/backend/libpq/auth.c @@ -2007,7 +2007,7 @@ CheckLDAPAuth(Port *port) 0, &search_message); - if (r != LDAP_SUCCESS) + if (r != LDAP_SUCCESS && r != LDAP_OPERATIONS_ERROR) { ereport(LOG, (errmsg("could not search LDAP for filter \"%s\" on server \"%s\": %s",
On Tue, Apr 1, 2014 at 4:19 PM, <jan.sarenik@generali.cz> wrote: > The following bug has been logged on the website: > > Bug reference: 9818 > Logged by: J=C3=A1n S=C3=A1ren=C3=ADk > Email address: jan.sarenik@generali.cz > PostgreSQL version: Unsupported/Unknown > Operating system: CentOS 6.5 > Description: > > Hello! > > Following line is my only record in pg_hba.conf: > local all all ldap > > ldapurl=3D"ldap://aa00aaa001.aaaa.corp.local/DC=3Daaaa,DC=3Dcorp,DC=3Dloc= al?sAMAccountName?sub" > ldapbinddn=3D"CN=3DsvcLDAPDWH,OU=3DServices,OU=3DUsersAdm,DC=3Daaaa,DC=3D= corp,DC=3Dlocal" > ldapbindpasswd=3D"XXXXXX" > > LDAP server is Microsoft Active Directory. > I am testing on 554bb3beba27bf4a49edecc40f6c0f249974bc7c (today's git tre= e) > Version of OpenLDAP does not influence it (I have linked it with current > release, no change). > All I want in the end is to log into postgres as both of following users > > CN=3DA000001,OU=3DUsersW7,DC=3Dgpcz,DC=3Dcorp,DC=3Dlocal > CN=3DA000002,OU=3DUsersStd,DC=3Dgpcz,DC=3Dcorp,DC=3Dlocal > > Instead all I am getting is: > LOG: could not search LDAP for filter "(CN=3DA000001)" on server > "aa00aaa001.aaaa.corp.local": Operations error > LOG: could not search LDAP for filter "(CN=3DA000002)" on server > "aa00aaa001.aaaa.corp.local": Operations error > > If I specify ldapurl to contain OU=3DUsersW7, I can log in as A000001 > but not A000002 (and vice versa). > > The only work around I was able to do so far is following, based > on the idea that LDAP_OPERATIONS_ERROR produced by MS AD server > is misleading. See end of > http://msdn.microsoft.com/en-us/library/dd303696.aspx 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. 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? 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=3Daa00aaa001.aaaa.corp.local ldapbasedn=3DDC=3Daaaa,DC=3Dcorp,DC= =3Dlocal ldapsearchattribute=3DsAMAccountName ldapbinddn=3D"CN=3DsvcLDAPDWH,OU=3DServices,OU=3DUsersAdm,DC=3Daaaa,DC=3Dco= rp,DC=3Dlocal" ldapbindpasswd=3D"XXXXXX" For ldap auth not using the url syntax, subtree search is always used. --=20 Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/
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. > 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. > 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. 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 [1result] ---------------------------------------------------- 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 successfulbind must be completed on the connection., data 0, v1db1) [0 results] 9. unbindRequest(5) Thanks for feed-back! Best regards, Jasan
(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/