Re: SSPI client authentication in non-Windows builds - Mailing list pgsql-hackers

From Christian Ullrich
Subject Re: SSPI client authentication in non-Windows builds
Date
Msg-id 4D22FA7C.1060904@chrullrich.net
Whole thread Raw
In response to Re: SSPI client authentication in non-Windows builds  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
* 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



pgsql-hackers by date:

Previous
From: Greg Smith
Date:
Subject: Re: Re: new patch of MERGE (merge_204) & a question about duplicated ctid
Next
From: Dimitri Fontaine
Date:
Subject: Extension support for pg_dump, patch v23