* 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. > 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'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. > 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. > > 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. 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'. > But - IIRC, you can just join your windows machine to your unix kerberos > realm and be done with it - SSPI APIs should work fine in that case. I don't think that's generally an option, again, in a university-type setting, even if you had a unix box. Thanks, Stephen
Description: Digital signature