Re: .pgpass and root: a problem

* Shaun Thomas (sthomas@optionshouse.com) wrote:
> psql: GSSAPI continuation error: Unspecified GSS failure.  Minor
> code may provide more information
> GSSAPI continuation error: Server not found in Kerberos database
>=20
> Not extremely useful.

You need to register the server w/ AD by creating a principal for it and
then exporting the princ (shared secret between the KDC and the server)
and then loading it on the server.  Another option is to create a MIT or
Heimdal KDC and then set up a cross-realm trust.  Which you want to use
really depends on how large your Unix environment is (if it exists at
all) and how much it needs to be independent from the Windows/AD
systems.

> Here's what I don't get... If I'm my own user, and I call "kinit",
> it sets up my kerberos cache, having obtained it from our AD server.

Yes, you get a ticket-granting-ticket from the AD.

> Presumably, that means kerberos is a service that can forward
> requests to another server (AD) if it gets a request that isn't in
> its local cache.

Yes, whenever you connect to another system, it will attempt to do
Kerberos-based authentication by asking the KDC for a ticket for the
service you're connecting to.  For PostgreSQL, this would be something
like: POSTGRES/your.host.com@YOUR.DOMAIN.  If the princ is coming off of
AD directly, I believe it has to be all uppercase and you'll need to
tell PG (in postgresql.conf) that the krb service is POSTGRES.  Windows
clients should then be fine w/ connecting to it, but you'll have to
adjust your Unix-based psql config if you're using it.

> If it gets a response, that response is added to
> the local cache for the next request.

Yes, it will cache the service princ ticket, which is valid for a
limited timeframe.

> If not, I'm missing the benefit of kerberos.

If you'd like to secure your systems, I would strongly encourage you to
become familiar with Kerberos.  It underpins all of AD and many, many
Unix environments.  It is by far better than passing passwords around or
doing LDAP-style password-based authentication.  It can also integrate
into stronger authentication systems (eg: PKI, HSPD12/CAC smart cards).

> IMO, telling PG to use gss/kerberos should be as simple as turning
> it on, so whatever installed handling mechanism is consulted, ala
> PAM. Clearly I'm missing something. I'm going to read some docs to
> figure out the stack, but I've never seen this particular thing
> before.

Funny, as it's what makes AD work.

> It's obvious I should abandon LDAP. Fine. I tried PAM auth (which is
> configured to forward to AD), and that works graet, but has the same
> problem. If the user is presented with a PW prompt more than once in
> a row, something has failed.

PAM is just as bad (if not worse, depending on how you have it set
up...) than using LDAP.

    Thanks,

        Stephen