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

Поиск
Список
Период
Сортировка
От Magnus Hagander
Тема Re: GSSAPI server side on Linux, SSPI client side on Windows
Дата
Msg-id CABUevEx_g5He2jKLDB1tPfVpXmpHNKNkNTU8RnBWWXeZLZhHOA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: GSSAPI server side on Linux, SSPI client side on Windows  (Christian Ullrich <chris@chrullrich.net>)
Список pgsql-general

On Tue, Nov 12, 2013 at 6:56 AM, Christian Ullrich <chris@chrullrich.net> wrote:
* From: Brian Crowell

> On Mon, Nov 11, 2013 at 10:51 PM, Brian Crowell <brian@fluggo.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/

В списке pgsql-general по дате отправления:

Предыдущее
От: "Francisco Figueiredo Jr."
Дата:
Сообщение: Re: GSSAPI server side on Linux, SSPI client side on Windows
Следующее
От: Brian Crowell
Дата:
Сообщение: Re: GSSAPI server side on Linux, SSPI client side on Windows