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