Re: SSPI authentication

* Magnus Hagander (magnus(at)hagander(dot)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.

> 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