Re: BUG #9337: SSPI/GSSAPI with mismatched user names
От | Tom Lane |
---|---|
Тема | Re: BUG #9337: SSPI/GSSAPI with mismatched user names |
Дата | |
Msg-id | 6417.1393269937@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: BUG #9337: SSPI/GSSAPI with mismatched user names (Brian Crowell <brian@fluggo.com>) |
Ответы |
Re: BUG #9337: SSPI/GSSAPI with mismatched user names
|
Список | 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 по дате отправления: