Hi Jani,
you add more possibility in your response :) .
OpenLDAP slapd configuration is same on Debian 12 and 13 because we use
same package, from same source (we produce our own package which contain
configuration for 100+ institution) ... so I wouldnt point to that
changes. Also packet contain advanced ACL for request to LDAP database.
Connection method ... hmmm that is good question, according SASL
specification it is framework for authentication which support different
authentication methods :
PLAIN
LOGIN
CRAM-MD5
DIGEST-MD5
SCRAM
GSSAPI
SSO
EXTERNAL
ANONYMOUS
OAUTHBEARER / XOAUTH2
In my configuration ldapi:/// is connected to UNIX socket file, which
correctly work from command line.
So ldap:///, ldaps:///, ldapi:/// basically are connection method. :)
(/usr/sbin/slapd -d0 -h ldap:/// ldapi:/// ldaps:/// -u openldap -g
openldap -F /etc/ldap/slapd.d)
My first question is way request finish in ldaps:/// ldap:/// part of
code , and not in SASL (ldapi:///) part of code ? Even configuration
clearly said UseSASL ? If I correctly interpreted
/opt/radiator/radiator/Radius/Ldap.pm, only way to create SASL request
is using
if ($self->{UseSASL}) line 566.
Following your last suggestion i put in configuration follow :
Host /run/slapd/ldapi
and got follow error :
8f235690 Thu Apr 9 15:13:30 2026 415294: DEBUG: Handling with
Radius::AuthLDAP2:
00000000 Thu Apr 9 15:13:30 2026 415662: INFO: AuthLDAP2 Connecting to
/run/slapd/ldapi port 389
00000000 Thu Apr 9 15:13:30 2026 416434: INFO: AuthLDAP2 Connected to
/run/slapd/ldapi port 389
00000000 Thu Apr 9 15:13:30 2026 416785: INFO: AuthLDAP2 Attempting to
bind to LDAP server /run/slapd/ldapi port 389
00000000 Thu Apr 9 15:13:30 2026 417526: ERR: AuthLDAP2 Could not bind
connection with , **obscured**, error: LDAP_STRONG_AUTH_NOT_SUPPORTED
(server /run/slapd/ldapi port 389). SASL error:
00000000 Thu Apr 9 15:13:30 2026 417604: ERR: AuthLDAP2 Backing off
from /run/slapd/ldapi port 389 for 60 seconds.
8f235690 Thu Apr 9 15:13:30 2026 417895: DEBUG: AuthBy LDAP2 result:
IGNORE, User database access error
Then check with :
ldapsearch -Y EXTERNAL -H ldapi:/// -b "" -s base supportedSASLMechanisms
SASL/EXTERNAL authentication started
SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
SASL SSF: 0
# extended LDIF
#
# LDAPv3
# base <> with scope baseObject
# filter: (objectclass=*)
# requesting: supportedSASLMechanisms
#
#
dn:
supportedSASLMechanisms: SCRAM-SHA-512
supportedSASLMechanisms: SCRAM-SHA-384
supportedSASLMechanisms: SCRAM-SHA-256
supportedSASLMechanisms: SCRAM-SHA-224
supportedSASLMechanisms: SCRAM-SHA-1
supportedSASLMechanisms: DIGEST-MD5
supportedSASLMechanisms: EXTERNAL
supportedSASLMechanisms: NTLM
supportedSASLMechanisms: CRAM-MD5
supportedSASLMechanisms: LOGIN
supportedSASLMechanisms: PLAIN
# search result
search: 2
result: 0 Success
# numResponses: 2
# numEntries: 1
So EXTERNAL method is supported.
I will tomorrow try to install everything on plain Debian 12 serve like
i was did for this test and test your suggestion that authentication
wasnt done with SASL, but with plain ldap protocol (even that is true it
is wired that stop working updating same server from version 12 to 13 of
Debian).
Regards,
Dubravko
On 4/9/26 2:19 PM, Jani Lahti wrote:
Hello Dubravko
SASL authentication is an alternative to the default simple
authentication (AuthDN and AuthPassword), it is not a connection method.
Radiator configuration expects the Host clause to have a DNS name or
IP address, not a URL scheme. If Host is omitted, localhost is used as
the default. Similarly, if Port is omitted (in your case, commented
out), default 389 is used (as you saw from the logs).
I haven't tested it, so just a guess: Your old setup may have seemingly
been working ok because on the old setup OpenLDAP server may have been
responding to normal TCP connections on port 389 from localhost,
and somehow this "Host ldapi:///" line (or you had it commented out)
ended up being interpreted as not having a proper Host clause at all =>
use default: localhost.
As far as I know, Radiator doesn't support LDAP over IPC, and if it did
(and if Host accepted the URI notation), you'd need to have the Unix
socket file included in the URI, as Radiator wouldn't know the exact
file path.
//jani
On Thu, 9 Apr 2026 at 09:21, Dubravko Penezic via radiator
<[email protected] <mailto:[email protected]>> wrote:
Hi Hugh,
lets start with possible solutions :
Host ldapi\:\/\/\/
return
00000000 Thu Apr 9 07:43:53 2026 449514: INFO: AuthLDAP2 Connecting to
ldapi\:\/\/\/ port 389
and all other same response.
That clarify that configuration value is passed RADIATOR engine as is
without modification.
Now return to ldapi:/// ...
ldapi:/// (LDAP over IPC) - Instead of using TCP/IP (like ldap:// or
ldaps://), ldapi:/// uses a local socket file, typically located at
/var/run/ldapi or /var/run/openldap/ldapi/.
The ldapi:/// protocol is often used with the SASL EXTERNAL mechanism
EXTERNAL Mechanism: Because the connection is local, the client does
not
need a username or password. The SASL EXTERNAL mechanism allows the
LDAP
server to authenticate the user based on the Unix credentials (user ID,
user Group ID) provided by the operating system kernel.
Usually we use something like :
ldapsearch -h ldapi:/// -Y EXTERNAL -b "cn=config"
ldapvi -h ldapi:/// -Y EXTERNAL -b "cn=config"
Now back to your second suggestion , that wouldnt work by design, but
for complet all test I try also with
Host ldapi://127.0.0.1/ <http://127.0.0.1/>
and got
00000000 Thu Apr 9 07:55:19 2026 279828: ERR: AuthLDAP2 Could not open
LDAP connection to ldapi://127.0.0.1/ <http://127.0.0.1/> port 389.
Backing off for 60 seconds.
I dint try with GlobalVar's because i dont see how that my improve
upper tests.
RADIATOR documentation have follow recomendation :
"Also requires perl-ldap 0.33 and the Authen::SASL 2.09 module, or
later."
I check and both package are install.
For follow have in mind I am not Perl expert ...
I found pattern for error response in /opt/radiator/radiator/Radius/
Ldap.pm
line 410
$self->log($main::LOG_ERR, "$self->{log_class_identifier} Could not
open
LDAP connection to $log_host_port. Backing off for
$self->{FailureBackoffTime} seconds.");
which follow to line 370
$self->{ld} = Net::LDAP->new
($server->{host},
inet6 => $server->{useInet6},
port => $port,
timeout => $self->{Timeout},
version => $self->{Version},
multihomed => $self->{MultiHomed} ? 1 : 0,
localaddr => $localaddr,
);
To me that dosnt look like proper way to connect to LDAP via SASL
Also I found that SASL connection is prepare in line 568 .
On other hand, I dont understand way that was work correctly before and
stop working.
Dubravko
On 4/9/26 3:45 AM, Hugh Irvine wrote:
>
> Hello Dubravko -
>
> It must be your Host declaration that is causing the problem - I
haven't
> seen this before "ldapi:///"
>
> Have you tried with just the IP address?
>
> Otherwise you could try escaping the special characters:
>
> Host ldapi\:\/\/\/
>
> You could also use Radiator GlobalVar's instead.
>
> Please let us know your results.
>
>
> Hugh
>
>
> On 8/4/2026 17:18, Dubravko Penezic wrote:
>> Hi Hugh,
>>
>> configuration is follow :
>>
>> Trace 4
>> LogTraceId
>> LogMicroseconds
>> DbDir /etc/radiator
>> LogDir /var/log/radiator
>> LogFile %L/radiator-test.log
>> AuthPort 1812
>> AcctPort 1813
>> DictionaryFile /opt/radiator/radiator/dictionary
>> <Client 10.10.10.10>
>> Secret PeroPero
>> StatusServer off
>> </Client>
>>
>> <Realm DEFAULT>
>> RewriteUsername s/^(.+)(\.hs@)(mali\.hr)$/$1/i
>> <AuthBy LDAP2>
>> Host ldapi:///
>> # Port
>> Timeout 5
>> FailureBackoffTime 60
>> UseSASL
>> SASLMechanism EXTERNAL
>> BaseDN %0=%1,dc=mali,dc=hr
>> Scope base
>> UsernameAttr uid
>> ServerChecksPassword
>> UnbindAfterServerChecksPassword
>> AuthenProto PAP
>> AuthAttrDef hrEduPersonExpireDate,Connect-Info,reply
>> </AuthBy>
>> </Realm>
>>
>>
>> Debug log output is :
>>
>> 00000000 Wed Apr 8 09:07:55 2026 569528: DEBUG: Radius::JSON
backend
>> is Cpanel::JSON::XS version 4.39
>> 00000000 Wed Apr 8 09:07:55 2026 569652: DEBUG: SCTP socket API
>> extensions not available
>> 00000000 Wed Apr 8 09:07:55 2026 569705: DEBUG: Finished reading
>> configuration file '/etc/radiator/radiator-test.conf'
>> 00000000 Wed Apr 8 09:07:55 2026 729564: DEBUG: Radius::JSON
backend
>> is Cpanel::JSON::XS version 4.39
>> 00000000 Wed Apr 8 09:07:55 2026 729669: DEBUG: SCTP socket API
>> extensions not available
>> 00000000 Wed Apr 8 09:07:55 2026 729718: DEBUG: Finished reading
>> configuration file '/etc/radiator/radiator-test.conf'
>> 00000000 Wed Apr 8 09:07:55 2026 729860: DEBUG: Reading RADIUS
>> dictionary file '/opt/radiator/radiator/dictionary'
>> 00000000 Wed Apr 8 09:07:55 2026 797863: INFO: Using
Net::SSLeay 1.94
>> with SSL/TLS library version 0x30500050 (OpenSSL 3.5.5 27 Jan 2026)
>> 00000000 Wed Apr 8 09:07:55 2026 797949: DEBUG: SSL/TLS library
and
>> Net::SSLeay support set_default_passwd_cb and related functions
>> 00000000 Wed Apr 8 09:07:55 2026 798061: DEBUG: This system is
IPv6
>> capable. IPv6 capability provided by: core
>> 00000000 Wed Apr 8 09:07:55 2026 798171: WARNING: Startup check
could
>> not load Radius::UtilXS or Digest::MD4. See Radiator reference
manual
>> for DisabledRuntimeChecks parameter
>> 00000000 Wed Apr 8 09:07:55 2026 798283: DEBUG: Creating
>> authentication socket 0.0.0.0 port 1812
>> 00000000 Wed Apr 8 09:07:55 2026 798423: DEBUG: Creating
accounting
>> socket 0.0.0.0 port 1813
>> 00000000 Wed Apr 8 09:07:55 2026 798529: NOTICE: Server started:
>> Radiator 4.30 on pero.mali.hr <http://pero.mali.hr>
>> 51c516c0 Wed Apr 8 09:08:22 2026 962489: DEBUG: Packet dump:
>> 51c516c0 *** Received from 10.10.10.10 port 48750 ....
>> 51c516c0 Code: Access-Request
>> 51c516c0 Identifier: 135
>> 51c516c0 Authentic:
>> [<131><191><178>[<28><17><151><135><235>|)<205>W<249><189>
>> 51c516c0 Attributes:
>> 51c516c0 Message-Authenticator =
>> <150><131><133>zb<237><131>+y<230><178><8>x<171><158>H
>> 51c516c0 User-Name = "[email protected] <mailto:[email protected]>"
>> 51c516c0 User-Password =
>> ji<155><5>)<194><206><143><152><176><223>(6<148><226><134>
>>
>> 51c516c0 Wed Apr 8 09:08:22 2026 962720: DEBUG: Handling
request with
>> Handler 'Realm=DEFAULT', Identifier ''
>> 51c516c0 Wed Apr 8 09:08:22 2026 964567: DEBUG: Rewrote user
name to
>> [email protected] <mailto:[email protected]>
>> 51c516c0 Wed Apr 8 09:08:22 2026 964699: DEBUG: SessINTERNAL:
>> Deleting session for [email protected] <mailto:[email protected]>,
161.53.2.218,
>> 51c516c0 Wed Apr 8 09:08:22 2026 964785: DEBUG: Handling with
>> Radius::AuthLDAP2:
>> 00000000 Wed Apr 8 09:08:22 2026 964943: INFO: AuthLDAP2
Connecting
>> to ldapi:/// port 389
>> 00000000 Wed Apr 8 09:08:22 2026 965184: ERR: AuthLDAP2 Could not
>> open LDAP connection to ldapi:/// port 389. Backing off for 60
seconds.
>> 51c516c0 Wed Apr 8 09:08:22 2026 965264: DEBUG: AuthBy LDAP2
result:
>> IGNORE, User database access error
>> 51c516c0 Wed Apr 8 09:08:22 2026 965349: DEBUG: Access ignored for
>> [email protected] <mailto:[email protected]>: User database access error
>>
>> I did small redacted action on conf and log , but only on IP
address,
>> username parts.
>>
>> From my point of view, RADIATOR code isnt able to connect to local
>> LDAP service using SASL , dosnt meter what request contain. Bu I
may
>> be wrong.
>>
>> Dubravko
>>
>>
>> On 4/8/26 7:37 AM, Dubravko Penezic via radiator wrote:
>>> Hi Hugh,
>>>
>>> indirectly you give very good advice :) ... try with clean
>>> configuration .
>>>
>>> I have relatively complex configuration across multiple files and
>>> some Perl codes, so it is somehow hard to do proper redact.
However
>>> it is very easy for me to create simple clean example for test.
>>>
>>> I will do that today and send findings and configuration.
>>>
>>> Dubravko
>>>
>>> On 4/8/26 2:01 AM, Hugh Irvine wrote:
>>>>
>>>> Hello Dubravko -
>>>>
>>>> Could you please send us a redacted copy of the configuration
file?
>>>>
>>>> I've not seen a connection string like the one you show below?
>>>>
>>>>
>>>> Hugh
>>>>
>>>>
>>>> On 7/4/2026 23:48, Dubravko Penezic via radiator wrote:
>>>>> Hi,
>>>>>
>>>>> few days ago we change from Debian 12 to Debian 13 , and working
>>>>> configuration of RADIATOR 4.30-1 stop working on part that
connect
>>>>> to LDAP (OpenLDAP) service on same server.
>>>>>
>>>>> Error is as following :
>>>>>
>>>>> 00b6e9f0 Tue Apr 7 15:38:58 2026 533634: DEBUG: Handling with
>>>>> Radius::AuthLDAP2:
>>>>> 00000000 Tue Apr 7 15:38:58 2026 533789: INFO: AuthLDAP2
>>>>> Connecting to ldapi:/// port 389
>>>>> 00000000 Tue Apr 7 15:38:58 2026 534044: ERR: AuthLDAP2
Could not
>>>>> open LDAP connection to ldapi:/// port 389. Backing off for 60
>>>>> seconds.
>>>>>
>>>>> I did check slapd configuration end check ldapi:/// EXTERNAL
>>>>> authentication from command line, and impersonate like radiator
>>>>> user everything work correctly , "only" RADIATOR is not able to
>>>>> connect.
>>>>>
>>>>> Any idea ? or debugging options ?
>>>>>
>>>>>
>>>>> Dubravko Penezic
>>>>>
>>>>> Srce
_______________________________________________
radiator mailing list
[email protected]
https://lists.open.com.au/mailman/listinfo/radiator
