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.
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
Das ganze sollte natĂĽrlich wieder entfernt werden, sobald das Problem richtig von Univention addressiert wurde - aber aktuell funktioniert es zumindest fĂĽr uns.
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:
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.
Könnte es vielleicht sein, dass dem User freerad nicht erlaubt ist anfragen zu stellen?
Sonst wĂĽrde ja die Nutzung im Debug-Modus ja auch nicht funktionieren!
Habe das selbe Problem nach dem Update auf die neueste Version.
LG
mittles systemctl edit freeradius funktioniert, scheint es sich um ein Berechtigungsproblem (Zugriff auf bestimmte Dateien) zu handeln.
Welche Dateien das genau sind könnte man evtl. mittels aktivem auditd versuchen zu ermitteln.
Da fĂĽr mich der beschriebene Workaround funktioniert, habe ich vorerst nicht weiter geforscht. Ich hoffe erstmal weiterhin auf einen Fix seitens UCS
I just experienced this problem after updating. For me in the /etc/freeradius/3.0/ directory some files, directories, symlinks had had their permissions updated to root:root instead of the freeradius user and group which explains why running freeradius -X works as root but not as the freeradius service/user.
I CD’d to that directory and just ran chown freerad:freerad on each file and directory that was set up with root as owner or group and then restarted freeradius and that solved my problem.
A change to the service is not normally necessary. I checked the file permissions. One file had incorrect permissions. After correcting this, radius worked normally again.
I don’t have this file /etc/freeradius/3.0/ldap-groups-attrs.conf and therefore I can’t confirm that this solves the problem too. But for sure it’s a permission problem (AmbientCapabilities=CAP_DAC_OVERRIDE should allow ignoring the permissions - for this reason it works if set, even if the permissions are not set correctly).
Could anyone show up, what the permissions for the files in the folder /etc/freeradius/3.0/ should be?
My folder looks like this:
:~# ls -l /etc/freeradius/3.0/
insgesamt 208
drwxr-xr-x 2 freerad freerad 4096 22. Feb 17:45 certs
-rw-r----- 1 freerad freerad 8010 23. Feb 16:52 clients.conf
-rw-r----- 1 freerad freerad 8323 19. Aug 2023 clients.conf.dpkg-dist
-rw-r--r-- 1 root root 1408 27. Feb 2019 clients.conf.example
-rw------- 1 freerad root 361 22. Feb 18:01 clients.univention.conf
-rw-r----- 1 freerad freerad 1420 19. Aug 2023 dictionary
-rw-r----- 1 freerad freerad 2661 27. Nov 2017 experimental.conf
lrwxrwxrwx 1 root root 28 19. Aug 2023 hints -> mods-config/preprocess/hints
lrwxrwxrwx 1 root root 33 19. Aug 2023 huntgroups -> mods-config/preprocess/huntgroups
drwxr-xr-x 2 freerad freerad 4096 25. Mai 05:55 mods-available
drwxr-xr-x 11 freerad freerad 4096 22. Feb 17:45 mods-config
drwxr-xr-x 2 freerad freerad 4096 8. Mär 11:23 mods-enabled
-rw-r----- 1 freerad freerad 52 27. Nov 2017 panic.gdb
drwxr-xr-x 2 freerad freerad 4096 22. Feb 17:51 policy.d
-rw-r----- 1 root freerad 488 22. Feb 17:51 proxy.conf
-rw-r----- 1 freerad freerad 29206 19. Aug 2023 proxy.conf.debian
-rw-r----- 1 root freerad 31470 22. Feb 18:01 radiusd.conf
-rw-r----- 1 freerad freerad 30773 19. Aug 2023 radiusd.conf.debian
-rw-r----- 1 freerad freerad 20754 19. Aug 2023 README.rst
drwxr-xr-x 2 freerad freerad 4096 22. Feb 17:51 sites-available
drwxr-xr-x 2 freerad freerad 4096 22. Feb 17:44 sites-enabled
-rw-r----- 1 freerad freerad 3470 27. Nov 2017 templates.conf
-rw-r----- 1 freerad freerad 8536 27. Nov 2017 trigger.conf
lrwxrwxrwx 1 root root 27 19. Aug 2023 users -> mods-config/files/authorize
