On Wed, Jan 6, 2021 at 4:39 PM Paul Förster <paul.foerster@xxxxxxxxx> wrote: > > Hi Magnus, > > > On 06. Jan, 2021, at 15:48, Magnus Hagander <magnus@xxxxxxxxxxxx> wrote: > > > > Only if you can create rules in your pg_hba.conf file that knows where > > the users are. You can specify multiple servers on one line, but that > > only balances across servers that don't work. If a server replies "no" > > to a response, PostgreSQL will not move on to the next one. So you > > have to make it initially pick the correct rule. > > that unfortunately is not an option, partly because LDAP and AD use different options and also, as you already mentioned it, if one server says no, it's no. > > > And what would you do if user5 exists in both the two ldap servers? > > that wouldn't matter as long as user5 exists on the database and can be authenticated by either LDAP. > > > One hacky way you could do it is create a group role for each server, > > maintained by some cron job, that indicates with LDAP server the user > > is on. You can then use group matching to pick the correct rule in > > pg_hba. It's kind of an ugly hack though.. > > that sounds really hacky. ;-) Yes. But you have a really hacky environment :P > > You'd probably be better off to have a federated ldap server that has > > a view of both servers, and use that. > > can't do that either. I have no control over both LDAP services. PostgreSQL is just a consumer and I can't make any of the two LDAPs to sync onto each other. You could have a third LDAP instance that federates the other two. Another option could be to proxy it through something like FreeRADIUS. I'm fairly certain it can also move on to a secondary server if the first one reports login failure. > > Or even better, since one of your nodes is AD, it speaks Kerberos. > > Setting up a Kerberos trust between the two environments would make it > > possible to do things like regexp matching on the realm in > > pg_ident.conf, and as a bonus you get Kerberos which is a lot more > > secure than ldap for auth.. It might have a slightly higher barrier > > of entry, but could probably pay off well in a case like this. > > that'd require me to recompile and redistribute the PostgreSQL software. I only have openLDAP compiled into it but no GSSAPI. While this could be possible, it would also mean service interruption, almost not possible in a 24x7 environment. Also, and I'm no expert on this, it would require me to get certificates and configure them, and so on, right? I assume you're not using any of the standard packagings then, as I believe they all come with support for GSSAPI. Yet another reason why it's a good idea to use that :) And no, gssapi does not use certificates. > I thought of a pg_ident.conf configuration. In fact, it's more of a prefix change. The complete situation is like this: > > ldap1 knows aaa-u1, aaa-u2, and so on > ldap2 knows bbb-u1, bbb-u2, and so on > > So, I thought, I could create a pg_ident.conf like this: > > mymap /^aaa-(.*)$ bbb-\1 > > Then pg_ctl reload of course. But that doesn't seem to work. Maybe I'm trying something wrong here. pg_ident only works for authentication methods where the username comes from the other system, such as with Kerberos. It does not work for LDAP, where the username is specified in PostgreSQL. -- Magnus Hagander Me: https://www.hagander.net/ Work: https://www.redpill-linpro.com/
