Re: [pgadmin-hackers] Client-side password encryption

* Magnus Hagander (mha(at)sollentuna(dot)net) wrote:
> 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...

> 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? 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. 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 :( ).

> (it works with libpq and OLEDB in 8.0.2 (I think, it could be .3), but
> it's much better in 8.1)

I'll definitely give it a shot. I think I'm going to upgrade our main
databases next week when it's quiet to 8.1 and see how that goes. I'll
definitely also try out MIT leash and 8.1 ODBC from Access to Postgres.

> > I guess to do that we'd have to make libpq under Windows have
> > the option of using the Windows SSPI layer. Anyone looked
> > into this at all?
> > Anyone know if it'd have a chance of getting accepted?
>
> That is another thing alltogether, which would allow us to work with NT4
> domains (not really interesting, IMHO) and local windows accounts (which
> might be interesting).

Yeah, the ability to use the credentials the users get when they log in
to authenticate them to Postgres would be *really* nice. Get that
working for Apache2, SSH, POP3/IMAP, etc, and you get the
'single-sign-on' golden crown... :)

> 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). Those are the two options the PuTTY Kerberos folks
provide and they do it using two different .dll files (where you rename
whichever one to 'krbauth.dll' or some such). I suppose another option
would be to have the Windows systems authenticate against Samba and a
Unix-based KDC but I didn't think that worked all that well yet and
unfortunately isn't an option for me anyway (can't just change people
from using the corporate domain server to using one I set up, wouldn't
really want to anyway).

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...

Thanks!

Stephen