Re: SSPI client authentication in non-Windows builds

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.

I originally fixed only the JDBC driver in this way [2], but then I
thought that I might try applying the same logic to libpq as well.

The preprocessor logic in that part of fe_sendauth() is quite
impenetrable; I hope I have not broken everything else.

[1] <http://archives.postgresql.org/message-id/i6cpc2%24m3h%241%40dough.gmane.org>
[2] <http://archives.postgresql.org/message-id/i6org1%24mup%241%40dough.gmane.org>

*** src/interfaces/libpq/fe-auth.c.orig Mon Jan 3 13:33:32 2011
--- src/interfaces/libpq/fe-auth.c Mon Jan 3 13:34:41 2011
***************
*** 831,836 ****
--- 831,839 ----

#if defined(ENABLE_GSS) || defined(ENABLE_SSPI)
case AUTH_REQ_GSS:
+ #if defined(ENABLE_GSS) && !defined(ENABLE_SSPI)
+ case AUTH_REQ_SSPI:
+ #endif
{
int r;

***************
*** 891,896 ****
--- 894,902 ----
#else
case AUTH_REQ_GSS:
case AUTH_REQ_GSS_CONT:
+ #ifndef ENABLE_SSPI
+ case AUTH_REQ_SSPI:
+ #endif
printfPQExpBuffer(&conn->errorMessage,
libpq_gettext("GSSAPI authentication not supported\n"));
return STATUS_ERROR;
***************
*** 913,923 ****
}
pgunlock_thread();
break;
- #else
- case AUTH_REQ_SSPI:
- printfPQExpBuffer(&conn->errorMessage,
- libpq_gettext("SSPI authentication not supported\n"));
- return STATUS_ERROR;
#endif


--- 919,924 ----

On Mon, Jan 3, 2011 at 8:11 AM, Christian Ullrich <chris(at)chrullrich(dot)net> wrote:
> 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.

I have to confess that I don't know whether this is a good idea or a
bad idea. But you should add your patch here, in any case:

https://commitfest.postgresql.org/action/commitfest_view/open

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

* Robert Haas wrote:

> On Mon, Jan 3, 2011 at 8:11 AM, Christian Ullrich<chris(at)chrullrich(dot)net> wrote:

>> 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.
>
> I have to confess that I don't know whether this is a good idea or a
> bad idea.

Both GSS and SSPI have advantages and disadvantages.

To use SSPI, your backends must run as a dedicated domain account, so if
you use the binary installer, you have to change permissions on the data
directory and reconfigure the service. On the other hand, you do not
need a keytab.

To use GSS, you need a keytab, but not a domain user account, and thus
no domain at all.

Earlier, I had the concern that using client-side GSSAPI (or the
Kerberos SSPI package) to connect to a server using SSPI Negotiate (as
the backend currently does) was a violation of the published protocol,
but that the Negotiate SSP handled this by falling back to Kerberos. I
would have been reluctant to rely on this behavior, which I thought
undocumented. However, I just found the documentation that says this is
all right:

<http://msdn.microsoft.com/en-us/library/aa378748(v=VS.85).aspx>

"A server that uses the Negotiate package is able to respond to client
applications that specifically select either the Kerberos or NTLM
security provider."

This covers the case where the client is running Windows, because then
libpq will actually use SSPI instead of GSSAPI, satisfying the letter of
the documentation. By implication, because SSPI Kerberos is wire-level
compatible with GSSAPI, it also covers the case where the client is
running on another platform and uses native GSSAPI libraries to
authenticate.

If it was not for supporting NTLM through SSPI, it would even be
possible to simply get rid of AUTH_REQ_SSPI entirely and let the server
send AUTH_REQ_GSS for "sspi" lines in pg_hba.conf. By doing this, no
patches to the client libraries are needed, because both libpq and the
JDBC driver will automatically do the right thing on all platforms.

--
Christian Ullrich

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?

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?

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

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
<http://msdn.microsoft.com/en-us/library/aa380496(v=VS.85).aspx
<http://msdn.microsoft.com/en-us/library/aa380496%28v=VS.85%29.aspx>>.
> 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.

--
Christian

* Christian Ullrich wrote:

> Magnus Hagander wrote:

