Thread: 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 notsupported\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@chrullrich.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@chrullrich.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@chrullrich.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@chrullrich.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@chrullrich.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
linkagainst 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
issuesee GCC bug #18799.
8: There was an interesting build issue in this configuration. Linux glibc does not include strlcpy(),
whichis why both libpgport and Heimdal's libroken have their own versions. What happens is that
PostgreSQL'sconfigure, after correctly determining that there is no declaration of strlcpy() in the
systemheaders, nevertheless detects libroken's implementation and excludes it from libpgport. Later,
(atleast) 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
2003R2server 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@chrullrich.net> wrote: > * Christian Ullrich wrote: > >> Magnus Hagander wrote: > >>> On Mon, Jan 3, 2011 at 14:11, Christian Ullrich<chris@chrullrich.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/
Attachment
* 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@chrullrich.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@hagander.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@hagander.net> wrote: > On Sat, Jan 29, 2011 at 16:21, Christian Ullrich <chris@chrullrich.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/