BUG #9818: LDAP Authentication subtree problem

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á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

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=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.

--
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 [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)

Thanks for feed-back!
Best regards, Jasan

--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/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!

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&amp;sektion=3&amp;apropos=0&amp;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&amp;apropos=0&amp;sektion=3&amp;manpath=OpenLDAP+2.0-Release&amp;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/