Freeradius verschiedene Gruppen managen

Hallo Mathias,

was mir auffällt. Vorher war Dein Log:

In Deinem letzten Versuch hattest Du:

Im letzten Versuch also das Verzeichnis für das PID File:

/run/freeradius-teachers vorher /run/freeradius. Das Verzeichnis /run/freeradius-teachers muß vermutlich erst angelegt werden.

Ich würde auch die Berechtigungen der verschiedenen Verzeichnisse überprüfen. freerad.freerad sollte User.Gruppe sein. Vor allem wenn Du den freeradius händisch zwischendurch als root gestartet hattest, dann könnte es sein, daß die Berechtigungen root.root sind.

Viele Grüße
Klaus

Hallo Klaus,

Ja, das stimmt. Als ich den freeradius von hand gestartet habe, hat er das Verzeichnis freeradius-teachers angelegt. Ich habe gehofft, dass es am Verzeichnisnamen liegt und das in /etc/default/freeradius-teachers geändert.
fr01
Die Berechtigungen stimmen.

Ich hab’s gefunden!!!
Bei EnvironmentFile=- /etc/default/freeradius war ein Leerzeichen zwischen dem „-“ und dem /etc/... das war’s.

Jetzt ist ein guter Zeitpunkt, mich bai allen zu bedanken, die mir bei der Suche so gut geholfen haben.

Vielen, vielen Dank!!! Ohne euch hätte ich das nicht geschafft!

Viele Grüße,
Mathias

Hi.
Wäre das nicht was für’s Wiki?
Viele Grüße,
Michael

Hallo Michael,

Ich bau unser WLAN um und schau’ ob alles so läuft, wie ich mir das vorstelle.
Dann arbeite ich das ins Wiki ein.

Gruß,
Mathias

Hi.
Ich hole diesen Beitrag nochmal nach oben, da wir vor der gleichen Überlegung stehen: Im Moment verwalten wir die Beschränkung zum Internet über sophomorix-managementgroup --set-wifi ...
Leider ist mir nicht ganz klar, was dann intern auf dem RADIUS-Server geschieht, dass nach Ausführen des Befehls bestimmte User ins Internet dürfen und andere nicht. Über welchen Mechanismus bzw über welche .conf-Datei wird das geregelt?

Der Hintergrund der Überlegung ist der gleiche wie bei Mathias (@rettich). Wir wollen aber eigentlich kein eigenes WLAN für die Lehrer abstrahlen, sondern weiterhin alles über eine SSID erledigen.

Konkret ist es bei uns so, dass die Lehrer und die Oberstufe immer ins Internet dürfen. Der Zugang ist über ein Captive Portal (das auf der OPNSense läuft) gesperrt und wird dort

  • über FreeRADIUS vom v7-Server für die o.g. Gruppen
  • für alle anderen über ein Voucher bei „spontanem Bedarf“

freigegeben. Das funktioniert zwar auch alles, aber nun gibt es vermehrt das folgende Problem:

In der OPNSense sehe ich bei den laufenden Sessions diverse Einträge doppelt und dreifach.
Es werden also die gleichen Logins mit unterschiedlichen MAC-Adressen angezeigt. Das kann natürlich einfach nur daran liegen, dass mehr und mehr Geräte dem AP nicht mehr ihre echte MAC-Adresse sondern aus „Sicherheitsgründen“ eine „virtuelle“ MAC-Adresse zeigen. Auf der OPNSense sieht das dann so aus, als wären zwei verschiedene Geräte mit dem gleichen Login verbunden.

Es kann aber auch sein, dass Logins & Passwörter von Schülern an andere Schüler gegeben werden, die eigentlich nicht zu einer der o.g. Gruppen gehören. Das würden wir gerne unterbinden, da hier zu viele Geräte das WLAN vollstopfen. Und um das herausfiltern zu können, wäre es denkbar, dass sich jedes Gerät immer nur einmal anmelden kann – oder, dass man die Gruppenverwaltung von FreeRADIUS bemüht, um genauer einzustellen, wer was darf.

Eine Stolperfalle bei der Sache: Falls man die Einstellung verwendet, dass man sich nur noch mit einer MAC-Adresse anmelden darf, muss man sich u.U. jeden Tag neu am Captive Portal anmelden — und das würden natürlich alle als Gängelei empfinden. Daher wäre es mir eigentlich am liebsten, wenn man das so regeln könnte: Lehrer dürfen immer rein und bleiben auch dauerhaft angemeldet und Schüler dürfen nur mit einer MAC-Adresse rein und müssen sich spätestens nach 1 Woche neu anmelden.

Daher die Frage: Wie regelt ihr das?
Viele Grüße,
Michael

Hallo Michael,

Ich hole diesen Beitrag nochmal nach oben, da wir vor der gleichen
Überlegung stehen: Im Moment verwalten wir die Beschränkung zum Internet
über |sophomorix-managementgroup --set-wifi …|
Leider ist mir nicht ganz klar, was dann intern auf dem RADIUS-Server
geschieht, dass nach Ausführen des Befehls bestimmte User ins Internet
dürfen und andere nicht. Über welchen Mechanismus wird das geregelt?

das sophomorix-managementgroups setzt bei den LDAP Usern, die in der
wifi.default.??? aufgeführt sind in ihrem LDAP Eintrag das Flag: WLAN = Ja

Dieses wird vom freeradius ausgewertet, wenn er rausfinden will, ob
jemand darf oder eben nicht.

LG

Holger

Hallo Holger, ok
dann schaut FreeRADIUS offenbar auch ins AD und findet dort entweder den Eintrag WiFi=Ja oder Nein
Ich hab’s gerade in den docs wiedergefunden: Scheinbar wird das über den Befehl /usr/bin/ntlm_auth ... abgefragt.

Ich hatte gehofft, dass man evtl hier ansetzen kann, um zwischen den Gruppen Lehrer und Schüler nochmal zu differenzieren und diesen Gruppen ggf unterschiedliche Einstellungen mit auf den Weg zu geben :thinking:
FreeRADIUS ist leider echt komplex …
Vielleicht hat das ja jemand so oder so ähnlich gemacht?

[… etwas später …] → Ernüchterung macht sich breit:

Viele Grüße,
Michael

… vorläufiger Workaround für die OPNSense:

  • Captive Portal Einstellungen:
    Leerlaufzeitlimit (Minuten) auf 10080 (1 Woche) gestellt und zusätzlich
  • Gleichzeitige Benutzeranmeldungen deaktiviert

Damit werden alle Geräte gezwungen, sich nach einer Woche neu anzumelden. Ist für die Lehrer im Moment vielleicht etwas nervig aber was die Anzahl der aktiven Sessions sowie die Weitergabe von Credentials an „Unbefugte“ angeht, wird sich sicher ein spürbarer Effekt zeigen :thinking: :interrobang:

[Update]
Der Teufel steckt im Detail — wenn man die Option „Gleichzeitige Benutzeranmeldungen“ deaktiviert, können sich natürlich auch per Voucher nicht mehrere Geräte über ein Ticket anmelden. Der Workaround ist daher leider nur ein Würgaround :wink:

[Update vom Update}
Ich habe meine Scripte zur Steuerung der OPNSense via API nun um ein weiteres Script erweitert. Dieses Script schaut ganz einfach nach, ob es Logins gibt, die von mehr als einem Gerät stammen und trennt sie. Das ist vielleicht etwas radikal aber es reduziert die Anzahl der Geräte im WLAN drastisch. Normalerweise lagen wir (auf der OPNSense bzw im Unifi-Controller zu sehen) täglich bei ca 1300 Geräten / Sessions – jetzt nur noch bei 800. Ich hoffe, dass sich das positiv auf die Airtime für alle auswirkt.
Hier nochmal der Link zu den anderen Scripten, falls das auch für andere interessant ist:

Im Grunde ist die Lösung doch kinderleicht:

  • Man richtet einen Freeradius Server mit WebGUI ein wie z.B. hier beschrieben: Freeradius Management mit WebGUI - Administrator
  • Dort richtet man unter Profile/Gruppen die Lehrer Schüler Gruppen ein und weist diesen Gruppen die entsprechenden VSAs zu
  • Zuletzt ordnet man die einzelnen User der Gruppe Lehrer oder Schüler zu.
    Eigentlich ist das sehr schnell erledigt und der gängige Weg das so umzusetzen mit den Radius Gruppen.

Hallo.
Schön zu hören, dass der eingeschlagene Weg schon mal stimmt … ich habe seit den letzten Beiträgen zum Thema aus Zeitmangel nicht an dieser Sache weitergemacht.

Eine freeRADIUS-Installation + daloRADIUS läuft aber mittlerweile trotzdem. Das ging relativ flott als Proxmox-LXC-Container. Als alles fertig war, stellte ich dann aber fest, dass der hier gezeigte Ansatz zwar ganz gut funktioniert aber nicht nahtlos mit dem v7-Server zusammenarbeitet, da es in diesem Fall darum geht, dass die User alle über mySQL verwaltet oder sogar neu angelegt werden. Das ist aber bei dem Setup mit dem v7-Server im Hintergrund alles gar nicht nötig geschweige denn sinnvoll, da sämtlich User ja bereits über die LDAP/AD-Verbindung zur Verfügung stehen. Aus diesem Grund habe ich mich mit daloRADIUS dann nicht weiter beschäftigt. Stattdessen müsste der freeRADIUS-Server um die LDAP-Gruppen ergzänzt werden. So bin ich auf den Thread hier gestoßen:

Das haben andere schon vor längerer Zeit gemacht. Leider habe ich seitdem nichts mehr gehört, wie die Sache ausgegangen oder weitergelaufen ist…
Wenn ich das richtig sehe, dürfte das alles keine Raketenwissenschaft sein.

Viele Grüße,
Michael

P.S.: daloRADIUS scheint übrigens weiterentwickelt zu werden. Ich hatte im ersten Versuch eine ganze neue Version drauf. In sämtlichen Screenshots zu den zu treffenden Einstellungen habe ich aber immer nur die alte Oberfläche gefunden, so dass ich die letztlich auch genommen habe…

