Re: LDAP Login Problem - Mailing list pgsql-general

From Tom Robst
Subject Re: LDAP Login Problem
Date
Msg-id 4B8E8072.1080309@thermocable.com
Whole thread Raw
In response to Re: LDAP Login Problem  (Magnus Hagander <magnus@hagander.net>)
List pgsql-general
Thanks Magnus. I should have mentioned I'm using OpenLDAP 2.2. I guess
I'll just have to wait for Postgres 9 and workaround it in the meantime.
It's not an insurmountable issue...

Regards,
Tom Robst
--

On 03/03/10 15:18, Magnus Hagander wrote:
> 2010/3/3 Tom Robst<tomrobst@thermocable.com>:
>> Hi,
>>
>> I am having a problem with authentication using LDAP on PostgreSQL 8.4.2.
>>
>> The problem seems to be limited to which attribute is specified in the ldapprefix. If I specify "uid=" and then try
loginusing the username "trobst" (which is the value in the ldap db) I get an error: 
>>
>> host    all         all         192.168.1.0/24        ldap ldapserver=ldap.thermocable.com ldapprefix="uid="
ldapsuffix=",cn=Staff,dc=thermocable,dc=com"
>>
>> LOG:  LDAP login failed for user
>> "uid=trobst,cn=Staff,dc=thermocable,dc=com" on server
>> "ldap.thermocable.com": error code 49
>> FATAL:  LDAP authentication failed for user "trobst"
>>
>> However if I specify the ldapprefix to be "cn=" and login using the username "Tom Robst" it all works fine.
>>
>> host    all         all         192.168.1.0/24        ldap ldapserver=ldap.thermocable.com ldapprefix="cn="
ldapsuffix=",cn=Staff,dc=thermocable,dc=com"
>
> The LDAP authentication needs to bind with the full DN, which is
> "cn=...". Specifying uid= doesn't make it a valid LDAP distinguished
> name. So unless your LDAP server is "tricky" (like the Microsoft one,
> which accepts both DN and "DOMAIN\username" in the login packet),
> there's nothing you can do I think. (well, you can also change all
> your DNs in the LDAP catalog, but that's likely to break a lot of
> other things)
>
> PostgreSQL 9.0 will allow you do do a search+bind to get the
> functionality you want. The change should be fairly standalone so you
> could probably have it backpatched if it's urgent for you, but since
> it's a new feature it's not something the community backpatches.
>

pgsql-general by date:

Previous
From: Tom Lane
Date:
Subject: Re: bug in function arguments "recognition"
Next
From: Ivan Sergio Borgonovo
Date:
Subject: Re: bug in function arguments "recognition"