On Wed, May 30, 2018 at 12:04 PM, Stephen Frost <sfrost@xxxxxxxxxxx> wrote:
Greetings,
* C GG (cgg0007@xxxxxxxxx) 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
