Re: More flexible LDAP auth search filters?

On Mon, Jul 17, 2017 at 1:23 AM, Stephen Frost <sfrost(at)snowman(dot)net> wrote:

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