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
|
Список | 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 по дате отправления: