Обсуждение: pgsql: Allow ldaps when using ldap authentication
Allow ldaps when using ldap authentication While ldaptls=1 provides an RFC 4513 conforming way to do LDAP authentication with TLS encryption, there was an earlier de facto standard way to do LDAP over SSL called LDAPS. Even though it's not enshrined in a standard, it's still widely used and sometimes required by organizations' network policies. There seems to be no reason not to support it when available in the client library. Therefore, add support when using OpenLDAP 2.4+ or Windows. It can be configured with ldapscheme=ldaps or ldapurl=ldaps://... Add tests for both ways of requesting LDAPS and a test for the pre-existing ldaptls=1. Modify the 001_auth.pl test for "diagnostic messages", which was previously relying on the server rejecting ldaptls=1. Author: Thomas Munro Reviewed-By: Peter Eisentraut Discussion: https://postgr.es/m/CAEepm=1s+pA-LZUjQ-9GQz0Z4rX_eK=DFXAF1nBQ+ROPimuOYQ@mail.gmail.com Branch ------ master Details ------- https://git.postgresql.org/pg/commitdiff/35c0754fadca8010955f6b10cb47af00bdbe1286 Modified Files -------------- configure | 11 ++++++++ configure.in | 1 + doc/src/sgml/client-auth.sgml | 50 ++++++++++++++++++++++++++--------- src/backend/libpq/auth.c | 59 ++++++++++++++++++++++++++++++++++++----- src/backend/libpq/hba.c | 16 +++++++++++- src/include/libpq/hba.h | 1 + src/include/pg_config.h.in | 3 +++ src/test/ldap/t/001_auth.pl | 61 ++++++++++++++++++++++++++++++++++++++++--- 8 files changed, 178 insertions(+), 24 deletions(-)
On Thu, Jan 4, 2018 at 4:14 AM, Peter Eisentraut <peter_e@gmx.net> wrote: > Allow ldaps when using ldap authentication Other Windows systems seem OK with this, but baiji said: .\src\backend\libpq\auth.c(2538): error C2065: 'LDAPS_PORT' : undeclared identifier Checking where that's supposed to come from... -- Thomas Munro http://www.enterprisedb.com
On Thu, Jan 4, 2018 at 9:07 AM, Thomas Munro <thomas.munro@enterprisedb.com> wrote: > On Thu, Jan 4, 2018 at 4:14 AM, Peter Eisentraut <peter_e@gmx.net> wrote: >> Allow ldaps when using ldap authentication > > Other Windows systems seem OK with this, but baiji said: > > .\src\backend\libpq\auth.c(2538): error C2065: 'LDAPS_PORT' : > undeclared identifier > > Checking where that's supposed to come from... Windows documentation talks about LDAP_SSL_PORT instead. I assume that "Vista Ultimate 6.0.6000 MSVC 2005 Pro 8.0.50727.867" doesn't define LDAPS_PORT, but some later version added it for compatibility with OpenLDAP. Let's just define it ourselves if it's undefined as we did for some other LDAP macros, since its value is well known (it's an IANA-registered port). See attached. While poking around in the documentation, I came across this surprising sentence[1]: "Be aware that even if the secure parameter is set to zero, if the PortNumber parameter is set to LDAP_SSL_PORT (636) or to LDAP_SSL_GC_PORT (3269), an encrypted session is initiated." Huh. That wasn't mentioned on the main page for the function[2] and I don't like it, because it means that the same connection string could have a different meaning on Windows and Unix. So I also propose that we also tweak the code to prevent that. I don't have a Windows system myself, but this builds OK on Appveyor CI. [1] https://msdn.microsoft.com/en-us/library/aa367031(v=vs.85).aspx [2] https://msdn.microsoft.com/en-us/library/aa366996(v=vs.85).aspx -- Thomas Munro http://www.enterprisedb.com
Вложения
On 1/3/18 16:24, Thomas Munro wrote: > Windows documentation talks about LDAP_SSL_PORT instead. I assume > that "Vista Ultimate 6.0.6000 MSVC 2005 Pro 8.0.50727.867" doesn't > define LDAPS_PORT, but some later version added it for compatibility > with OpenLDAP. Let's just define it ourselves if it's undefined as we > did for some other LDAP macros, since its value is well known (it's an > IANA-registered port). See attached. > > While poking around in the documentation, I came across this > surprising sentence[1]: "Be aware that even if the secure parameter is > set to zero, if the PortNumber parameter is set to LDAP_SSL_PORT (636) > or to LDAP_SSL_GC_PORT (3269), an encrypted session is initiated." > Huh. That wasn't mentioned on the main page for the function[2] and > I don't like it, because it means that the same connection string > could have a different meaning on Windows and Unix. So I also propose > that we also tweak the code to prevent that. pushed -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services