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. > 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..?). > 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
Attachment:
signature.asc
Description: PGP signature
