Re: BUG #9337: SSPI/GSSAPI with mismatched user names - Mailing list pgsql-bugs

From Tom Lane
Subject Re: BUG #9337: SSPI/GSSAPI with mismatched user names
Date
Msg-id 6417.1393269937@sss.pgh.pa.us
Whole thread Raw
In response to Re: BUG #9337: SSPI/GSSAPI with mismatched user names  (Brian Crowell <brian@fluggo.com>)
Responses Re: BUG #9337: SSPI/GSSAPI with mismatched user names
List pgsql-bugs
Brian Crowell <brian@fluggo.com> writes:
> On Mon, Feb 24, 2014 at 1:10 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Why exactly doesn't Npgsql know what the Kerberos principal name is?
>> How did it obtain the ticket without knowing that?

> Windows obtained the ticket, not Npgsql. It's attached to my logon
> token without Npgsql's help. If I'm on the domain, I _might_ have
> access to that information through a call to LsaGetLogonSessionData or
> similar. If I'm not on the domain, I definitely don't.

Hm, so how did Windows know what ticket to get?  *Somewhere* there's
got to be a mapping from "Brian" to "BCrowell".  It might not be
readily accessible to you though :-(

As noted upthread, we can't really do what you're suggesting without
a fundamental rearchitecting of our authentication scheme, which aside
from being a lot of work would probably break at least as many use-cases
as it improves.  To take one example, it's not unreasonable at all that
people might want database superusers to have to use a different auth
method from ordinary users --- so just taking the username out of the
auth method selection process doesn't sound workable.

It's unfortunate that this doesn't fit well with the architecture you
find yourself dealing with on the client side, but I doubt we can do
anything to help you.

            regards, tom lane

pgsql-bugs by date:

Previous
From: Brian Crowell
Date:
Subject: Re: BUG #9337: SSPI/GSSAPI with mismatched user names
Next
From: Stephen Frost
Date:
Subject: Re: BUG #9337: SSPI/GSSAPI with mismatched user names