Sperren von Gruppen und Benutzern vom Dozentenfrontend aus
Bei einer Anmeldung eines Rechners der nicht über die Adminoberfläche angemeldet wurde und damit keinen Maschinenaccount hat wird das Script adduser das in der smb.conf angegeben ist ausgeführt. Damit wird dann je nachdem was in diesem Skript steht, ein Rechneraccount angelegt. Genau dies ist aber nicht erwünscht. Es sollten nur Rechner aufgenommen werden die definitiv einem Raum zugeordnet sind. Sonst funktionieren die Funktionen nicht, wie einsammeln, ...
Oops eben merk ichs ! Ich kann als Dozent ja nur von einem an der Domain registrierten Raum aus Zugriffsrechte setzen ! Ganz schlecht. Wieso ? Ich möchte auch gerne von anderswo Klassenweise , nicht Raumweise sperren und freischalten können. Wir haben an den LDAP vom Schoolserver einen Radius angehängt an dem sich die Studenten authentifizieren müssen wenn sie ins wlan möchten.Dort wird mit einem filter "nointernet=yes" geprüft ob sie dürfen oder auch nicht. Die Raumweise (Hostbezogene) Sperrung macht für uns daher keinen Sinn (macht sie überhaupt Sinn ? ich will ja Benutzer einschränken nicht die Hardware), da sowieso jeder Student einen Laptop besitzt und somit über WLAN weitersurfen könnte. Die Möglichkeit des Sperrens von Gruppen und Klassen vom Dozentenaccount aus ist jedoch von essenzieller Wichtigkeit für uns. Inwieweit die Einsammel und Austeil Funktion betroffen sein soll , kann ich nicht ganz nachvollziehen, da die Daten im Home-Netzlaufwerk auf dem Server liegen und mit den Räumen eigentlich nichts zu tun hat. Mein Bitte wäre , die Domänenanbindung zu automatisieren ( wie bei SLOX schon geschehen ),Die Raumsperrung zugunsten der Gruppen/Personenbezogenen Sperrung aufzugeben und sie dem Dozentenfrontend hinzuzufügen. Mit feundlichen Grüßen Patrick Machauer
So werden willkürlich accounts an gelegt, die nicht der schönen Struktur des Schulservers entspricht.
* Gesendet mit / Sent by: FEN-Webmail * http://www.fen-net.de *
Zuerst mal vielen Dank für die Anregungen. Der Schulserver lebt nun mal davon, dass dieser in verschiedenen Schulen eingesetzt wird, unbd die Erfahrungen bzw. Wünsche sind für mich die Grundlage für die Weiterentwicklung. Alles kann ich nun mal nicht wissen :-)) Am Mittwoch, 12. Mai 2004 14:10 schrieb Patrick Machauer:
Bei einer Anmeldung eines Rechners der nicht über die Adminoberfläche angemeldet wurde und damit keinen Maschinenaccount hat wird das Script adduser das in der smb.conf angegeben ist ausgeführt. Damit wird dann je nachdem was in diesem Skript steht, ein Rechneraccount angelegt. Genau dies ist aber nicht erwünscht. Es sollten nur Rechner aufgenommen werden die definitiv einem Raum zugeordnet sind. Sonst funktionieren die Funktionen nicht, wie einsammeln, ...
Oops eben merk ichs ! Ich kann als Dozent ja nur von einem an der Domain registrierten Raum aus Zugriffsrechte setzen ! Ganz schlecht. Wieso ? Ich möchte auch gerne von anderswo Klassenweise , nicht Raumweise sperren und freischalten können.
Auf Benutzerebene geht das jetzt schon und bald wird das auf Gruppen bzw. Klassenebene gehen.
Wir haben an den LDAP vom Schoolserver einen Radius angehängt an dem sich die Studenten authentifizieren müssen wenn sie ins wlan möchten.Dort wird mit einem filter "nointernet=yes" geprüft ob sie dürfen oder auch nicht.
Genau so machen wir das auch, nur dass es bei uns "internetDisabled=yes" heisst.
Die Raumweise (Hostbezogene) Sperrung macht für uns daher keinen Sinn (macht sie überhaupt Sinn ? ich will ja Benutzer einschränken nicht die
Sehr wohl, da die meiste Rechner in den Schulen doch stationär sind.
Hardware), da sowieso jeder Student einen Laptop besitzt und somit über WLAN weitersurfen könnte.
Aber nicht unbeding in jedre Schule. Außerdem würde ich nicht registrierten Rechner keine Rechte geben. Man kann doch virtuelle Räume bilden wie Laptos der Klassen was auch immer. Dann hat man den Vorteil, dass man diese Rechner unabhängig der angemeldeten Benutzers und des Standortes sperren kann. Das ist ja auch ein mögliches Szenario.
Die Möglichkeit des Sperrens von Gruppen und Klassen vom Dozentenaccount aus ist jedoch von essenzieller Wichtigkeit für uns.
Wie gesagt danke fürs Info. Wird gemacht.
Inwieweit die Einsammel und Austeil Funktion betroffen sein soll , kann ich nicht ganz nachvollziehen, da die Daten im Home-Netzlaufwerk auf dem Server liegen und mit den Räumen eigentlich nichts zu tun hat.
Sehr wohl, wenn sich die Benutzer sich nicht mit Ihrem eigenen login, sondern mit dem der Workstation anmelden. (Bitte im Hanbuch nach Klausurumgebung suchen.)
Mein Bitte wäre , die Domänenanbindung zu automatisieren ( wie bei SLOX schon geschehen ),
SLOX nimmt einfach den vorhandenen NETBIOS-Namen an. Das geht hier nicht, da wegen der Workstationbenutzer der NETBIOS-Name auf der Workstation geändert werden muss. Legt man aber keinen Wert darauf, kann man bald sog. "Alternativen Namen" verpassen. Wir haben diese Möglichkeit in Hamm (NRW) getestet. Da war es nötig da bestimmte Applicationserver (CAD ..) ihren Namen nicht gern hergeben:-)) Es kommt bald als Update raus.
Die Raumsperrung zugunsten der Gruppen/Personenbezogenen Sperrung aufzugeben und sie dem Dozentenfrontend hinzuzufügen. Würde ich die Raumsperrung abschaffen, würde ich sehr schnell große Ärger mit sehr vielen Schulen haben :-)))
Mit feundlichen Grüßen
Patrick Machauer
So werden willkürlich accounts an gelegt, die nicht der schönen Struktur des Schulservers entspricht.
* Gesendet mit / Sent by: FEN-Webmail * http://www.fen-net.de *
-- ----------------------------------- Péter Varkoly -o) SuSE Linux AG /\\ e-mail: Peter.Varkoly@suse.de _\_/ Tel.: +49-911-74053484 Mobil.: +49-179-1277635 -----------------------------------
Sehr wohl, wenn sich die Benutzer sich nicht mit Ihrem eigenen login, sondern mit dem der Workstation anmelden. (Bitte im Hanbuch nach Klausurumgebung suchen.)
Im aktuellen Handbuch ist diese auf der Seite 91 als Klassenarbeit und 187 auch beshieben.
Mein Bitte wäre , die Domänenanbindung zu automatisieren ( wie bei SLOX schon geschehen ),
SLOX nimmt einfach den vorhandenen NETBIOS-Namen an. Das geht hier nicht, da wegen der Workstationbenutzer der NETBIOS-Name auf der Workstation geändert werden muss. Legt man aber keinen Wert darauf, kann man bald sog. "Alternativen Namen" verpassen. Wir haben diese Möglichkeit in Hamm (NRW) getestet. Da war es nötig da bestimmte Applicationserver (CAD ..) ihren Namen nicht gern hergeben:-)) Es kommt bald als Update raus.
Die Raumsperrung zugunsten der Gruppen/Personenbezogenen Sperrung aufzugeben und sie dem Dozentenfrontend hinzuzufügen.
Würde ich die Raumsperrung abschaffen, würde ich sehr schnell große Ärger mit sehr vielen Schulen haben :-)))
Mit feundlichen Grüßen
Patrick Machauer
So werden willkürlich accounts an gelegt, die nicht der schönen Struktur des Schulservers entspricht.
* Gesendet mit / Sent by: FEN-Webmail * http://www.fen-net.de *
-- ----------------------------------- Péter Varkoly -o) SuSE Linux AG /\\ e-mail: Peter.Varkoly@suse.de _\_/ Tel.: +49-911-74053484 Mobil.: +49-179-1277635 -----------------------------------
Am Mittwoch, 12. Mai 2004 14:10 schrieb Patrick Machauer:
Bei einer Anmeldung eines Rechners der nicht über die Adminoberfläche angemeldet wurde und damit keinen Maschinenaccount hat wird das Script adduser das in der smb.conf angegeben ist ausgeführt. Damit wird dann je nachdem was in diesem Skript steht, ein Rechneraccount angelegt. Genau dies ist aber nicht erwünscht. Es sollten nur Rechner aufgenommen werden die definitiv einem Raum zugeordnet sind. Sonst funktionieren die Funktionen nicht, wie einsammeln, ...
Oops eben merk ichs ! Ich kann als Dozent ja nur von einem an der Domain registrierten Raum aus Zugriffsrechte setzen ! Ganz schlecht. Wieso ? Ich möchte auch gerne von anderswo Klassenweise , nicht Raumweise sperren und freischalten können. Übrigens der Hauptadministrator kann es sowieso. Ich will übrigens niemanden etwas unterstellen, aber stellen Sie sich vor jeder, Lehrer könnte jeden Raum sperren. Es muss nicht unbedingt gewollt sein, aber auch versehentlich kann man dann den falschen Raum sperren, und dann ist die Hölle los und passiert gerade das, was wir mit dem Schulserver abwenden möchten: der arme IT/Mahte/Physiklehrer (der Defaultschuldige) wird aus dem unterricht gerissen, denn das sche... Teil tuts wieder nicht. Sie mögen zwar alles überall, kontrollieren können, na gut, dann sind Sie aber in diesem Moment nicht ein "normaler" Lehrer sondern der Administrator. Also melden Sie sich als Administrator an.
-- ----------------------------------- Péter Varkoly -o) SuSE Linux AG /\\ e-mail: Peter.Varkoly@suse.de _\_/ Tel.: +49-911-74053484 Mobil.: +49-179-1277635 -----------------------------------
participants (2)
-
Patrick Machauer -
Peter Varkoly