Re: LDAP where DN does not include UID attribute
| От | Robert Fleming |
|---|---|
| Тема | Re: LDAP where DN does not include UID attribute |
| Дата | |
| Msg-id | 4c0112730909141647s16717480j34add672d0a3e607@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: LDAP where DN does not include UID attribute (Tom Lane <tgl@sss.pgh.pa.us>) |
| Ответы |
Re: LDAP where DN does not include UID attribute
|
| Список | pgsql-admin |
On Mon, Sep 14, 2009 at 4:23 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
That's just the way the company LDAP is setup -- it's out of my control unfortunately.
Our schema used to have the uid in the DN, and I always wrote our enterprise software to just do the bind without a search. When the LDAP schema changed, my reaction was the same as yours, but when I saw that Bugzilla, MediaWiki, etc. accommodate it without flinching, I figured it wasn't too uncommon, so I changed my own software. Other software that supports it: Tiki wiki, Apache's mod_authnz_ldap, ejabberd. I think I had to tweak some Perl for jabberd <jabberd.org> to handle it.
It might be twice as slow, but if PostgreSQL were smart or configurable enough, it could skip the search when not necessary. So performance needn't be impacted.
Robert
Robert Fleming <fleminra@gmail.com> writes:What value does that have that would justify doubling the time needed
> But I would like to authenticate to PostgreSQL using the "uid" LDAP
> attribute,
to authenticate? (I presume two LDAP requests will take about twice
as long as one...)
That's just the way the company LDAP is setup -- it's out of my control unfortunately.
Our schema used to have the uid in the DN, and I always wrote our enterprise software to just do the bind without a search. When the LDAP schema changed, my reaction was the same as yours, but when I saw that Bugzilla, MediaWiki, etc. accommodate it without flinching, I figured it wasn't too uncommon, so I changed my own software. Other software that supports it: Tiki wiki, Apache's mod_authnz_ldap, ejabberd. I think I had to tweak some Perl for jabberd <jabberd.org> to handle it.
It might be twice as slow, but if PostgreSQL were smart or configurable enough, it could skip the search when not necessary. So performance needn't be impacted.
Robert
В списке pgsql-admin по дате отправления: