Hi folks, I am currently experiencing an issue with IPA Server set up on Fedora 36, using ipa-adtrust-install, and I'm unsure if this is due to a bug or misconfiguration on my part.
Here's what I've done:
I ran the following ldapsearch command:
ldapsearch -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))"
On OpenLDAP 2.4.46, it was working fine, and it gave an output. But OpenLDAP 2.6.2 and 2.6.4 fails with No such object (32) error.
I used gdb to investigate and found that the error occurred here: https://git.openldap.org/openldap/openldap/-/blob/master/clients/tools/commo...
It executes ldap_sasl_interactive_bind, but it exits right in the beginning: https://git.openldap.org/openldap/openldap/-/blob/master/libraries/libldap/s...
So back at: https://git.openldap.org/openldap/openldap/-/blob/master/clients/tools/commo... It exists the do-while loop right away and leaves with no result.
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/2ae62e86bc8ffab713fc4897...
Looking forward to your thoughts!
Best Regards, Simon
Simon Pichugin wrote:
Hi folks, I am currently experiencing an issue with IPA Server set up on Fedora 36, using ipa-adtrust-install, and I'm unsure if this is due to a bug or misconfiguration on my part.
Here's what I've done:
I ran the following ldapsearch command:
ldapsearch -LL -H cldap://server.example.com http://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))"
On OpenLDAP 2.4.46, it was working fine, and it gave an output. But OpenLDAP 2.6.2 and 2.6.4 fails with No such object (32) error.
I used gdb to investigate and found that the error occurred here: https://git.openldap.org/openldap/openldap/-/blob/master/clients/tools/commo...
It executes ldap_sasl_interactive_bind, but it exits right in the beginning: https://git.openldap.org/openldap/openldap/-/blob/master/libraries/libldap/s...
So back at: https://git.openldap.org/openldap/openldap/-/blob/master/clients/tools/commo... It exists the do-while loop right away and leaves with no result.
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/2ae62e86bc8ffab713fc4897...
cldap doesn't support authentication or authorization of any kind. Just add "-x" to your ldapsearch invocation.
Looking forward to your thoughts!
Best Regards, Simon
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/2ae62e86bc8ffab713fc4897...
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 last used: Wed Dec 31 19:00:00 1969
** ld 0x55b16e5b5680 Outstanding Requests: Empty ld 0x55b16e5b5680 request count 0 (abandoned 0) ** ld 0x55b16e5b5680 Response Queue: Empty ld 0x55b16e5b5680 response count 0 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/
openldap-technical@openldap.org
-
Howard Chu -
Simon Pichugin