On Sun, Jul 16, 2017 at 11:05 PM, Stephen Frost <sfrost@snowman.net> wrote:
Magnus, all, * Magnus Hagander (magnus@hagander.net) wrote: > (FWIW, a workaround I've applied more than once to this in AD environments > (where kerberos for one reason or other can't be done, sorry Stephen) is to > set up a RADIUS server and use that one as a "middle man". But it would be > much better if we could do it natively)
I'd suggest that we try to understand why Kerberos couldn't be used in that environment. I suspect in at least some cases what users would like is the ability to do Kerberos auth but then have LDAP checked to see if a given user (who has now auth'd through Kerberos) is allowed to connect. We don't currently have any way to do that, but if we were looking for things to do, that's what I'd suggest working on rather than adding more to our LDAP auth system and implying by doing so that it's reasonable to use.
I find it particularly disappointing to see recommendations for using LDAP auth, particularly in AD environments, that don't even mention Kerberos or bother to explain how using LDAP sends the user's PW to the server in cleartext.
You do realize, I'm sure, that there are many LDAP servers out there that are not AD, and that do not come with a Kerberos server attached to them...
I agree that Kerberos is usually the better choice *if it's available*. It's several orders of magnitude more complicated to set up though, and there are many environments that have ldap but don't have Kerberos.
Refusing to improve LDAP for the users who have no choice seems like a very unfriendly thing to do.
(And you can actually reasonably solve the case of kerberos-for-auth-ldap-for-priv by syncing the groups into postgres roles)