Re: SSPI client authentication in non-Windows builds

* 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