From: | Stephen Frost <sfrost(at)snowman(dot)net> |
---|---|
To: | Magnus Hagander <magnus(at)hagander(dot)net> |
Cc: | Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: More flexible LDAP auth search filters? |
Date: | 2017-07-16 21:05:17 |
Message-ID: | 20170716210517.GT1769@tamriel.snowman.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Magnus, all,
* Magnus Hagander (magnus(at)hagander(dot)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.
Thanks!
Stephen
From | Date | Subject | |
---|---|---|---|
Next Message | Magnus Hagander | 2017-07-16 21:08:40 | Re: More flexible LDAP auth search filters? |
Previous Message | Greg Stark | 2017-07-16 20:27:32 | Re: Something for the TODO list: deprecating abstime and friends |