Tim,
* Tim Watts (tim.j.watts@kcl.ac.uk) wrote:
> I would have to respectfully take another point of view: that that
> particular judgement is probably better placed with the sysadmin
> rather than a blanket decision by the devs.
It's not a blanket decision by any means- the current situation is that
such an option doesn't exist. It's not "it exists, but we disabled it
because we felt like it."
Were someone to write the code to support such an option, it's entirely
possible it'd get committed (though likely with strong caveats about its
use in the documentation).
> Reason: Whilst the argument is solid in an ideal world (all clients
> are part of the kerberos realm), in reality it means that I cannot
> gain partial security improvements and I have to leave it running
> with PAM auth which ensures that passwords are chucked around 100%
> of the time.
The pg_hba.conf allows you to migrate users or sets of users at a time.
Having a fall-back mechanism if Kerberos doesn't work is a different
thing. My experience has been that all clients (or at least, all in a
given IP range or for a set of users) *are* part of the Kerberos realm
because they're coming from Active Directory or another entrenched
Kerberos installation. That's specifically because that's how
Kerberos is intended to work and how it provides a strong
authentication mechanism.
> But it would be nice to be able to use kerberos tickets *where
> available* and fallback to password-interactive login where not.
And I continue to contend that this is a very bad idea.
Thanks,
Stephen
