Hallo Hans-Dietrich, ich denke diese Lösung leistet - genau so wie Coovachilli - was Du möchtest. http://www.linuxmuster.net/wiki/anwenderwiki:benutzerrechner:wlan:radius-accesspoint http://www.linuxmuster.net/wiki/anwenderwiki:benutzerrechner:wlan:radius-accesspoint-blau?s[]=radius&s[]=blau
Mit dem Projekt p_wifi kann ich bestimmen, welcher Benutzer oder welche Gruppe ins WLAN kommt und wer Mitglieder in p_wifi aufnehmen und daraus entfernen darf. Ich kann es z. B. so einrichten, dass jede KollegIn SchülerInnen oder Klassen in ihrem Unterricht temporär freischalten kann. Es kann nur ein Gerät zurzeit mit einer Benutzerkennung angemeldet sein. Man kann nur noch nicht beschränken welches. Da IServ solch eine Gruppe wie p_wifi zu dem Zeitpunkt als ich das mal für jemanden eingerichtet habe, nicht kannte (ca. September 2015), erfolgt die Beschränkung bei denen vielleicht ganz simpel über feste IPs im DHCP des Schulrouter. Dies wäre natürlich Security by Obscurity. Ob ein Schüler sich auf seinem iPhone eine WLAN-Verbindung mit statischer IP einrichten kann, weiß ich nicht und (s)eine Benutzerkennung bräuchte er für WPA-Enterprise immer noch. Wenn hier niemandem etwas besseres einfällt, würde ich als ersten Schritt die dynamischen Einträge im Schulrouter zu statischen umwandeln und nach und alle rauswerfen, die Smartphone-MACs haben. Den scope für unbekannte Geräte kann man ja klein machen, wenn man überhaupt einen haben möchte. Ich fürchte ja weniger Missbrauch als Überlastung. Vor ersterem soll uns ja Time for Kids schützen (helfen). Cybermobbing betreiben die Bösen eh mit ihrer LTE-flatrate, die sie auch gern mal per Hotspot mit ihren Spießgesellen teilen ... Gruß Jürgen Am 26.02.2016 um 10:09 schrieb Hans-Dietrich Kirmse: > Hallo H.Hullen, > > Am 26.02.2016 um 08:50 schrieb Helmut Hullen: >> Hallo, Juergen, >> >> Du meintest am 25.02.16: >> >>> heute habe ich auf einem Netzwerktreffen gelernt, das IServ (im >>> Zusammenspiel mit Time for Kids?) bei der WLAN-Authentifizierung in >>> BLAU neben Benutzername und Kennwort auch die MAC überprüft, um den >>> Zugang mit (natürlich unerlaubterweise) überlassenen Daten oder mit >>> unbekannten Geräten oder Smartphones zu verhindern. >> >> So ein Umstandswauwau ist zwar beliebt, aber m.E. für Schulen unnötig. >> Stichwort: Radiusserver. > > ob die Überprüfung der MAC oder eines Client-Zertifikats wirklich was > bringt, kann ich einfach noch nicht einschätzen. Ich verfolge dazu mit > Interesse diesen Thread und hoffe darauf, dass dazu Argumente kommen, > die mich da weiter bringen. > > Zum Radiusserver als solchen, den sehe ich als Administrator unseres > Schulnetzes keineswegs als Umstandswauwau an. Schon deshalb, weil wir > keine Key o.ä für das netz bekannt geben müssen. m.E. ist es rechtlich > problematisch, den Key wie ich es an verschiedenen Schulen gesehen > habe, an jeder Tür per Aushang bekannt zu geben. Will sagen: die > Schüler kommen dank Radiusserver ins lokale Netz und müssen sich dazu > mit ihren Login anmelden. Wenn sie nicht nur auf den Schulserver oder > einen anderen Client im Netz (meist WLan) zugreifen wollen, sondern > ins Internet wollen, müssen sie sich bei uns nochmal anmelden - am > Squid. Nur die Anmeldung am Squid wäre mir wegen den anderen > Nutzungsmöglichkeiten viel zu wenig. > > Aber wie schon gesagt, ist mir auch noch nicht klar, ob eine > Verifizierung der Clients überhaupt sinnvoll ist. Was mir aber > vorschwebt, die Logins zur reglementieren, also nur die Mitglieder > einer Gruppe über den Radiusserver in (W)Lan-Netz kommen können. Habe > ich aber noch keine Lösung dafür, sehe ich aber als machbar an. > >> Der ist dann nötig, wenn der Nutzer anders nicht identifiziert werden >> kann, und das trifft für Schulserver nicht zu. > > Das sehe ich nicht so. > >> Da hat jeder User sowieso >> seinen Account, fürs Home-Verzeichnis und zum Surfen. Das reicht. > > mir nicht. > >> Ist wie bei der Vergabe von Parkplätzen auf dem Schul-Parkplatz. >> Radiusserver ist vergleichbar mit Reservierung nach Kfz-Kennzeichen, >> nicht nach Namen oder Funktion (z.B. "stv. Schulleiter"). Letzteres >> vermeidet die Kontrolle, mit welchem Auto der Berechtigte diesmal >> angekommen ist. > > Dieser Vergleich ist dann passend, wenn man den Client identifizieren > will. Bei meinem Szenario ist der Client völlig außen vor, trotzdem > kann ich mir dafür keine Alternative für den Radiusserver vorstellen. > Will sagen, dieses Modell ist nicht wirklich passend für "Schule". > >> Ein Radiusserver erfordert eine zusätzliche Liste, die irgendwer >> zusätzlich führen und pflegen muss. > > korrekt. Bei meinem Vorhaben/Ansatz will ich wirklich die Schüler, die > WLan nutzen dürfen (z.B. weil sie eine spezielle Nutzerordnung dafür > unterschrieben haben) in eine Gruppe stecken. Das ist in der Tat eine > "Liste". Wenn sie das nicht mehr dürfen, müssen sie halt gelöscht > werden oder automatisch gelöscht werden, wenn sie die Schule verlassen. > >> Und nicht nur halbjährlich oder noch >> seltener - nein. > > muss ich das verstehen? > > Viele Grüße > Hans-Dietrich > _______________________________________________ > linuxmuster-user mailing list > [email protected] > https://mail.lehrerpost.de/mailman/listinfo/linuxmuster-user > _______________________________________________ linuxmuster-user mailing list [email protected] https://mail.lehrerpost.de/mailman/listinfo/linuxmuster-user
