Stephen Frost wrote:
Magnus, et al,
* Magnus Hagander (mag...@hagander.net) wrote:
Looking at the open item about the new error message shown when Kerberos
is compiled in, and not used:
assword:
FATAL: password authentication failed for user mha
psql: pg_krb5_init: krb5_cc_get_principal:
Magnus Hagander mag...@hagander.net writes:
Now that we have support for mappings, I expect it will be more common
for a user to authenticate with princ 'A' and then connect using their
Unix id 'B' to a PG user 'B'. As such, I'm alright with dropping
support for this. Users can always use
On 13 jan 2009, at 15.20, Gregory Stark st...@enterprisedb.com wrote:
Magnus Hagander mag...@hagander.net writes:
Now that we have support for mappings, I expect it will be more
common
for a user to authenticate with princ 'A' and then connect using
their
Unix id 'B' to a PG user 'B'. As
For what it's worth this always bothered me. I often - but nit always
- - have kerberos tickets gsst...@... lying around but my unix id is
stark.
I never set up kerberos authentication for postgres but whrn the
tickets happen to be there it fails to authenticate. I think I
complained
Looking at the open item about the new error message shown when Kerberos
is compiled in, and not used:
assword:
FATAL: password authentication failed for user mha
psql: pg_krb5_init: krb5_cc_get_principal: No credentials cache found
FATAL: password authentication failed for user mha
The
Magnus Hagander mag...@hagander.net writes:
The reason this is happening is that we are initializing Kerberos even
if we're not going to use it. The reason for doing *this*, is that if
kerberos is compiled in, we use it to find out if we should try a
different username than the one logged in
Magnus, et al,
* Magnus Hagander (mag...@hagander.net) wrote:
Looking at the open item about the new error message shown when Kerberos
is compiled in, and not used:
assword:
FATAL: password authentication failed for user mha
psql: pg_krb5_init: krb5_cc_get_principal: No credentials cache