>> On Mon, Jan 3, 2011 at 14:11, Christian Ullrich<chris(at)chrullrich(dot)net>
>> wrote:

>>> 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?

> 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.

This is what I tested this week. If there are any additional questions,
please let me know.

Clients tested
--------------

1 FreeBSD 8.1 (x86), Heimdal 1.4 (released Sep 2010)
2 Gentoo Linux (x86_64) 20110113, Heimdal 1.3.3 (released May 2010)
3 Gentoo Linux (x86_64) 20110113, MIT 1.9 (released Dec 2010)
4 Gentoo Linux (x86_64) 20110113, MIT 1.8.3 (released Aug 2010)
5 Ubuntu Linux (x86) 10.10, MIT 1.8.1 (released Apr 2010)
6 FreeBSD 7.0 (x86), Heimdal 0.7 (released Jun 2005)
7 Debian Linux (x86) 5.0.7, MIT 1.4 (released Jan 2005)
8 Debian Linux (x86) 5.0.7, Heimdal 0.7.2 (released Feb 2006)

Notes:

My approach in building PostgreSQL on the clients was to first get it to
build without the patch, then add the patch, do a minimal rebuild
("make") and test with databases configured for "md5" and "sspi"
authentication.

I also tried GNU shishi as a third Kerberos implementation, but could
not get it to even attempt to get a TGT.

2, 3, 4: These were the only Kerberos implementations available
in Portage, obviously very recent ones.

6: Heimdal 0.7 was the oldest release I could get to build
on this platform, and getting PostgreSQL to link against
it required some work.

7: MIT 1.4 is the first release that will build with gcc 4,
while the first release that PostgreSQL might possibly
compile with is 1.3. Everything before that does not
have a sufficient GSSAPI. For the GCC issue see GCC bug
#18799.

8: There was an interesting build issue in this configuration.
Linux glibc does not include strlcpy(), which is why both
libpgport and Heimdal's libroken have their own versions.
What happens is that PostgreSQL's configure, after
correctly determining that there is no declaration of
strlcpy() in the system headers, nevertheless detects
libroken's implementation and excludes it from libpgport.
Later, (at least) ecpg and initdb fail to link because it
is not there. I could not figure out how to force it to
be included in libpgport, so I had to use libroken instead.

Servers tested
--------------

A Windows Server 2008 (x86_64), PostgreSQL 9.0.2 (x86_64)
B Windows Server 2008R2 (x86_64), PostgreSQL 8.4.4 (x86)
C Windows Server 2003R2 (x86), PostgreSQL 9.0.2 (x86)

Notes:

A: This is the (production) installation I mentioned originally.

B, C: These are dedicatedldd testing installations.

Server configuration procedure
------------------------------

- Installed operating system
- Joined to domain
- Installed PostgreSQL
- Stopped service
- Created service account in domain, added SPNs using ADSIEdit

I used a "managed service account" for the 2008R2 server, which I then
installed on that server. Postgres on the 2003R2 server is using a
standard user account.

- Changed permissions on data directory
- Changed service logon
- Started service

Combinations tested successfully
--------------------------------

1 2 3 4 5 6 7 8

A X

B X X X X X X

C X X X

Combinations tested unsuccessfully
----------------------------------

1 2 3 4 5 6 7 8

A

B

C

Conclusion
----------

There is no detectable risk of SSPI-via-GSS authentication failure due
to interoperability problems between the client's GSSAPI and the
server's SSPI, no matter the versions involved. The only potential
exception is with a Windows 2000 server, which I did not have access to
and consequently did not test.

A number of pitfalls can hamper building PostgreSQL, especially with
older Kerberos implementations. These, however, will equally affect
builds that are intended to use only "traditional" GSSAPI authentication.

I am not sure what I may have done wrong in the case of client 8, which
was a Debian system installed using the minimal CD. Maybe I was missing
some package or other. Given that this was on Debian, it would surprise
me if it was a genuine bug in configure.

--
Christian

