14
Wie befehle für Benutzer eingrenzen?
Hi, wir haben über eine Softwreverteilung Win10 verteilt. Soweit alles gut.
Nun ist uns aufgefallen, das die "Kinder" den "netsh....." Befehl nutzen um z.B. das WLAN PW auszulesen.
Die Frage ist, wie kann ich das verhindern?
Ich bin davon ausgeganen, das nur Admins das nutzen können, aber Benutzer können das auch.
Also evtl per GPO einschränken? Macht das Sinn, da wir über unseren Server noch Befehle raussenden, die z.B. dafür sorgen, das eben das WLAN-PW gesetzt wird. Dafür läuft im Hintergrund OPSI.
Eine Option wäre die Verwaltung durch unsere WLAN-infrastruktur zu machen, aber das wäre etwas aufwendiger.
Hat jemand ein paar Tipps?
Danke.
Nun ist uns aufgefallen, das die "Kinder" den "netsh....." Befehl nutzen um z.B. das WLAN PW auszulesen.
Die Frage ist, wie kann ich das verhindern?
Ich bin davon ausgeganen, das nur Admins das nutzen können, aber Benutzer können das auch.
Also evtl per GPO einschränken? Macht das Sinn, da wir über unseren Server noch Befehle raussenden, die z.B. dafür sorgen, das eben das WLAN-PW gesetzt wird. Dafür läuft im Hintergrund OPSI.
Eine Option wäre die Verwaltung durch unsere WLAN-infrastruktur zu machen, aber das wäre etwas aufwendiger.
Hat jemand ein paar Tipps?
Danke.
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 2189230205
Url: https://administrator.de/contentid/2189230205
Printed on: April 25, 2024 at 06:04 o'clock
14 Comments
Latest comment
Servus
Sehr schön, haben wir noch nicht
Sehr schön, haben wir noch nicht
Nun ist uns aufgefallen, das die "Kinder" den "netsh....." Befehl nutzen um z.B. das WLAN PW auszulesen.
Welche Kinder? Schule? WIe wärs damit: Die Nutzung von cmd und powershell einfach komplett verbieten?Die Frage ist, wie kann ich das verhindern?
Die nutzung von cmd und powershell komplett verbieten?Danke.
Bitte
Hallo,
wie währe es, wenn man auch noch eine vernünftige W-Lan Authentifizierung einführt?
wie währe es, wenn man auch noch eine vernünftige W-Lan Authentifizierung einführt?
Zitat von @RoadRage3:
Servus
Sehr schön, haben wir noch nicht
Servus
Sehr schön, haben wir noch nicht
Nun ist uns aufgefallen, das die "Kinder" den "netsh....." Befehl nutzen um z.B. das WLAN PW auszulesen.
Welche Kinder? Schule? WIe wärs damit: Die Nutzung von cmd und powershell einfach komplett verbieten?Die Frage ist, wie kann ich das verhindern?
Die nutzung von cmd und powershell komplett verbieten?Also das wäre ja auch meine Überlegung, aber ich möchte das eben nur auf Benutzerebene tun und die Frage ist, ob das möglich ist?
Ich wäre auch nicht davon ausgegangen, dass das PW von der SSID für jeden im klartext abzurufen ist. Für Admins okay, aber nicht für "Benutzer".
Zitat von @wiesi200:
Hallo,
wie währe es, wenn man auch noch eine vernünftige W-Lan Authentifizierung einführt?
Hallo,
wie währe es, wenn man auch noch eine vernünftige W-Lan Authentifizierung einführt?
für diese Geräte, ober die wir sprechen ist das nicht praktikabel. Das hatten wir schon. Ja es handel sich hier um eine Schule und das Problem sind ja hier Lehrer (nicht alle) und die wesentlich informierteren Schüler.
Einfach via GPO verbieten?
Zitat von @simpsonetti:
Also das wäre ja auch meine Überlegung, aber ich möchte das eben nur auf Benutzerebene tun und die Frage ist, ob das möglich ist?
Also das wäre ja auch meine Überlegung, aber ich möchte das eben nur auf Benutzerebene tun und die Frage ist, ob das möglich ist?
Ja, das geht.
Moin,
du kannst die Ausführung von cmd.exe und powershell.exe via GPO Verbieten.
Benutzerrichtlinie, Admin Vorlage, System, Windows-Anwendung nicht ausführen: Powershell.exe
und
Benutzerrichtlinie, Admin Vorlage, System, Zugriff auf Eingabeaufforderung verhindern: aktivieren
Greift dann nur für den Benutzer, bei dem die GPO konfiguriert ist.
Gruß
Doskias
du kannst die Ausführung von cmd.exe und powershell.exe via GPO Verbieten.
Benutzerrichtlinie, Admin Vorlage, System, Windows-Anwendung nicht ausführen: Powershell.exe
und
Benutzerrichtlinie, Admin Vorlage, System, Zugriff auf Eingabeaufforderung verhindern: aktivieren
Greift dann nur für den Benutzer, bei dem die GPO konfiguriert ist.
Gruß
Doskias
Zitat von @Doskias:
Moin,
du kannst die Ausführung von cmd.exe und powershell.exe via GPO Verbieten.
Benutzerrichtlinie, Admin Vorlage, System, Windows-Anwendung nicht ausführen: Powershell.exe
und
Benutzerrichtlinie, Admin Vorlage, System, Zugriff auf Eingabeaufforderung verhindern: aktivieren
Greift dann nur für den Benutzer, bei dem die GPO konfiguriert ist.
Gruß
Doskias
Moin,
du kannst die Ausführung von cmd.exe und powershell.exe via GPO Verbieten.
Benutzerrichtlinie, Admin Vorlage, System, Windows-Anwendung nicht ausführen: Powershell.exe
und
Benutzerrichtlinie, Admin Vorlage, System, Zugriff auf Eingabeaufforderung verhindern: aktivieren
Greift dann nur für den Benutzer, bei dem die GPO konfiguriert ist.
Gruß
Doskias
Okay, danke. Und das geht auch für die Gruppe der "Benutzer" ?
Also die sollen das nicht dürfen, system accounts und (domain)admins schon.
Du musst die GPO halt der entsprechenden OU bzw. der Benutzergruppe zuweisen. Wie jede GPO halt. Da ich deinen Aufbau der Domäne nicht kenne und nicht weiß wie deine OUs aufgebaut sind, kann ich es dir nicht sagen:
Es ist eine Benutzerkonfiguration, die nur für die Benutzer gilt. System Accounts sind lokale Accounts, da greift die GPO nicht, da die nicht in der OU sein werden. Für Domainadmins greift sie, wenn die in der gleichen OU wie deine Schüler sind, was hoffentlich nicht der Fall ist.
Ansonsten: GPO-erstellen, authentifizierten Benutzer im Sicherheitsfilter rauswerfen, authentifizierten Benutzer in Delegierung mit leserechte hinzufügen, Testbenutzer oder ganze Benutzergruppe im Sicherheitsfilter hinzufügen. Sollte aber bei der GPO und einem strukturiertem AD nicht erforderlich sein
Gruß
Doskias
Es ist eine Benutzerkonfiguration, die nur für die Benutzer gilt. System Accounts sind lokale Accounts, da greift die GPO nicht, da die nicht in der OU sein werden. Für Domainadmins greift sie, wenn die in der gleichen OU wie deine Schüler sind, was hoffentlich nicht der Fall ist.
Ansonsten: GPO-erstellen, authentifizierten Benutzer im Sicherheitsfilter rauswerfen, authentifizierten Benutzer in Delegierung mit leserechte hinzufügen, Testbenutzer oder ganze Benutzergruppe im Sicherheitsfilter hinzufügen. Sollte aber bei der GPO und einem strukturiertem AD nicht erforderlich sein
Gruß
Doskias
Zitat von @Doskias:
Du musst die GPO halt der entsprechenden OU bzw. der Benutzergruppe zuweisen. Wie jede GPO halt. Da ich deinen Aufbau der Domäne nicht kenne und nicht weiß wie deine OUs aufgebaut sind, kann ich es dir nicht sagen:
Es ist eine Benutzerkonfiguration, die nur für die Benutzer gilt. System Accounts sind lokale Accounts, da greift die GPO nicht, da die nicht in der OU sein werden. Für Domainadmins greift sie, wenn die in der gleichen OU wie deine Schüler sind, was hoffentlich nicht der Fall ist.
Ansonsten: GPO-erstellen, authentifizierten Benutzer im Sicherheitsfilter rauswerfen, authentifizierten Benutzer in Delegierung mit leserechte hinzufügen, Testbenutzer oder ganze Benutzergruppe im Sicherheitsfilter hinzufügen. Sollte aber bei der GPO und einem strukturiertem AD nicht erforderlich sein
Gruß
Doskias
Du musst die GPO halt der entsprechenden OU bzw. der Benutzergruppe zuweisen. Wie jede GPO halt. Da ich deinen Aufbau der Domäne nicht kenne und nicht weiß wie deine OUs aufgebaut sind, kann ich es dir nicht sagen:
Es ist eine Benutzerkonfiguration, die nur für die Benutzer gilt. System Accounts sind lokale Accounts, da greift die GPO nicht, da die nicht in der OU sein werden. Für Domainadmins greift sie, wenn die in der gleichen OU wie deine Schüler sind, was hoffentlich nicht der Fall ist.
Ansonsten: GPO-erstellen, authentifizierten Benutzer im Sicherheitsfilter rauswerfen, authentifizierten Benutzer in Delegierung mit leserechte hinzufügen, Testbenutzer oder ganze Benutzergruppe im Sicherheitsfilter hinzufügen. Sollte aber bei der GPO und einem strukturiertem AD nicht erforderlich sein
Gruß
Doskias
Also bzgl des AD:
Das haben ja nicht wir aufgesetzt, sondern der Hersteller des Schulservers.
Hier ist es nun so, das ich keine direkten "OU=" Einträge sehe. Ich sehe hier meine BaseDN= dc=domain,dc=de und darunter dann lauter CN=Computers, CN=Users, CN=System usw Einträge. So wie es scheint, sind auch alle Gruppen in CN=Users drin.
Das heißt, könnte ich das so machen, das ich die in CN=Users,CN=group monitor z.B. direkt suche und hinzufüge? Geht das so?
Oder kann ich mir da eigenen OUs zubauen? Keine Ahnung ob der Schulserver dann explodiert. Die halten sich da immer sehr zurück und sagen nicht viel dazu. Ich glaube grundsätzlich möchten sie das nicht und sagen dann immer, kein support mehr ....
Wo die Gruppen drin sind ist total egal. Es geht darum wo die User drin sind. Da wo die User drin sind , da muss die GPO und die wird dann auf alle User angewendet, es sei denn du änderst den Sicherheitsfilter.
Prinzipiell kannst du dir so viele OUs bauen wie du willst. Aber: jeder User kann nur in einer OU gleichzeitig sein. Und wenn du User verschiebst, dann kann es sein, dass Skripte oder Programme nicht mehr funktionieren, da die die User in spezifischen OUs suchen, wo der User dann halt nicht mehr ist. Da dir offenbar der Gesamtüberblick fehlt, würde ich dir raten die Finger von der Neustrukturierung des ADs zu lassen.
Generell solltest du dich mal schlau lesen, wie GPOs funktionieren und wie sie aufgebaut sind. Dann wird sich deine Frage auch beantworten wo du es eintragen musst. Ggf. hol dir doch deinen Dienstleister dazu (oder einen anderen). Das was du vorhast ist kein Hexenwerk und schneller erledigt als du Zeit hier im Forum brauchst
.
Also:
Schritt 1: Mach dich schlau was GPOs sind, wie sie aufgebaut sind und wie man sie konfiguriert
Schritt 2: Konfiguriere die GPO für einen Test-Benutzer
Schritt 3: Roll die GPO auf alle User aus, die sie haben sollen.
Google kennt viele gute Seiten, die dir erklären wie man eine GPO aufbaut. Es wäre mir jetzt zu mühsam, das ganze hier noch mal abzutippen oder reinzukopieren
Gruß
Doskias
Prinzipiell kannst du dir so viele OUs bauen wie du willst. Aber: jeder User kann nur in einer OU gleichzeitig sein. Und wenn du User verschiebst, dann kann es sein, dass Skripte oder Programme nicht mehr funktionieren, da die die User in spezifischen OUs suchen, wo der User dann halt nicht mehr ist. Da dir offenbar der Gesamtüberblick fehlt, würde ich dir raten die Finger von der Neustrukturierung des ADs zu lassen.
Generell solltest du dich mal schlau lesen, wie GPOs funktionieren und wie sie aufgebaut sind. Dann wird sich deine Frage auch beantworten wo du es eintragen musst. Ggf. hol dir doch deinen Dienstleister dazu (oder einen anderen). Das was du vorhast ist kein Hexenwerk und schneller erledigt als du Zeit hier im Forum brauchst
.Also:
Schritt 1: Mach dich schlau was GPOs sind, wie sie aufgebaut sind und wie man sie konfiguriert
Schritt 2: Konfiguriere die GPO für einen Test-Benutzer
Schritt 3: Roll die GPO auf alle User aus, die sie haben sollen.
Google kennt viele gute Seiten, die dir erklären wie man eine GPO aufbaut. Es wäre mir jetzt zu mühsam, das ganze hier noch mal abzutippen oder reinzukopieren
Gruß
Doskias
Inwiefern ist es ein Problem, wenn die Kinder das WLAN-Password kennen? Nutz doch einen Radius-Server und verteile individuelle Passwörter.
Hier liegt ein simpler Fehler vor.
Nur Admins könne das WLAN-Passwort auslesen, es sei denn, du hast es mit dem Nutzerkonto der Kinder eigenhändig eingegeben, dann kann deren Konto es auch lesen.
Also: pw im Kindernutzerkonto löschen, als Admin neu eingeben, fertig.
Nur Admins könne das WLAN-Passwort auslesen, es sei denn, du hast es mit dem Nutzerkonto der Kinder eigenhändig eingegeben, dann kann deren Konto es auch lesen.
Also: pw im Kindernutzerkonto löschen, als Admin neu eingeben, fertig.
Zitat von @DerWoWusste:
Hier liegt ein simpler Fehler vor.
Nur Admins könne das WLAN-Passwort auslesen, es sei denn, du hast es mit dem Nutzerkonto der Kinder eigenhändig eingegeben, dann kann deren Konto es auch lesen.
Also: pw im Kindernutzerkonto löschen, als Admin neu eingeben, fertig.
Hier liegt ein simpler Fehler vor.
Nur Admins könne das WLAN-Passwort auslesen, es sei denn, du hast es mit dem Nutzerkonto der Kinder eigenhändig eingegeben, dann kann deren Konto es auch lesen.
Also: pw im Kindernutzerkonto löschen, als Admin neu eingeben, fertig.
Ich vermute das eingesetzt OPSI verteilt das Kennwort unter dem Benutzerkonto.
Ich kann DWWs Aussage zumindest bestätigen. Wenn ich es als Admin eingebe und dann mit einem nicht-Adminkonto auslese, dann erhalte ich nur "vorhanden" beim Sicherheitsschlüssel.
