Re: 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=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/