Re: LDAP authentication slow

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

> Greetings,
>
> * C GG (cgg0007(at)gmail(dot)com) wrote:
> > On Wed, May 30, 2018 at 12:04 PM, Stephen Frost <sfrost(at)snowman(dot)net>
> wrote:
> > > 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.
>
> This argument doesn't really hold much weight. Anything using libpq is
> likely to work well with GSSAPI and most languages base their access to
> PG on libpq. Ensuring that a ticket is available also isn't hard with
> k5start or similar. Even proxying tickets with mod_auth_kerb or similar
> isn't all that difficult to get going to leverage SPNEGO.
>

Sounds complicated.

>
> > 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).
>
> This seems entirely out-of-place and not related to GSSAPI (pre-hashed
> passwords..?). Further, password quality and rotation would be able to
> be handled by AD instead of trying to do it in PG, though this also
> seems to be conflating different things (are you talking about access
> from an application, whose password should be randomly generated to
> begin with, or users..?).
>
>
Correct. Password quality and rotation needs to be handled in AD instead of
trying to do it in PG.

I'm feeling attacked for trying to work with the tools I have available to
me and the constraints I have been given.

> > Unless I've missed something GSSAPI is still out of consideration if
> we're
> > having to supply username/password combinations in connection strings.
>
> There continues to be some confusion here as with GSSAPI you
> specifically wouldn't need to include passwords 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?
>
> Passing passwords around between different systems for authentication is
> likely to be expensive and insecure. Using SCRAM on PG would at least
> avoid the call out from the PG server to the LDAP server but then you
> would have different passwords on the different systems potentially.
>
The solution to these issues is to move away from passing passwords
> around, as Active Directory did.
>
> Thanks!
>
> Stephen
>

Please let me be clear, this is not a question about whether or not to use
passwords. This is a question of how to determine the cause of and remedy a
slowdown retrieving data from PostgreSQL when using LDAP(S) to authenticate
PostgreSQL users. One of the sideline questions would be how to achieve the
same effect by using a different scheme. I should further clarify that a
major requirement would be that the scheme would need to work in our
current environment without having to re-engineer the client applications.
That would entail the need to pass a username and password as we have
traditionally done.

Any friendly assistance with LDAP(S) to that end is welcome.