Thanks again, everyone, for all the responses and ideas. I'm still getting caught up on the various responses but with
respectto LDAP/AD, I truly wish it were an option. I agree with the various sentiments that AD authentication is more
manageable,scalable, secure, etc. However, if there were one set of environs where you'd think we could rely
exclusivelyon AD authentication, it would be SQL Server, which by default, relies on Windows & AD for its
authentication. However, for our company, even in our SQL Server environments, we almost always have to resort to
internal(SQL-authenticated) accounts at times for various reasons: usually because vendor software doesn't support AD
authentication,but I've even heard some people mention docker containers can't use it, either. Full disclosure - I
haven'trun that last one down yet, have only heard it in passing so don't know the details.
Christian's idea of fail2ban looks interesting, so I'm going to be investigating that.
Thanks again, all of you. Really appreciate the feedback and ideas!
Ken
-----Original Message-----
From: Stephen Frost <sfrost@snowman.net>
Sent: Wednesday, May 06, 2020 7:28 AM
To: Geoff Winkless <pgsqladmin@geoff.dj>
Cc: Tim Cross <theophilusx@gmail.com>; pgsql-generallists.postgresql.org <pgsql-general@lists.postgresql.org>
Subject: EXTERNAL: Re: Lock Postgres account after X number of failed logins?
Greetings,
* Geoff Winkless (pgsqladmin@geoff.dj) wrote:
> On Wed, 6 May 2020 at 00:05, Tim Cross <theophilusx@gmail.com> wrote:
> > Where Tom's solution fails is with smaller companies that cannot
> > afford this level of infrastructure.
>
> Is there an objection to openldap? It's lightweight (so could
> reasonably be run on the same hardware without significant impact),
> BSD-ish and mature, and (with the password policy overlay) should
> provide exactly the functionality the OP requested.
LDAP-based authentication in PG involves passing the user's password to the database server in the clear (or tunneled
throughSSL, but that doesn't help if the DB is compromised), so it's really not a good solution.
Thanks,
Stephen