Thread: GSSAPI/SSPI and mismatched user names
I'm going to file this as a bug as well, but I guess I'm hoping to catch some developers here for discussion.
I'm working with the Npgsql group on getting integrated security to "just work" in the same way SQL Server's does. I wrote a workaround for one issue, only to find out that I need more workarounds, and I finally realized that this a problem with the way Postgres handles GSSAPI/SSPI logins. You can read my full description here:
The short version is that Postgres requires two user names when using GSSAPI/SSPI: one from the startup packet, and one from the Kerberos ticket, and if these don't match exactly, the login fails. It's generally impossible to determine the correct user name to send in the startup packet.
I think Postgres should either not require or ignore the user name in the startup packet for these two login types. What do you think?
I think Postgres should either not require or ignore the user name in the startup packet for these two login types. What do you think?
—Brian
* Brian Crowell (brian@fluggo.com) wrote: > https://github.com/npgsql/Npgsql/issues/162#issuecomment-35916650 Reading through this- can't you use GSSAPI to get the Kerberos princ found the ticket which is constructed? I'm pretty sure the MIT libraries support that, at least... > The short version is that Postgres requires two user names when using > GSSAPI/SSPI: one from the startup packet, and one from the Kerberos ticket, > and if these don't match exactly, the login fails. It's generally > impossible to determine the correct user name to send in the startup packet. Just as with .k5login, they do *not* have to match, but if they don't then there needs to be a mapping provided from the Kerberos princ to the PG username. Check out pg_ident and note that it even supports regexp's, so you may be able to construct a mapping such that the princ is mixed case and the login works- provided you send the lowercase'd username as the PG user to log in as. > I think Postgres should either not require or ignore the user name in the > startup packet for these two login types. What do you think? We need the username to figure out which auth method we're using... Thanks, Stephen
Attachment
On Mon, Feb 24, 2014 at 12:55 PM, Stephen Frost <sfrost@snowman.net> wrote: > * Brian Crowell (brian@fluggo.com) wrote: >> https://github.com/npgsql/Npgsql/issues/162#issuecomment-35916650 > > Reading through this- can't you use GSSAPI to get the Kerberos princ > found the ticket which is constructed? I'm pretty sure the MIT > libraries support that, at least... I expected I might be able to do that on Linux, but right now I'm trying to work out the Windows non-domain case. > Just as with .k5login, they do *not* have to match, but if they don't > then there needs to be a mapping provided from the Kerberos princ to the > PG username. Check out pg_ident and note that it even supports > regexp's, so you may be able to construct a mapping such that the princ > is mixed case and the login works- provided you send the lowercase'd > username as the PG user to log in as. Unfortunately, in this case I don't even have a wrong-cased username to start with. I have the user name of the logged-in non-domain user, which is not the user name of the domain credentials I'm sending across the network. >> I think Postgres should either not require or ignore the user name in the >> startup packet for these two login types. What do you think? > > We need the username to figure out which auth method we're using... Oh dear. --Brian
* Brian Crowell (brian@fluggo.com) wrote: > On Mon, Feb 24, 2014 at 12:55 PM, Stephen Frost <sfrost@snowman.net> wrote: > > * Brian Crowell (brian@fluggo.com) wrote: > >> https://github.com/npgsql/Npgsql/issues/162#issuecomment-35916650 > > > > Reading through this- can't you use GSSAPI to get the Kerberos princ > > found the ticket which is constructed? I'm pretty sure the MIT > > libraries support that, at least... > > I expected I might be able to do that on Linux, but right now I'm > trying to work out the Windows non-domain case. I'm afraid you're going to need to try harder to find out how to get the Windows GSSAPI/SSPI code to give you the princ. I was actually pretty sure that GSSAPI defined a way, but I don't know the Windows side of it or if they decided to not bother implementing parts of GSSAPI. > Unfortunately, in this case I don't even have a wrong-cased username > to start with. I have the user name of the logged-in non-domain user, > which is not the user name of the domain credentials I'm sending > across the network. You're going to need to figure out how to tell PG what PG user you want to log in as in the initial packet. > > We need the username to figure out which auth method we're using... > > Oh dear. Exactly- this is not something we can solve with a little bit of tweaking... Thanks, Stephen
Attachment
On Mon, Feb 24, 2014 at 1:06 PM, Stephen Frost <sfrost@snowman.net> wrote: > I'm afraid you're going to need to try harder to find out how to get the > Windows GSSAPI/SSPI code to give you the princ. I was actually pretty > sure that GSSAPI defined a way, but I don't know the Windows side of it > or if they decided to not bother implementing parts of GSSAPI. I don't think there's a Windows GSSAPI implementation at all. You're expected to go through Win32 and all of their security providers. Read here for some of the loveliness: http://stackoverflow.com/questions/7613468/getting-the-current-username-when-impersonated https://groups.google.com/forum/#!topic/microsoft.public.platformsdk.security/5L7ugO0Fc90 (Really, though, the Windows login infrastructure and API is rather nice.) > Exactly- this is not something we can solve with a little bit of > tweaking... Nuts. It sounded easy :P --Brian