On Tue, Jan 28, 2020 at 3:56 AM PG Bug reporting form
<noreply@postgresql.org> wrote:
> The following bug has been logged on the website:
>
> Bug reference: 16234
> Logged by: Sujith kumar
> Email address: sujiplr@gmail.com
> PostgreSQL version: 9.5.20
> Operating system: RHEL 7.7
> Description:
>
> Hi Team,
>
> 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?
Hi Sujith,
This isn't a bug report, it's a question, so it belongs on the
pgsql-general mailing list, not the pgsql-bugs mailing list (which
you've reached via the bug reporting form).
But since I'm here: I don't think you can do that with the built-in
LDAP support. It does allow for multiple hostnames, but it doesn't
allow for different binding users. Later PostgreSQL release added
some more flexibility, but still not that. Furthermore, pg_hba.conf
doesn't have a way to consider multiple lines (it can't try one line,
then try a second line if that fails, ..., it only tries the first
matching line and if it fails, it's game over).
One approach would be to use PostgreSQL's PAM authentication mode
instead. PAM does have non-terminating "sufficient" rules (only one
needs to succeed). You'd need a pg_hba.conf line that says "ask PAM,
my service name is postgresql", and then a file /etc/pam.d/postgresql
that has something like (completely untested, just guessing here):
auth sufficient pam_ldap.so config=/path/first-ldap.conf
auth sufficient pam_ldap.so config=/path/second-ldap.conf
account required pam_permit.so
The referenced config files could contain different binddn lines and
whatever else you need. I don't know the details (see man pam_ldap).
Or perhaps you could use pam_exec.so instead, and point it at a Turing
machine of your own design that says yes or no, though it's probably
better to stick to ready-made solutions for authentication where
possible.
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.