Optimierung des OPNsense Freeradius LDAP Benutzerfilters
Closed this issue · 11 comments
So wie der Benutzerfilter nach der Installation eingerichtet ist, funktioniert dieser unter OPNsense 20 nicht:
(&(objectClass=person)(sAMAccountName=%{%{Stripped-User-Name}:-%{User-Name}})(memberOf=CN=wifi*))
Hier sollte, abhängig von der gewählten Domain/OU stehen:
(&(objectClass=person)(sAMAccountName=%{%{Stripped-User-Name}:-%{User-Name}})(memberOf=CN=wifi,OU=Management,OU=default-school,OU=SCHOOLS,DC=fzi,DC=lan))
Auch die Dokumentation im Wiki hier und in der offiziellen Doku dazu müssten korrigiert werden:
https://github.com/linuxmuster/linuxmuster-base7/wiki/Setup-und-Inbetriebnahme-des-Systems#freeradius-einrichten
https://docs.linuxmuster.net/de/latest/systemadministration/network/radius/index.html?highlight=radius#ldap-einrichten
Siehe auch meinen Beitrag dazu hier:
https://ask.linuxmuster.net/t/unifi-wlan-abschalten-ueber-schulkonsole/3365/16
Danke für den Hinweis. Wie überprüfst du, ob der Benutzerfilter im Radiusdienst funktioniert? Auf der Firewallkonsole klappt nämlich die Abfrage mit der Syntax:
ldapsearch -H ldaps://server.linuxmuster.lan -b dc=linuxmuster,dc=lan -D CN=global-binduser,OU=Management,OU=GLOBAL,DC=linuxmuster,DC=lan -w geheim '(&(objectClass=person)(sAMAccountName=zell)(memberOf=CN=wifi*))'
Jetzt habe ich das mit einem frisch aufgesetzten System mit OPNsense 20.1.8 nochmal durchgetestet. Es hat genauso funktioniert, wie es in der oben verlinkten Anleitung steht.
Danke für den Hinweis. Wie überprüfst du, ob der Benutzerfilter im Radiusdienst funktioniert?
Ich hatte oben den falschen Link zum Forum. Hier der Richtige:
https://ask.linuxmuster.net/t/unifi-wlan-abschalten-ueber-schulkonsole/3365/16
Auf der Firewallkonsole klappt nämlich die Abfrage mit der Syntax:
ldapsearch -H ldaps://server.linuxmuster.lan -b dc=linuxmuster,dc=lan -D CN=global-binduser,OU=Management,OU=GLOBAL,DC=linuxmuster,DC=lan -w geheim '(&(objectClass=person)(sAMAccountName=zell)(memberOf=CN=wifi*))'
Ja, die Abfrage klappt bei mir auch. Allerdings bekomme ich da ein Ergebnis unabhängig davon, ob der User Mitgied der Gruppe wifi ist oder nicht.
Aber letztlich zählt ja, was an der Radius Client Implementierung des Accesspoints ankommt. Deshalb ist ein Test mit z.B. dem radclient evtl. besser geeignet.
Ich habe "meinen" Fehler nun gefunden. In meinem Setup gibt es eine Klasse "wificlass". Wenn der Benutzer dort Mitglied ist, dann habe ich wie oben beschrieben immer auch einen Match für den Filter (memberOf=CN=wifi*). Deshalb funktioniert das bei mir nicht.
Wenn der Filter aber folgendermaßen lautet, so findet man wirklich nur die Gruppe "wifi":
(&(objectClass=person)(sAMAccountName=%{%{Stripped-User-Name}:-%{User-Name}})(memberOf=CN=wifi,OU=*))
Jetzt habe ich das mit einem frisch aufgesetzten System mit OPNsense 20.1.8 nochmal durchgetestet. Es hat genauso funktioniert, wie es in der oben verlinkten Anleitung steht.
Ja, die Abfrage klappt bei mir auch. Allerdings bekomme ich da ein Ergebnis unabhängig davon, ob der User Mitgied der Gruppe wifi ist oder nicht.
Tut mir leid, aber hier klappt das mit meinem ursprünglichen Filter (memberOf=CN=wifi*) tippitoppi. Wenn ich den User mit sophomorix-managementgroup --nowifi aus der Wifigruppe rausnehme, führt die ldapsearch-Abfrage auf der OPNsense zu keinem Ergebnis, ebenso die Radclient-Abfrage auf dem Server. Works for me.
Bitte meinen obigen Beitrag beachten:
#106 (comment)
Wenn es eine Klasse "wificlass" gibt, dann funktioniert der Filter nicht mehr. Der Filter sollte diese Möglichkeit abfangen. Einen Vorschlag habe ich oben gemacht.
Wenn einem Admin einfällt den WLAN-Zugriff über eine Gruppe "wlangruppe" zu steuern, greift der Filter auch nicht. So What. Wenn man WLAN-Zugriff nicht über die standardmäßig dafür vorgesehene Gruppe steuern will, muss man halt den Filter anpassen. Der ausgelieferte Filter funktioniert mit der Wifi-Managementgroup von sophomorix schulübergreifend. Mehr soll er auch nicht tun.
Natürlich kann man den Filter anpassen wenn man das Wissen dazu hat. Ich dachte mir Bugreporting erhöht die Qualität des Produkts. Wenn Bugs hier abgetan werden mit "So What" und "Works for me", dann bin ich falsch hier Fehler zu berichten.
Fakt ist:
sophomorix-check lässt es zu, daß eine Klasse "wificlass" angelegt wird, obwohl der OPNsense Radius Filter damit nicht funktioniert. Wenn das sauber wäre, dann würde entweder sophomorix-check das abfangen, oder der Filter entsprechend angepasst, so daß hier keine Fehler mehr auftauchen können.
Im Übrigen habe ich einen angepassten, universellen Filter gepostet, welcher besser funktioniert als der bisherige und solche Fälle abfängt. Daß das ignoriert wird und der Bug geschlossen wird, ohne auch nur darauf einzugehen, ist für mich enttäuschend.
Vielleicht hast Du aber auch etwas falsch verstanden. Ich steuere den wlan Zugriff nicht über die Gruppe wificlass. Der Benutzer ist nach wie vor Mitglied in der Gruppe wifi. Es gibt einfach nur eine zusätzliche Klasse wificlass in welcher die extrastudents sind, welche verwendet werden um schuleigene WLAN Geräte über WPA2 Enterprise zu verbinden. Man darf also keine Klasse anlegen, welche mit wifi* beginnt. Sollte dokumentiert werden, oder obiger Bugfix angewendet werden.
Ok, Benutzerfilter in memberOf=CN=wifi,OU=Management,OU=* geändert.
Published in linuxmuster-base7 7.0.73.