Re: TODO: GNU TLS

* Joshua D. Drake (jd(at)commandprompt(dot)com) wrote:
> > > I do not like --with-krb5 because it has extremely limited real world
> > > use.
> >
> > Riiigghhhttt... Only every Windows setup which uses Active Directory,
> > most major universities, and certain large corporations (uh, AOL?) would
> > even think to use something like Kerberos!
>
> I said "Extremely Limited" real world use. Between just two of my
> customers, in the next 2 years we (CMD) will have 12 thousand postgresql
> installations. Not one of them will use Kerberos.

There's no accounting for poor taste...

> > > I do not like --with-pam but only because I have never gotten it to
> > > work.
> >
> > We use it on some of our production systems (since it can provide
> > cracklib, password expiration, etc, and the postgres instance inside
> > it's own vserver so it doesn't hurt as much to make the passwd/shadow
> > files available to it...). I'd be happy to help you get it to work if
> > you'd like, and I could even provide you with some PG/C functions to use
> > password changing and password aging. :)
>
> Oh, I am sure it is great. I have just never tried that hard to get it
> to work :)

Oh, I never said it was great, just said that we used it since PG
doesn't directly provide the things we need (cracklib, password aging,
etc).

> > > I do like --with-ldap because it is pretty much standard within
> > > directory lookups by the nature of Active Directory.
> >
> > Funny you like LDAP but not Kerberos, both of which are part of Active
> > Directory... Using LDAP simple binds to AD for authentication is
> > *quite* silly and *much* less secure than using Kerberos...
>
> Yes but LDAP gives me a lot of other things, easily and it has SSL. SSL
> + Firewall gives me 98% of the security I need.

Unfortunately, security isn't a game of percentages. Hopefully you'll
never have a server compromised which is then used to capture passwords
which can then be used to jump to other systems... Kerberos is there
and it's not too hard to use (though does depend on the MIT Kerberos for
Windows service currently). Supporting SSPI/GSSAPI and then writing a
small document on how to generate Windows keytabs for Postgres would
mean single-sign-on for Windows users using applications which use
libpq...

Thanks,

Stephen