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