Re: [SOLVED] Re: pgAdmin 4 + python wheel + kerberos

Hi

On Thu, May 7, 2020 at 3:52 PM Stephen Frost <sfrost(at)snowman(dot)net> wrote:

> Greetings,
>
> * Dave Page (dpage(at)pgadmin(dot)org) wrote:
> > On Wed, May 6, 2020 at 5:20 PM Stephen Frost <sfrost(at)snowman(dot)net> wrote:
> > > Any chance you could share that patch..? Considering that pgAdmin4
> has,
> > > sadly, decided to go the (broken) route of adding LDAP basic-user auth,
> >
> > Less secure != broken, unless you know something I don't (and bear in
> mind
> > I've seen your talk on the subject :-p )
>
> You could make the same distinction and argument when talking about
> NTLM, LANMAN, or even hash algorithms like MD5. There's good reasons
> for why Microsoft moved away from NTLM and why all of their applications
> use Kerberos and explicitly not LDAP-simple-bind for authentication.
>

I'm not saying it's the best option or anything close, simply that it's not
broken in the dictionary sense of the word.

>
> > LDAP was added as the first option whilst adding support for pluggable
> > authentication mechanisms, partly because it's the one we're most
> > familiar with, and partly because it's by far the most common option
> > requested by users (and yes, whilst like you I would love to be able to
> > tell them all to just use Kerberos, we both know that's not realistic).
>
> The most requested, in my experience at least, isn't LDAP- it's Active
> Directory integration, with an expectation that it'll work in the same,
> secure, way that SQL Server integrates into AD. That's not what any of
> this is though- and we see people being confused and making incorrect
> assumptions about what the LDAP support in PG is already, and I'm sure
> they'll also be confused with pgAdmin4.
>
> This is something that comes up too, and not even that long ago-
>
>
> https://www.postgresql.org/message-id/flat/16079-29e9c038e1463751%40postgresql.org

Maybe that person is confused (and certainly some others are), but I don't
see anything in that particular message to indicate they're using AD. For
all I can see they're using OpenLDAP or 389-ds.

Regardless; it's clearly not feasible for us to persuade every user of
non-AD LDAP to stop doing so.

>
>
> The poster even claims that with ldap auth: "But the user credentials
> will not be sent to Postgresql server to authenticate", which is clearly
> wrong.
>

Yeah, definitely.

>
> > > it'd really be good to, out of the box, make it support Kerberos-based
> > > auth, even with the limitations you've described here.
> >
> > We already have a Kerberos module on our plan to follow on from the LDAP
> > one. Following that we plan to also add support for Kerberos
> authentication
> > to the database servers themselves.
>
> Glad to hear it, I'd be happy to help with Kerberos auth support.
> Sounds like it's actually rather easy to implement it, based on Peter's
> comments (which isn't surprising, really, it's actually *not* very hard
> to enable for a web app thanks to modules like mod_auth_kerb- probably a
> great deal less code than the LDAP auth needed, in fact).
>

Our problem here is likely to be that we can't rely on mod_auth_krb. In a
container we're running under Gunicorn for example (perhaps with a reverse
proxy or Traefik in a different container), and users will often host under
Nginx rather than Apache.

--
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company