On Mon, Jul 17, 2017 at 1:23 AM, Stephen Frost <sfrost@snowman.net> wrote:
* Magnus Hagander (magnus@hagander.net) wrote: > On Sun, Jul 16, 2017 at 11:05 PM, Stephen Frost <sfrost@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.