Il 13/09/2023 13:45 CEST Alan DeKok <aland@deployingradius.com> ha scritto: The rlm_ldap module talks to the LDAP server via libldap. i.e. FreeRADIUS asks libldap to contact, the LDAP server, and libldap says "no".
Thanks Alan, your explaination led me to: "... ldapsearch is linked to GnuTLS and not OpenSSL..." (reference: https://kb.checkmk.com/pages/viewpage.action?pageId=17471579)
One thing which might help is to read mods-available/ldap, and look at the "ldap_debug" flag. Thanks, good clue! The full libldap debug revealed some unexpected errors and this one led me to the solution (or at least to a workaround): ...TLS: peer cert untrusted or revoked (0x42)
What I'm guessing is: 1- ldapsearch uses the debian certificates store, then it finds our internal CA root Certificate there, and it can trust the LDAP Server Certificate 2- libldap does not use the system certificates Store by default (does freeradius let set/send any parameter to overcome this behaviour?). The workaround I applied: expliciting, in mods-enabled/ldap, tls section: ca_file = /usr/share/ca-certificates/mozilla/ADCArootCert.crt My question: Given that the tls section states: "# The StartTLS operation is supposed to be used with normal ldap connections instead of using ldaps (port 636) connections", BUT I'm using LDAPS, should I fear random, unforeseeable behaviour from freeradius? Hm... rethinking it, if the "behaviour" comes from libldap it's possible that you are not able to know it for sure.
Checked: "-h" does not exist in ldapsearch 2.5.13
Well, we didn't write ldapsearch, and they don't notify us when their tools change. Of course, please just take my note as a suggestion to improve the documentation.
Thanks again, Pietro.