As we’re trying to replace an ancient LDAP server, and at the same time add some functionality, I looked into UCS. Got everything working so far, including replication. But trying to use Radius authentication from our FortiGate firewall, I noticed UCS doesn’t have an up-to-date FreeRadius available, but only 3.2.1. This version does not contain the BlastRadius fix with the message-authenticator returned, which prevents current FortiGate OS authentication from working. Is there any plan on providing a fixed version?
I started installing an official FreeRadius release (3.2.8), but am still running into some problems; also, I’m not sure whether UCS will continue working with the official release (instead of the outdated Debian one)
OK, did some more fiddling with the files … seems like one can get the official 3.2.8 to work with UCS in general by just using all of the config files from the old version, and adding the lines for Message-Authenticator/Proxy in the radiusd.conf and client.univention.conf. Will need to do some more checks on how the files are messed up if any changes are made through the web gui, but for now, at least, I can get it to work.
Anyway, shout out to the Univention folks - the BlastRadius bug has been out a while, as has freeradius 3.2.4 and newer … if you want your system to be usable as a radius source for patched, current systems, you may want to look into fixing this on your side of the software …
Hey @GarryG
We’ve been having the same problem for a few months now (RADIUS No Message-Authenticator attribute / BlastRADIUS vulr) Strangely enough, the Fortigate does auth users even with the “No Message Auth” error.
I would be really interested to see what you’ve done to fix this.
The change in FortiGate about Radius requiring the message auth field filled only applies to newer patches (read: all of the current releases) of FortiOS.
Basically, what I did was install the official freeradius release 3.2.8 from the FreeRadius repository, then replaced the new config files with the original from the UCS distribution, which worked fine (UCS still has the 3.2.1 release). After that, the FortiGate Radius auth worked flawlessly without any warnings or errors.
So, clients.univention.conf just had this line added:
require_message_authenticator = true
(not sure if it will survive updates through the GUI, though) and the same line in the security section of the radiusd.conf. Also added
limit_proxy_state = auto
which I also found in some docs, not sure if it is required or not.
You say version 3.2.8 from freeradius repo… I’m struggling to find this.
Bookworm backports have only v 3.2.1
OK, so I made some progress. I got the Network Radius source added and managed to install the Freeradius 3.2.8, great…
This version has its settings stored in /etc/freeradius while UCS freeradius uses /etc/freeradius/3.0 (with some ssl sitting in the original location).
UCR does not reference the /freeradius/3.0 path so we might be safe there.
Did a test installation on our secondary server and you are right, it does work.
I’m assuming that because of the Pin-Priority: 999 suggested for Network RADIUS repo any updates coming from UCS would get ignored. We will run it for a few days to see if there’s any unexpected behaviour.
(Disclosure: I’m not using FreeRADIUS on UCS these days)
The thing is that this bugfix hasn’t been backported to Debian 12, that’s what usually happens for security and critical fixes within a stable release of Debian. Since UCS 5.2 is based on Debian 12, that’s what Univention ships first. It’s only with Debian 13 / trixie that the bug is properly addressed:
- https://security-tracker.debian.org/tracker/CVE-2024-3596
- https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1076022
I’d say OP means the packages from InkBridge Networks, the company where the core developers of FreeRADIUS are employed.
But keep in mind that while the configuration should remain compatible within FreeRADIUS 3.2.x, you are basically replacing the packages provided by Univention by another source.
In practice it might actually work without issues and be upgradable, however keep in mind that Univention not “just” a modified Debian but to some degree an appliance, so modifications can not only cause issues with support but also lead to unexpected behavior.
Univention is actually aware of it based on their bugtracker, see: 57473 – Radius vulnerability CVE-2024-3596
1 Like
@msi Agreed,
I understand the risk and see how this could lead to more problems.
However, this not being addressed at UCS level causes issues down the line with another vendor who went and implemented checks for BlastRADIUS patching. This in turn causes issues with access to other features and/or service testing.
If I can implement a patch (even if by force installing the FreeRADIUS) which will sit quietly in the background, doing its job I’m willing to accept the external repo. Especially if by doing this we will regain access to something, avoid seeing big red X somewhere in another GUI and being grilled by bosses for not patching a well-known vulr.
For me, it’s probably less about the BlastRADIUS itself, although there’s some concern about it too, but overall system performance and ‘compatibility’ between different vendors.
@fdavid I see how this issue is not a top priority, with high bar to actually conduct the attack. However, as mentioned before, this is causing friction with other vendors (Fortinet in our case) and preventing smooth operation with UCS.
1 Like
Hi dzidek23,
thank you for the insights. I forwarded your concerns and input regarding BlastRADIUS, to further explain the possible impacts, and we’re taking a look at possible solutions.
1 Like