Re: GSSAPI server side on Linux, SSPI client side on Windows

From: Magnus Hagander <magnus(at)hagander(dot)net>
To: Christian Ullrich <chris(at)chrullrich(dot)net>
Cc: Brian Crowell <brian(at)fluggo(dot)com>, "pgsql-general(at)postgresql(dot)org >> PG-General Mailing List" <pgsql-general(at)postgresql(dot)org>
Subject: Re: GSSAPI server side on Linux, SSPI client side on Windows
Date: 2013-11-12 12:00:55
Message-ID: CABUevEx_g5He2jKLDB1tPfVpXmpHNKNkNTU8RnBWWXeZLZhHOA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Tue, Nov 12, 2013 at 6:56 AM, Christian Ullrich <chris(at)chrullrich(dot)net>wrote:

> * From: Brian Crowell
>
> > On Mon, Nov 11, 2013 at 10:51 PM, Brian Crowell <brian(at)fluggo(dot)com>
> wrote:
> > > I think I'm getting closer though. I have psql on Windows successfully
> > > authenticating, so I can't be too far off.
> >
> > Got it.
>
> Great!
>
> > The NpgsqlPasswordPacket class has a bug: a utility function it calls
> > appends a null character to the data, which completely screws up GSSAPI.
> > Now that I fixed that, I've got successful integrated authentication from
> > Windows to PostgreSQL on Linux.
> >
> > However:
> >
> > * If I don't specify my username, Npgsql sends it in lowercase "bcrowell"
>
> Hmm. That is related one problem I've been having with SSPI auth from
> libpq/ODBC. The database treats the claimed user name case-sensitively when
> looking up the user info in pg_authid, and if the user logged on to Windows
> with a name differing in case from what the database thinks it is,
> authentication fails. Npgsql sending it always in lower case is precisely
> what I landed on as a workaround (basically overriding libpq's automatic
> user name detection in the ODBC connection string by appending a UID
> option).
>

Yes, windows is really annoying in this regard. It preserves what you
*logged in* with as your username - not what's stored in Active Directory
or the SAM.

> * Use "kerberos" package in AcquireCredentialsHandle call instead of
> > "negotiate"
>
> As long as it is the client that does that, it should be fine. According
> to the documentation on SSPI packages, it is valid for the client SSPI to
> send a GSSAPI token to a server using the Negotiate package (instead of
> going through SPNEGO to arrive at the same protocol).
>

I believe it should be ok, yes.

> > Also, in my case, it doesn't seem to matter for the SPN whether the
> > service name is "postgres" or "POSTGRES." I've got PostgreSQL set to
>
> Yeah, I think that bit about "you have to make the service name uppercase
> in postgresql.conf" is some kind of oral tradition that everyone quotes at
> everyone else. I have been using SSPI and GSSAPI since the days of Windows
> 2000, and it has always worked quite well without it.
>

I think it also depends on which kerberos libraries you have on each end.
I've certainly had a lot of issues with it in the past, with Windows 2000
AD controllers and I think also Windows 2003.

>
> > "postgres", and Npgsql is specifying "POSTGRES", but I also at some point
> > configured two sets of SPNs on the domain for uppercase and lowercase, so
> > I don't know if that's a mitigating factor.
>
> The client gets its service ticket, with only one service name in it,
> before contacting the server, so it cannot know what the server wants to
> see.
>
> Congratulations on getting it to work. I'm a bit envious that you beat me
> to it (GSS auth interop between PostgreSQL on Windows and others is kind of
> my hobby), but the sooner, the better.
>

+1 :)

--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Kevin Grittner 2013-11-12 13:18:58 Re: Clang 3.3 Analyzer Results
Previous Message Francisco Figueiredo Jr. 2013-11-12 11:45:28 Re: GSSAPI server side on Linux, SSPI client side on Windows