> I'm wondering if I missed something or if there was an oversight in the implementation of this RFC, specifically regarding the CLDAP case:
> https://git.openldap.org/openldap/openldap/-/commit/2ae62e86bc8ffab713fc4897f38461c31f2c79a8
>
cldap doesn't support authentication or authorization of any kind. Just add "-x" to your ldapsearch invocation.
Hi Howard,
Thanks!
When I try that, it just leads to another issue which happens on all of the versions (old and new).
The bind is successful (at least it says that), but then the search hangs (and in the server's logs, I see no activity at all):
# ldapsearch -d 7 -x -LL -H cldap://
server.example.com -b '' -s base 'dc=example,dc=com' "(&(DnsDomain='dc=example,dc=com')(NtVer=\x06\x00\x00\x00)(AAC=\x00\x00\x00\x00))"
ldap_url_parse_ext(cldap://
server.example.com)
ldap_create
ldap_url_parse_ext(cldap://
server.example.com:389/??base)
ldap_sasl_bind
ldap_send_initial_request
ldap_new_connection 1 1 0
ldap_int_open_connection
ldap_connect_to_host: UDP
server.example.com:389 ldap_new_socket: 3
ldap_prepare_socket: 3
ldap_connect_to_host: Trying
10.0.138.111:389 ldap_open_defconn: successful
ldap_result ld 0x55b16e5b5680 msgid 0
wait4msg ld 0x55b16e5b5680 msgid 0 (infinite timeout)
wait4msg continue ld 0x55b16e5b5680 msgid 0 all 1
** ld 0x55b16e5b5680 Connections:
* host:
server.example.com port: 389 (default)
refcnt: 1 status: Connected
ldap_chkResponseList ld 0x55b16e5b5680 msgid 0 all 1
ldap_chkResponseList returns ld 0x55b16e5b5680 NULL
ldap_int_select
So I wonder if some code path for CLDAP is broken or if we may have some misconfiguration on our side.
I'd really appreciate any thoughts on this.
Thanks!
Kind Regards,
SImon
> Looking forward to your thoughts!
>
> Best Regards,
> Simon
>
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/