On Wed, May 30, 2018 at 2:50 PM, Stephen Frost <sfr...@snowman.net> wrote:
> Greetings, > > * C GG (cgg0...@gmail.com) wrote: > > On Wed, May 30, 2018 at 12:04 PM, Stephen Frost <sfr...@snowman.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.
