On Mon, Jul 17, 2017 at 1:23 AM, Stephen Frost <sfr...@snowman.net> wrote:
> > * Magnus Hagander (mag...@hagander.net) wrote: > > On Sun, Jul 16, 2017 at 11:05 PM, Stephen Frost <sfr...@snowman.net> > wrote: > > > 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 am aware that some exist, I've even contributed to their development > and packaging, but that doesn't make it a good idea to use them for > authentication. > Pretty sure that doesn't include any of the ones I'm talking about, but sure :) > > I agree that Kerberos is usually the better choice *if it's available*. > > Which is the case in an AD environment.. > Yes. But we shouldn't force everybody to use AD :P > > 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. > > Frankly, I simply don't agree with this. > Really? For LDAP auth I don't need to do *anything* in preparation. For Kerberos auth I need to create an account, set encryption type, export keys, etc. You can't possibly claim this is the same level of complexity? > > Refusing to improve LDAP for the users who have no choice seems like a > very > > unfriendly thing to do. > > I'm fine with improving LDAP in general, but, as I tried to point out, > having a way to make it easier to integrate PG into an AD environment > would be better. It's not my intent to stop this patch but rather to > point out the issues with LDAP auth that far too frequently are not > properly understood. > A documentation patch for that would certainly be a good place to start. Perhaps with up to date instructions for how to actually set up Kerberos in an AD environment including all steps required? > > (And you can actually reasonably solve the case of > > kerberos-for-auth-ldap-for-priv by syncing the groups into postgres > roles) > > Yes, but sync'ing roles is a bit of a pain and it'd be nice if we could > avoid it, or perhaps make it easier. > Certainly. //Magnus
