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

All,

I'll fill in more on this tomorrow, but the actual service ticket is not
going to be useful on the client side, no. There is a ticket cache on the
client though, normally, which should have info about the princ the cache
is for. That's what klist operates against (on Windows and Linux..).

Thanks,

Stephen

On Monday, February 24, 2014, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> Brian Crowell <brian(at)fluggo(dot)com <javascript:;>> writes:
> > On Mon, Feb 24, 2014 at 3:40 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us<javascript:;>>
> wrote:
> >> If it's possible to get a name out of a ticket without contacting a
> >> realm server, I think what you're talking about would likely be all
> right.
>
> > Well, for starters, it turns out I'm wrong about the principal. Only
> > the target principal (that of the Postgres server) is in clear text.
> > The source principal (my user name) is in the encrypted part of the
> > request, so that can _only_ be decrypted by the server. However, if I
> > remember right, the server will be in direct possession of the
> > decryption key (IIRC, its own password), and therefore should be able
> > to determine the user name without contacting a third server.
>
> 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?
>
> I looked at our docs again and notice that there is no authentication
> server specification option for the GSSAPI auth method. I guess that
> that information is buried within the "server key file" or someplace;
> this goes beyond my knowledge of Kerberos internals I fear. I do see
> that there isn't any visible specification of a server password either,
> so even absent the multi-realm issue it's not clear to me that what
> you propose is practical for code outside the Kerberos libraries.
>
> regards, tom lane
>
>