Das liegt daran das die neue und aktuelle 2.0er Version von Dalo eine neue Verzeichnisstruktur hat, so das die alte Installationsanleitung bei der neuen Version nicht mehr greift.
Wenn man aber die neue 2.0 über Git installiert wie oben beschrieben oder im Dalo README dann klappt das auf Anhieb sofort…dann auch mit dem neuen und aktuellen WebGUI. :wink:

Ok, aber wie gesagt – ob daloRADIUS in diesem Fall überhaupt so viel bringt … :thinking: :interrobang:

Die entsprechende Frage dazu wurde schon 2016 hier gestellt :stuck_out_tongue_winking_eye:
https://sourceforge.net/p/daloradius/support-requests/48/

… man kann die Frage auch umformulieren: Wenn man unter daloRADIUS auch das Modul ldap mit verwenden könnte, um alle User aus dem AD direkt (weiter) zu verwenden, wäre viel gewonnen. Im Prinzip also sowas wie hier gezeigt aber dann mit grafischem WebUI:

Hallo Michael,

zumindest nach dem
Offiziellen Statement des Entwicklers

ist LDAP-Intergration bei daloRADIUS nicht vorgesehen.

VG
Thomas

Hallo.
Ich habe es nochmal so versucht, wie von Mathias (@rettich ) vorgeschlagen. Der freeRADIUS-Server ist ein Debian 11 mit freeRADIUS 3.2, der im Moment nur zu Testen auf einer Extra-VM bereitsteht.
Ich bin der Anleitung oben gefolgt und habe auch das Verzeichnis unter /etc/freeradius/3.0 kopiert usw.
Der Start des beiden einzelnen Dämonen klappt auch. In beiden Fällen erhalte ich grünes Licht:

Zuerst 
service freeradius start
service freeradius status
(service freeradius stop)

und anschließend:

service freeradius-teachers start
service freeradius-teachers status
(service freeradius-teachers stop)

-> journalctl -xe
● freeradius.service - FreeRADIUS multi-protocol policy server
     Loaded: loaded (/lib/systemd/system/freeradius.service; enabled; vendor preset: enabled)
     Active: active (running) since Fri 2023-06-16 15:19:38 UTC; 7min ago

Wenn ich aber zuerst den „normalen“ Dienst starten will und dann den „freeradius-teachers“ hinterher, klappt es nicht mehr. Dann scheitert der Start des zweiten Dienstes mit der Meldung:

Jun 16 15:34:05 freeradius-server freeradius[16246]: Configuration appears to be OK
Jun 16 15:34:05 freeradius-server systemd[1]: freeradius-teachers.service: Control process exited, code=exited, status=1/FAILURE
░░ Subject: Unit process exited
░░ Defined-By: systemd
░░ Support: https://www.debian.org/support
░░ 
░░ An ExecStart= process belonging to unit freeradius-teachers.service has exited.
░░ 
░░ The process' exit code is 'exited' and its exit status is 1.
Jun 16 15:34:05 freeradius-server systemd[1]: freeradius-teachers.service: Failed with result 'exit-code'.
░░ Subject: Unit failed
░░ Defined-By: systemd
░░ Support: https://www.debian.org/support
░░ 
░░ The unit freeradius-teachers.service has entered the 'failed' state with result 'exit-code'.
Jun 16 15:34:05 freeradius-server systemd[1]: Failed to start FreeRADIUS multi-protocol policy server.
░░ Subject: A start job for unit freeradius-teachers.service has failed
░░ Defined-By: systemd
░░ Support: https://www.debian.org/support
░░ 
░░ A start job for unit freeradius-teachers.service has finished with a failure.
░░ 
░░ The job identifier is 63101 and the job result is failed.

Daher die Frage: Wie startest Du beide daemons auf einer VM? Oder wo steckt hier der (Denk-)Fehler?
Viele Grüße,
Michael

Hab’s! Es lag an weiterhin doppelt vergebenen Ports! Man muss echt sehr genau hinschauen, da in der Datei /etc/freeradius/3.0-teachers/sites-enabled/default die folgende Standardsyntax verwendet wird: port = 0.
Das bedeutet dann: Nimm den Standardport 1812!

Daher bringt es auch nichts, diese Datei nach dem Suchwort 1812 oder 1813 zu durchsuchen sondern man muss sowohl für die IPv4 als auch für die IPv6 Adresse die Stellen, wo port = 0 steht, manuell auf 1912 und 1913 (wie oben vorgeschlagen) umstellen. Danach starten beide Dämonen auch gleichzeitig!
(Alternativ kann man den Abschnitt für IPv6 natürlich auch auskommentieren)

Geholfen hat mir hier übrigens der Befehl netstat -tulpn. Damit habe ich dann gesehen, wo das Problem steckt.

Im nächsten Schritt wird nun erstmal ein freeRADIUS-Zertifikat für das WPA3-Enterprise WLAN erzeugt und dann wird’s spannend, ob in dieses Netz am Ende nur noch Lehrergeräte gelangen können.

Viele Grüße,
Michael