Hi Dan,
>> 'seems enabling LDAPS introduces lots of compatibility problems, huhhh
hmm, at least with the Novell LDAP SDK (which is 99% OpenLDAP) I currently dont see them;
and since the Novell SDK is free and available for every platform this isnt that bad;
also for Win32 this makes ldaps possible without headaches....

> Is LDAPS just regular LDAP running on top of SSL/TLS, in the same way as
> HTTPS is to HTTP? Or is it like the FTP with the --ftp-ssl option or
> SSL telnet where an LDAP negotiation takes place before SSL is enabled?
I cant tell you fore sure how it internally works...

> If
> the former, then surely we can use libcurl's already portable SSL back-end
> components to negotiate SSL over the socket before handing it to OpenLDAP
> to do the LDAP stuff. It sounds like that could simplify the LDAPS code
> at the same time as allowing the use of all the different SSL libraries
> already supported by curl.
AFAICT when the LDAP libraries use SSL then they do it internally,
and there's no need to either include non-ldap SSL headers, nor non-ldap SSL libraries...
however on Win32 I found that the Novell LDAP DLLs depend on gsskrb5.dll which is included in the SDK;
but no other gss headers were needed; I guess this dependency is because Novell uses the kerberos stuff for PW encrytion or such...; but as said before such doesnt matter since no need to link against non-ldap libs.

> I suspect that using the LDAP library's LDAPS support will introduce
> problems
> when LDAP is compiled to use one SSL library (e.g. OpenSSL) while libcurl
> is compiled to use another (e.g. yaSSL), with symbol clashes, etc.
nope, no probs; all symbols are prefixed with 'ldap_', no symbol clashes;
tested that on NetWare and Win32, and this _should_ be same on Linux too.

Guen.
Received on 2007-08-16