On Sun, Jan 23, 2011 at 16:02, Christian Ullrich <chris(at)chrullrich(dot)net> wrote:
> * Christian Ullrich wrote:
>
>> Magnus Hagander wrote:
>
>>> On Mon, Jan 3, 2011 at 14:11, Christian Ullrich<chris(at)chrullrich(dot)net>
>>> wrote:
>
>>>> 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?
>
>> 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.
>
> This is what I tested this week. If there are any additional questions,
> please let me know.

Thanks, this is exactly the kind of testing I was hoping for - or
rather, it's a lot more extensive than I was hoping for :)

However, i think the code path down around the error message is simply
incorrect. That #ifdef spaghetti is pretty hard to parse, but it gives
the wrong error message (we should say it's sspi that's not available
when we have none of the two options) and/or a "duplicate case label"
error, in some combinations of sspi/gssapi existing/notexisting.

Attached is an updated version of the patch that passes compiling on
all my systems in different combinations, including msvc. Can you
verify that it still works in your env? (you don't have to retest all
those platforms!)

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

* Magnus Hagander wrote:

> However, i think the code path down around the error message is simply
> incorrect. That #ifdef spaghetti is pretty hard to parse, but it gives
> the wrong error message (we should say it's sspi that's not available
> when we have none of the two options) and/or a "duplicate case label"
> error, in some combinations of sspi/gssapi existing/notexisting.
>
> Attached is an updated version of the patch that passes compiling on
> all my systems in different combinations, including msvc. Can you
> verify that it still works in your env? (you don't have to retest all
> those platforms!)

Yes, it works fine, for md5, sspi, and gss authentication methods,
tested with MIT 1.4 against Windows 2008R2, PostgreSQL 8.4.4.

For some reason, the 9.0.2 binary installer for Windows does not install
the Kerberos/GSSAPI DLLs, so I cannot test with that version.

--
Christian

On Sat, Jan 29, 2011 at 16:21, Christian Ullrich <chris(at)chrullrich(dot)net> wrote:
> * Magnus Hagander wrote:
>
>> However, i think the code path down around the error message is simply
>> incorrect. That #ifdef spaghetti is pretty hard to parse, but it gives
>> the wrong error message (we should say it's sspi that's not available
>> when we have none of the two options) and/or a "duplicate case label"
>> error, in some combinations of sspi/gssapi existing/notexisting.
>
>>
>>
>> Attached is an updated version of the patch that passes compiling on
>> all my systems in different combinations, including msvc. Can you
>> verify that it still works in your env? (you don't have to retest all
>> those platforms!)
>
> Yes, it works fine, for md5, sspi, and gss authentication methods, tested
> with MIT 1.4 against Windows 2008R2, PostgreSQL 8.4.4.

Great, thanks!

> For some reason, the 9.0.2 binary installer for Windows does not install the
> Kerberos/GSSAPI DLLs, so I cannot test with that version.

That's intentional - but they are not needed for SSPI operation on
windows, and in fact won't even be used by default if they're there.

They were taken out of the main packaging due to them being a PITA to
deal with in general, IIRC.

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

* Magnus Hagander (magnus(at)hagander(dot)net) wrote:
> They were taken out of the main packaging due to them being a PITA to
> deal with in general, IIRC.

Yes, making it very difficult for those of us who still need them. :(

Stephen

On Sat, Jan 29, 2011 at 16:22, Magnus Hagander <magnus(at)hagander(dot)net> wrote:
> On Sat, Jan 29, 2011 at 16:21, Christian Ullrich <chris(at)chrullrich(dot)net> wrote:
>> * Magnus Hagander wrote:
>>
>>> However, i think the code path down around the error message is simply
>>> incorrect. That #ifdef spaghetti is pretty hard to parse, but it gives
>>> the wrong error message (we should say it's sspi that's not available
>>> when we have none of the two options) and/or a "duplicate case label"
>>> error, in some combinations of sspi/gssapi existing/notexisting.
>>
>>>
>>>
>>> Attached is an updated version of the patch that passes compiling on
>>> all my systems in different combinations, including msvc. Can you
>>> verify that it still works in your env? (you don't have to retest all
>>> those platforms!)
>>
>> Yes, it works fine, for md5, sspi, and gss authentication methods, tested
>> with MIT 1.4 against Windows 2008R2, PostgreSQL 8.4.4.
>
> Great, thanks!

And applied.

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