[RADIATOR] UNS: Re: Issue with LDAP and SASL authentication
Dubravko Penezic
dpenezic at srce.hr
Thu Apr 9 16:04:15 UTC 2026
Hi Jani,
just another info Debian 11, RADIATOR 4-30-1 , basically same LDAP
configuration , and RADIATOR configuration return follow :
b7fa40b0 Thu Apr 9 17:56:49 2026 921045: DEBUG: Handling with
Radius::AuthLDAP2:
00000000 Thu Apr 9 17:56:49 2026 921206: INFO: AuthLDAP2 Connecting to
ldapi:/// port 389
00000000 Thu Apr 9 17:56:49 2026 921834: INFO: AuthLDAP2 Connected to
ldapi:/// port 389
00000000 Thu Apr 9 17:56:49 2026 921983: INFO: AuthLDAP2 Attempting to
bind to LDAP server ldapi:/// port 389
b7fa40b0 Thu Apr 9 17:56:49 2026 923089: ERR: AuthLDAP2 LDAP search for
(uid=test) failed with error LDAP_NO_SUCH_OBJECT
b7fa40b0 Thu Apr 9 17:56:49 2026 923176: DEBUG: Radius::AuthLDAP2 looks
for match with 'test' [test at pero.hr]
b7fa40b0 Thu Apr 9 17:56:49 2026 923232: DEBUG: Radius::AuthLDAP2
REJECT: No such user: 'test' [test at pero.hr]
If I interpreted log correctly RADIATOR did connect to ldapi:/// , do
search and correctly return that user dosnt exist.
Regards,
Dubravko
On 4/9/26 3:25 PM, Dubravko Penezic via radiator wrote:
> 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
>> <radiator at lists.open.com.au <mailto:radiator at lists.open.com.au>> 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 = "pero at mali.hr <mailto:pero at mali.hr>"
>> >> 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
>> >> pero at mali.hr <mailto:pero at mali.hr>
>> >> 51c516c0 Wed Apr 8 09:08:22 2026 964699: DEBUG: SessINTERNAL:
>> >> Deleting session for pero at mali.hr <mailto:pero at mali.hr>,
>> 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
>> >> pero at mali.hr <mailto:pero at mali.hr>: 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
> radiator at lists.open.com.au
> https://lists.open.com.au/mailman/listinfo/radiator
More information about the radiator
mailing list