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:
https://github.com/npgsql/Npgsql/issues/162#issuecomment-35916650
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?
--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
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
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
* 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
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
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general