Re: BUG #9337: SSPI/GSSAPI with mismatched user names

* Brian Crowell (brian(at)fluggo(dot)com) wrote:
> On Mon, Feb 24, 2014 at 6:30 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> > Um. I spoke imprecisely, I see. The objection to involving a Kerberos
> > server in determining the username is not solely about the cycles
> > involved; it's that it requires identifying a specific Kerberos server
> > to do it. Don't we lose multi-realm support if we have to know the
> > server's password in advance of examining pg_hba.conf?
>
> Not as far as I know. For GSSAPI, the server determines which password
> to use based on the ticket, which includes the server's principal
> name, and it looks it up in its own key file (PG's krb_server_keyfile
> option). (For SSPI, I don't think you can use multiple passwords; if
> coming from another domain, you'd need Active Directory's assistance
> to cross the domain correctly.)

There's two different things here- multi-realm (as in, a given server
can live in multiple, independent, realms) and cross-realm (where the
realms trust each other). For cross-realm, the server exists only in
one realm and there's only one key for it; users from other realms will
get a cross-realm ticket-granting-ticket which can then be used to
request a service ticket for the server. For multi-realm, there's
multiple keys because the server actually exists in multiple realms.
I've not gone back to look at why we added multi-realm support, but I
wonder if it might have specifically been to allow a PG server to be in
both an AD realm and a Unix realm at the same time, without a cross
realm trust between the two (which was problematic until AD got AES
support since the only compatible encryption was quite weak).

While I've seen discussion about it in the past, my recollection is that
we *do* need to decide which entry in the keytab to use to decrypt the
ticket first and to figure that out we need to know what we're going to
use for krb_realm, krb_srvname and krb_server_hostname. Since those can
be set in pg_hba.conf based on the information we're provided in the
startup packet, we would be giving up some flexability in this case.

On the other hand, Magnus removing the krb5 auth method also removed
krb_server_hostname.. I'll ask him about that because we should
probably make that available under 'gss' or we may end up leaving some
of our users out in the cold when 9.4 comes out and that'd be quite
unfortuante.

Regarding getting the username from the local credential cache, in the
(recently removed) krb5 support, we were extracting the username in
libpq from the credentials cache, but only needed it to pass back to
the krb5 calls. Still, that is example code of how to do it using the
Kerberos libraries, while you can use gss_inquire_cred() with GSSAPI.

If we decide to allow an option where we use the 'default cred' in
GSSAPI to also determine the PG username we are authenticating to, we'll
want to think about how we support that in libpq and psql and consider
what to do about the limitations of not being able to specify different
krb_server_hostname depending on the user which is attempting to
authenicate.

> I also went back and checked, and the server does not have to contact
> a Kerberos server to authenticate the client or determine its user
> name. So long as the ticket is encrypted with the correct password
> (Postgres's password), Postgres can decrypt it and know who the client
> is and that they're really who they say they are.

That's correct- a server in a Kerberos realm never directly communicates
(as part of Kerberos) with the KDCs.

> Since this request has turned out to be a little more complicated than
> I thought, I'd like to volunteer to research it further and maybe
> bring it along. It's not part of my job duties right now, so I'll have
> to come back and visit it later, but so far I don't see anything
> obvious that would make it unfeasible. The GSSAPI/Kerberos case looks
> the easiest. SSPI/Negotiate will be harder because that requires
> passing data back and forth; you couldn't finish in one packet.

No complaints here, just a word of caution that we don't want to break
existing setups and should consider what other systems do in this regard
to avoid surprising behavior for users who are used to SSH or other
Kerberos-enabled systems.

Thanks,

Stephen