On May 21, 2021, at 6:58 PM, Michael Ströder via Freeradius-Users <freeradius-users@lists.freeradius.org> wrote:
But with 3.0.22 every now and then it does not work anymore. Restarting radiusd "fixes" it for some time. Unfortunately I did not find a way to easily reproduce it.
In syslog I see these messages (first line is the last good case before failure):
2021-05-21T17:24:13.571211+00:00 ap1 radiusd[1728]: (13) Login OK: [miwi] (from client localhost port 1 cli 84-EF-18-F7-9E-6E) 2021-05-21T18:18:31.765761+00:00 ap1 radiusd[1728]: (20) Invalid user (ldap: Bind with (anonymous) to ldaps://ae-dir.hv.local:636 failed: Local error): [miwi] (from client localhost port 0 via TLS tunnel) 2021-05-21T18:18:31.772668+00:00 ap1 radiusd[1728]: (20) Login incorrect (ldap: Bind with (anonymous) to ldaps://ae-dir.hv.local:636 failed: Local error): [miwi] (from client localhost port 0 via TLS tunnel) 2021-05-21T18:18:31.775870+00:00 ap1 radiusd[1728]: (20) Login incorrect (eap: Failed continuing EAP TTLS (21) session. EAP sub-module failed): [miwi] (from client localhost port 1 cli 84-
From the above I suspect radiusd does not properly properly reconnect as configured with SASL/EXTERNAL bind (using its EAP-TLS server cert as client cert) probably after reaching idle connection timeout. Instead it seems to use an anonymous bind.
Weird.
Any clue what's going on here?
Not sure. The only changes to rlm_ldap between 3.0.21 and 3.0.22 are to add configuration items which set tls_min_version. Everything else is unchanged. Alan DeKok.