Re: SSPI client authentication in non-Windows builds

From: Christian Ullrich <chris(at)chrullrich(dot)net>
To: Magnus Hagander <magnus(at)hagander(dot)net>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: SSPI client authentication in non-Windows builds
Date: 2011-01-17 16:46:59
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

Magnus Hagander wrote:
> On Mon, Jan 3, 2011 at 14:11, Christian Ullrich<chris(at)chrullrich(dot)net> wrote:
>> Hello all,
>> this patch adds support for connecting to servers running on Windows
>> and requesting SSPI authentication. It does this by treating
>> AUTH_REQ_SSPI the same as AUTH_REQ_GSS if no native SSPI support is
>> available.
>> In addition to being generally useful, this is a workaround to a
>> problem with MIT KfW that I encountered back in September 2010 [1].
>> This change has been tested and works correctly on FreeBSD 8.1, using
>> the Kerberos and GSSAPI libraries from Heimdal 1.4. The server is
>> running PostgreSQL 9.0.2 on Windows 2008.
> Does this require some certain minimum version of the kerberos
> libraries? Do you know if it works with just Heimdal or both Heimdal
> and MIT?
All it does ist GSSAPI auth, which means that it should work in any
environment where GSSAPI auth against a GSSAPI implementation that calls
itself that would work (because that part of SSPI is actually designed
for interoperability). As for reality, I'm afraid I don't know whether
it works with anything but the configuration I mentioned. I will do some
more testing this week, but I'm limited in the number of combinations I
can try; some randomly chosen Linux distributions with whatever Kerberos
they ship and the Heimdal from the FreeBSD 8 base system instead of the
port (if I can get PostgreSQL to build with that) against Windows 2003
and 2008 is probably going to be all I can offer. Expect a report early
next week.

You can find some more information at
> What I'm after is: do we need a autoconf check, or a #ifdef, or
> something to make sure we don't enable it in a scenario where it won't
> work?
Enabling it unconditionally (that is, conditional on --with-gssapi)
would mean that, instead of "SSPI authentication unsupported", the user
would get either success or authentication failure. Some may consider
the latter a regression in terms of user experience; I don't really agree.

The patch does not add any additional risk of build failure, because the
GSSAPI client code will always be compiled if enabled, and all the patch
really does is move a case label.


In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2011-01-17 16:47:40 Re: Moving test_fsync to /contrib?
Previous Message Tom Lane 2011-01-17 16:46:04 Re: Replication logging