Problems with Freeradius auth after upgrading to 5.2.0

UCS - Univention Corporate Server
,
1

I recently (yesterday) upgraded from UCS 5.0.9 to 5.2.0 and since then freeradius seems to have some problem.
When freeradius is started via systemd (or the WebUI) and I try to authenticate a wireless device, I get the following error in the radius.log:

*Sun Feb 23 17:24:53 2025 : ERROR: (33) mschap: ERROR: Program returned code (1) and output ''*
*Sun Feb 23 17:24:53 2025 : Auth: (33)   Login incorrect (mschap: Program returned code (1) and output ''): [username/<via Auth-Type = eap>] (from client AP_name port 0 via TLS tunnel)*
*Sun Feb 23 17:24:53 2025 : Auth: (34) Login incorrect (eap_peap: The users session was previously rejected: returning reject (again.)): [username/<via Auth-Type = eap>] (from client AP_name port 1 cli 80-86-D9-4B-F8-16)*
(username and AP_name are vars for the obfuscated original values)

When I stop freeradius (via systemd) and start it manually by freeradius -f,
everything works like a charm and all my clients are authenticated.

When freeradius is started (doesn’t matter which way), I get the following output:
ber_get_next failed, errno=11.

When starting with systemd, the output of systemctl status freeradius.service looks like:

â—Ź freeradius.service - FreeRADIUS multi-protocol policy server
     Loaded: loaded (/lib/systemd/system/freeradius.service; enabled; preset: enabled)
     Active: active (running) since Sun 2025-02-23 17:33:50 CET; 5min ago
       Docs: man:radiusd(8)
             man:radiusd.conf(5)
             http://wiki.freeradius.org/
             http://networkradius.com/doc/
    Process: 630277 ExecStartPre=/usr/sbin/freeradius $FREERADIUS_OPTIONS -Cx -lstdout (code=exited, status=0/SUCCESS)
   Main PID: 630278 (freeradius)
     Status: "Processing requests"
      Tasks: 6 (limit: 9432)
     Memory: 89.2M (limit: 2.0G)
        CPU: 1.217s
     CGroup: /system.slice/freeradius.service
             └─630278 /usr/sbin/freeradius -f

Feb 23 17:33:50 hostname freeradius[630277]: Compiling Post-Auth-Type REJECT for attr Post-Auth-Type
Feb 23 17:33:50 hostname freeradius[630277]: Compiling Autz-Type Status-Server for attr Autz-Type
Feb 23 17:33:50 hostname freeradius[630277]: radiusd: #### Skipping IP addresses and Ports ####
Feb 23 17:33:50 hostname freeradius[630277]: Configuration appears to be OK
Feb 23 17:33:50 hostname freeradius[630278]: ber_get_next failed, errno=11.
Feb 23 17:33:50 hostname freeradius[630278]: ber_get_next failed, errno=11.
Feb 23 17:33:50 hostname freeradius[630278]: ber_get_next failed, errno=11.
Feb 23 17:33:50 hostname freeradius[630278]: ber_get_next failed, errno=11.
Feb 23 17:33:50 hostname freeradius[630278]: ber_get_next failed, errno=11.
Feb 23 17:33:50 hostname systemd[1]: Started freeradius.service - FreeRADIUS multi-protocol policy server.

As a workaround (in order to keep my users connected) I start freeradius manually by issuing: freeradius -f &
This way everything seems to work.

The problem appeared after the upgrade to 5.2.0. All packages are up2date.

Maybe someone got similar problems and has a hint for me.
Thanks in advance.

2

Thanks for your solution with the start mode of freeradius.

I can confirm the same behaviour here, connecting isn’t possible, but when freeradius is started manually from the CLI freeradius -f & it works.

Error log:

Mon Feb 10 08:35:35 2025 : ERROR: (1664) mschap: ERROR: Program returned code (1) and output ''
Mon Feb 10 08:35:35 2025 : Auth: (1664)   Login incorrect (mschap: Program returned code (1) and output ''): [USERNAME/<via Auth-Type = eap>] (from client zar2 port 0 via TLS tunnel)
Mon Feb 10 08:35:35 2025 : Auth: (1665) Login incorrect (eap_peap: The users session was previously rejected: returning reject (again.)): [USERNAME/<via Auth-Type = eap>] (from client zar2 port 406115 cli 2c-33-58-4e-12-95)
3

Hallo!
Wir haben das selbe Problem, es scheint an einem Schutzmechnismus von der systemd Unit-File zu liegen. Ich bin jetzt leider nicht dazugekommen, herauszubekommen, welcher oder warum - aber hier unser Workaround:

  • systemctl edit freeradius
### Anything between here and the comment below will become the new contents of the file"
[Service]
NoNewPrivileges=false
PrivateTmp=false
ProtectControlGroups=false
ProtectKernelModules=false
ProtectKernelTunables=false
SystemCallArchitectures=
ReadOnlyDirectories=
ReadWriteDirectories=
AmbientCapabilities=
MemoryLimit=infinity
### Lines below this comment will be discarded
  • systemctl stop freeradius.service && systemctl start freeradius

Das ganze sollte natĂĽrlich wieder entfernt werden, sobald das Problem richtig von Univention addressiert wurde - aber aktuell funktioniert es zumindest fĂĽr uns.

LG

1 Like
4

Thank you for your hint.
I’ve tested a bit with the different options and values and came to the conclusion, that already

AmbientCapabilities=CAP_DAC_OVERRIDE

solves the problem. So the rest of the options could be left with default settings.
So it could be a permission problem when starting freeradius via systemd.

During various service-restarts I noticed the following messages:

Mär 17 12:08:51 hostname freeradius[2606397]: Configuration appears to be OK
Mär 17 12:08:51 hostname freeradius[2606398]: ber_get_next failed, errno=11.
Mär 17 12:08:51 hostname freeradius[2606398]: ber_get_next failed, errno=11.
Mär 17 12:08:51 hostname freeradius[2606398]: ber_get_next failed, errno=11.
Mär 17 12:08:51 hostname freeradius[2606398]: ber_get_next failed, errno=11.
Mär 17 12:08:51 hostname freeradius[2606398]: ber_get_next failed, errno=11.
Mär 17 12:08:51 hostname systemd[1]: Started freeradius.service - FreeRADIUS multi-protocol policy server.

and

Unit uses MemoryLimit=; please use MemoryMax= instead. Support for MemoryLimit= will be removed soon.

The first one showed up even if freeradius was started manually. The seconed one is more of an information about an upcoming change.
So both of them shouldn’t have to do with the problem itself.

2 Likes