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
