Re: BUG #16234: LDAP Query

Поиск
Список
Период
Сортировка
От Stephen Frost
Тема Re: BUG #16234: LDAP Query
Дата
Msg-id 20200205120712.GV3195@tamriel.snowman.net
обсуждение исходный текст
Ответ на BUG #16234: LDAP Query  (PG Bug reporting form <noreply@postgresql.org>)
Ответы RE: BUG #16234: LDAP Query  ("Albin, Lloyd P" <lalbin@scharp.org>)
Список pgsql-bugs
* PG Bug reporting form (noreply@postgresql.org) wrote:
> I have a requirement to do authentication through LDAP, the LDAP query
> should go to two different LDAP servers with dedicated binding users (
> different for two LDAP servers) , if the user is not available in first LDAP
> then it should check in second LDAP. But here as per hba file , it won't
> work in this model ( If there is no successful search in first hope, it will
> throw error).
>
> So we have to do multiple query in the LDAP query string, how we can do
> this?

What kind of setup is this, that you have two LDAP servers involved..?
That's certainly not a common setup that I've seen..

If what you actually have are two different Active Directory domains and
you want users to be able to authenticate from either one, then you
would typically place the PG server in one of them and then create a
cross-realm trust between the two AD realms, so that users can gain
access to resources in the other realm.

In other words, if you have:

- ABC.COM realm
- XYZ.COM realm

and your users exist in ABC.COM, and your PG server is in XYZ.COM, then
you'd need a cross-realm trust, whereby XYZ.COM will trust the users
being presented from ABC.COM.  You can also enable the cross-realm trust
in the other direction, if you want.  Of course, users in XYZ.COM will
already be able to authenticate to the PG server in the same realm.

Note that the approach outlined above, and in general the better
approach to use here, does *not* use LDAP; if you're in an environment
like Active Directory which supports kerberos/GSS natively, and
configure PG to use GSS.

* Thomas Munro (thomas.munro@gmail.com) wrote:
> Standard free warning: whenever using LDAP, be aware of cleartext
> passwords visible to everyone on your network if you don't use
> SSL/TLS, even if you are using SSL for the connection between client
> and PostgreSQL.

Further- no matter what you do, if you're using LDAP for auth with PG,
the PG server will see the user's password, in cleartext, meaning that
if the PG server is ever compromised, every user who logs into it after
that will have their full network credentials stolen.  The same is true
with the PAM solution presented earlier.  Basically, don't do it, it's
not secure.

Thanks,

Stephen

Вложения

В списке pgsql-bugs по дате отправления:

Предыдущее
От: Thomas Butz
Дата:
Сообщение: Re: BUG #16241: Degraded hash join performance
Следующее
От: "David G. Johnston"
Дата:
Сообщение: Re: BUG #16244: Ref cursor from PostgreSQL and entity Framework