Re: LDAP Login Problem
| От | Tom Robst |
|---|---|
| Тема | Re: LDAP Login Problem |
| Дата | |
| Msg-id | 4B8E8072.1080309@thermocable.com обсуждение исходный текст |
| Ответ на | Re: LDAP Login Problem (Magnus Hagander <magnus@hagander.net>) |
| Список | 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 по дате отправления: