Stephen Frost wrote: > * Magnus Hagander ([EMAIL PROTECTED]) 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 ---------------------------(end of broadcast)--------------------------- TIP 4: Have you searched our list archives? http://archives.postgresql.org