Re: LDAP authentication slow

On Wed, May 30, 2018 at 12:04 PM, Stephen Frost <sfrost(at)snowman(dot)net> wrote:

> Greetings,
>
> * C GG (cgg0007(at)gmail(dot)com) wrote:
> > This is PostgreSQL 9.5 -- We just enabled LDAP(S) authentication (to an
> > Active Directory server) for a certain grouping of users
>
> You really shouldn't be using LDAP auth to an Active Directory system.
> Active Directory supports Kerberos, which is a much more secure way to
> authenticate.
>
>
Understood, and I agree.

> > I'm getting complaints from the users authenticating using ldap that
> > database operations are taking quite a bit longer than they were
> previously
> > when they were authenticating with MD5 stored passwords. Clearly, there's
> > more machinery at work with that kind of operation, but the increase in
> > time is way more that I would have estimated.
>
> Using Kerberos/GSSAPI will be much faster as you only need to get a
> ticket and then that can be reused to authenticate multiple times to the
> database without having to contact the LDAP server.
>

This is also understood.

>
> > I still want them to be able to type in a password, so GSSAPI is out for
> an
> > alternative (right?) ... Is there something I can do to help speed things
> > up? If there any telemetry that I can generate (logs, stats, etc.) which
> > might be able to pinpoint a bottleneck?
>
> What's the reason for wishing for them to "be able to type in a
> password"? With GSSAPI/Kerberos, users get true single-sign-on, so they
> would log into the Windows system with a password and then have a TGT
> which can be used to authenticate to other services without having to
> type in their password over and over again.
>
>
By and large, we're using pre-existing tools that would have to be heavily
modified to co-opt GSSAPI as an authentication method. For some
tools/applications, it's just not practical to use a ticket. But the
username/password paradigm is well supported. Most of these tools aren't
being used on Windows machines. That's not to say that Linux and macOS
don't have robust Kerberos tools available for use, but thinking that
Kerberos tickets are just floating out there in login-space waiting to be
used by psql and other tools isn't really the case in our environment.

The main reason for moving to LDAP(S) is the ability to enforce password
quality and rotation without the risk of disclosure (
https://www.postgresql.org/docs/10/static/passwordcheck.html) ... Allowing
pre-hashed passwords to be sent to the back-end circumvents any protections
passwordcheck might give. Plus, passwordcheck isn't available in all
PostgreSQL environments (I'm specifically thinking of AWS RDS).

Unless I've missed something GSSAPI is still out of consideration if we're
having to supply username/password combinations in connection strings.

I am still wondering what can we do to speed LDAP(S) up? Is there a
speedier authentication delegation paradigm that utilizes username/password
from the client?

> Thanks!
>
> Stephen
>