Re: kerberos/SSPI (was: Client-side password encryption)

> > ODBC and Kerberos works just fine, if you use the 8.1 ODBC
> driver. I
> > use it all the time :)
>
> That's what I had heard, I just havn't gotten it working yet
> myself. :) Believe me when I say that I *really* want to have
> it working though; this postgres->pam->libpam-krb5 nonsense
> is really a huge pain...

I bet...


> > Haven't tried any cross-realm work, though, but I use it to
> > authenticate Windows users in AD to a postgresql server
> running on Linux.
> > (It's not SSPI, btw, it's plain Kerberos)
>
> The windows users still have to be running leash and
> kinit'ing against your unix-based KDC, don't they?

No. I don't have a Unix based KDC. I use only Active Directory KDC. And
with MIT Kerberos libs for Windows, you don't need to run a separate
kinit, provided you are logged into a domain. You need a registry
setting to make it work, though, but it's well docced on the MIT
kerberos pages.
The only thing that runs on Unix is my PostgreSQL server.


> If we had
> SSPI then the credentials your users use to log into the
> Windows AD could be used to authenticate them to the database
> as well.

That's what I do today, no need for SSPI.

>It'd need to be cross-realm though and that can be
> difficult due to having to find a common encryption key that
> doesn't suck (does one exist with the more recent versions of
> AD?  I don't know and I had real difficulty getting
> cross-realm working before, which is very frustrating :( ).

Cross-realm, I don't know about. Haven't tried that, I have only one
realm.


> > In general, I'm not sure it's worth it considering we can
> do AD with
> > Kerberos. It might be interesting to be able to use windows
> accounts
> > and passwords to do authentication that's *not* integrated
> (meaning we
> > take the password from the user and just use the windows
> SAM instead
> > of a passwd file). That's a completely different thing, though.
>
> I'm not really sure I follow what you mean by 'AD with
> Kerberos'.  I thought there were only two different options:
> MIT Kerberos on Windows (which isn't AD and you have to use
> leash to kinit seperately with) or SSPI and Windows AD (which
> means you have to implement against SSPI in the client code).

MIT Kerberos *client libraries* on Windows, with AD as *server*.
I meant AD with Kerberos vs local windows login, where you don't get any
kerberos at all.

> I'd love to discuss this further and I'm interested enough in
> SSPI support (assuming it's necessary to do what I want) that
> I'd be willing to spend some time looking into implementing
> it.  I don't think it'd be too difficult, aiui it's quite
> similar to the Kerberos calls...

Note that PostgreSQL today uses "native kerberos" and not "kerberos
GSSAPI", which I beleive most products use. We just call
krb5_sendauth()/krb5_recvauth() directly. I'm not sure how much is still
the same with SSPI.

I suggest you look carefully into using the current Kerberos stuff
first. But if it doesn't do what you need, then SSPI may be an option.
Unsure of how well that works cross-platform, though.

//Magnus