Re: SSPI authentication - Mailing list pgsql-hackers

Stephen Frost wrote:
> * Magnus Hagander (magnus@hagander.net) wrote:
>> Stephen Frost wrote:
>>> I'm not quite sure if that would affect what we do but it sounds like it
>>> might.   The main thing we use on the clients wrt Postgres is the ODBC
>>> driver but I've used psql once or twice and have been trying to get
>>> people to learn it.
>> ODBC driver should work with it - I don't know exactly how they plug
>> into libpqs auth, but IIRC they do some stuff to make that work.
> 
> I wouldn't be so sure...  I'm not exactly a fan of how ODBC does that
> anyway, it essentially uses libpq for the auth, *sometimes*, and then
> hijacks the connection away.

Yeah, I'm not a fan of that either, but as long as it works..

Which leads me to the question - does it work for GSSAPI? Anybody from
the ODBC crowd who can comment on that?


>> Note that I'm only talking about being mutually exclusiv ewith MIT KRB
>> GSSAPI, not with MIT KRB in "krb5" mode. Though I very much want to
>> deprecate the "native kerberos" auth in favor of GSSAPI as soon as
>> possible for several reasons, so I'd suggest you don't use that once you
>> go to 8.3 ;-)
> 
> The KfW stuff from MIT provides both GSSAPI and 'native' kerberos, I
> believe, and most things use the GSSAPI side of it, actually.

We're pretty much the *only* major player who use "native" kerberos,
AFAIK. Back two years ago (I think it was) I found a really trivial
security hole in it (in the MIT code) that was exposed by a trivial user
input error. If anybody else was using it, they'd have found that one
long ago ;-)

GSSAPI really is the way to go.


>>> We've got SSPI which is used for the Windows domain (and only the windows
>>> resources) and then MIT Krb5 GSSAPI for the Unix resources.  While
>>> cross-realm is a nice idea it's less than easy to get going, especially
>>> with even a half-way secure key (I'm not exactly a big fan of
>>> arc/rc4...).
>> I have my Unix machines in the Active Directory, so there's no cross
>> realm. It works fine.
> 
> Yeah, that requires quite a bit more involvement between us and the
> corporate folks, and means that we're dependent on them to do things
> before we can do things.  That tends to end badly.

Heh.


>> And if you don't trust the key, put it over SSL? ;-) If you use SSL,
>> GSSAPI packets actually go through the SSL tunnel, unlike krb5 auth.
> 
> Uhh, the client and the KDC don't generally use SSL to talk to each
> other, last I checked, and the problem is with the cross-realm key (you
> know, the one that you could use to fake anyone from the trusted realm)
> having to be least-common-denominator between Windows and Unix since it
> has to exist in both KDCs.  That wouldn't be too much trouble if that
> least-common-denominator was AES256 but at the moment it's not.

Hm, Ok, thought you meant client<->server. Anyway, then use ipsec :-)


>>> Additionally, it seems likely to me that there will be cases when people
>>> running Windows don't *want* to set up an Active Directory for their
>>> Windows machines but want to use Kerberos to auth to certain resources
>>> (perhaps a campus environment where student systems aren't joined to an
>>> AD domain?).  Would that be possible with this?  I havn't done much w/
>>> SSPI so I'm not sure how deeply that's tied into things like that.
>> Yes, there's still support for doing GSSAPI with MIT KRB5. It's just
>> that you have to use it *instead* of SSPI. So a rebuild is necessary.
> 
> The way this is handled in a number of other applications (putty being
> the one that comes to mind easily) is that two DLLs are built- one for
> SSPI and one for GSSAPI and you can easily switch between them on the
> client.  That'd work fine for us.

Well, that you can do - you just need one libpq with sspi and one with
gssapi.


> I don't like the idea of having to rebuild things under Windows,
> honestly..  Not that I like to build anything these days...  If it's not
> enabled by default in some way I expect that it'd get 'forgotten'.

Ok, so looking at it from the other direction, say we wanted to support
both. Then we need to invent a new way for the client to tell libpq
which one to use. I think that's sensible if it's a common thing, but I
still see it as a *very* narrow use-case that needs both in the same DLL.
Or do you have a better idea on how to solve that?


//Magnus