Hallo zusammen
Wie kann ich in einem Netzwerk (Win2003 Domäne mit XP Prof./2000 Prof. Clients) verhindern, dass sich ein (nur ein) Benutzer Laufwerke unter Benutzung von anderen Benutzerdaten anhängt? (Benutzer XXX verbindet sich mit einem Netzlaufwerk als Benutzer YYY.)
Die Gruppe Domain Guests kann ich nicht benutzen, da damit das Profil gelöscht würde. (Nachdem sich der Benutzer abmeldet)
Gibt es eventuelle eine Richtlinie, die ich noch nicht gefunden habe?
Danke und Grüsse,
Mathias
Hallo Mathias,
da gibt es nur eins: das Passwort für den User YYY ändern und nicht bekanntgeben.
Grüße aus Essen
Wolfgang
Hi,
nur so zur Anregung.
http://www.nwlab.net/art/system-error-1219/systemfeh…
Ist natürlich nicht 100%ig
HTH
Quaser
Hallo Wolfgang,
ja das wäre sicher die einfachste Möglichkeit, Danke für die rasche Antwort. Leider aber muss der Benutzer beide Logins haben.
Wir wollen für einen Benutzer für die interne Anmeldung einen anderen Login haben als für eine Verbindung von extern (Einwahlverbindung, Accesspoints, …). Daher soll der Benutzer zwei Logins erhalten.
Der Login für die interne Anmeldung soll alle „normalen“ Rechte, ausser der Anmeldung von extern erhalten. Der Benutzer für den externen Zugang soll dann über einen VPN-Client eine Verbindung aufbauen können. Er soll seine Mails abfragen können, was eine Verbindung zum Exchange voraussetzt. Zudem soll er über eine Freigabe auf sein PST-File zugreifen können. Aber er soll sich nicht von extern mit anderen Netzlaufwerken verbinden können.
Wenn er bei anderen Unternehmens-Standorten ist, kann er sich innerhalb vom Netzwerk mit seinem internen Login anmelden und hat dann über VPN-Verbindungen auch Zugriff auf alle sonst zur Verfügung stehenden Daten.
Sorry, eventuelle hätte ich das schon in der ersten Mitteilung erwähnen sollen.
Grüsse,
Mathias
Hallo Quaser
Der Artikel besagt, dass, wenn das Profil auf dem Fileserver liegt und das Homedrive, welches standardmässig angebunden wird auch dort liegt, es nicht möglich ist dieses zu trennen und somit ein LW desselben Servers unter einem anderen Benutzer zu verbinden.
Nun, das habe ich probiert und genau das war leider nicht der Fall.
Ich habe mich über Termineldienst auf einem Server angemeldet und vorher kontrolliert, das mein Profil auf dem Fileserver liegt. Habe auch im Profil ein Homedrive auf dem Fileserver eingetragen.
Das Homedrive wurde beim Logon verbunden, soweit OK, aber ich hatte, nachdem ich zwei Fehlermeldungen/Warnungen quittiert hatte, ein weiteres Netz-LW vom Fileserver unter einem anderen Benutzer verbunden. Auch das Trennen des Homedrive ging, nachdem ich eine Warnung quittiert hatte.
Nun ja, eventuelle muss ich das ganze nochmals von extern probieren. Aktuell bin ich ja von einem Server auf einen anderen Server gegangen, aber das sich dann alles anders verhält stand leider nicht in dem Artikel.
Werd mich dann nochmals melden, wenn ich es real von extern probiert habe, kann aber etwas dauern.
Grüsse,
Mathias
Hallo Quaser
Hab nun das ganze nohcmals neu eingestellt und es von extern probiert. Hat so funktioniert wie beschrieben. Danach ahbe ich es nochmals über den Terminalserver probiert und nun klappt es auch hier. Warum es vorhin nicht funktioniert hat - Keine Ahnung…
Leider limitiert diese Vorgehensweise nur den Zugriff auf einen Server. Also wird der Benutzer über unseren Terminalserver wieder unter einem anderen Benutzerlogin auf die Daten zugreifen können. Ist also leider auch nur etwas, um den Benutzer zum Nachdenken anzuregen.
Gibt es da nicht eventuelle Drittanbieter-Tools, mit denen man das realisieren kann?
Danke und Grüsse,
Mathias
Hallo Mathias,
Wir wollen für einen Benutzer für die interne Anmeldung einen
anderen Login haben als für eine Verbindung von extern
(Einwahlverbindung, Accesspoints, …). Daher soll der
Benutzer zwei Logins erhalten.
ist vollkommen richtig und gut gelöst.
Der Login für die interne Anmeldung soll alle „normalen“
Rechte, ausser der Anmeldung von extern erhalten.
ok, das ist gut
Der Benutzer
für den externen Zugang soll dann über einen VPN-Client eine
Verbindung aufbauen können.
VPN = Netzwerk, d.h. die Verbindung ist so, als ob er im „normalen“ Netz wäre.
Er soll seine Mails abfragen
können, was eine Verbindung zum Exchange voraussetzt.
aber mit dem zweiten Benutzeraccount?
Zudem soll er über eine Freigabe auf sein PST-File zugreifen können.
sorry, auf welches PST-File? Das lokale PST-File ist nur eine Kopie der Exchange-Ordner.
Aber er soll sich nicht von extern mit anderen Netzlaufwerken
verbinden können.
ok, dann Rechtsklick auf das Festplattenicon und die Rechte für die Benutzer entsprechend einstellen.
Wenn er bei anderen Unternehmens-Standorten ist, kann er sich
innerhalb vom Netzwerk mit seinem internen Login anmelden und
hat dann über VPN-Verbindungen auch Zugriff auf alle sonst zur
Verfügung stehenden Daten.
also als Benutzer1
Sorry, eventuelle hätte ich das schon in der ersten Mitteilung
erwähnen sollen.
ja, das wäre einfacher gewesen.
Grüße aus Essen
Wolfgang
Hallo Wolfgang
Wir wollen für einen Benutzer für die interne Anmeldung einen
anderen Login haben als für eine Verbindung von extern
(Einwahlverbindung, Accesspoints, …). Daher soll der
Benutzer zwei Logins erhalten.ist vollkommen richtig und gut gelöst.
Der Login für die interne Anmeldung soll alle „normalen“
Rechte, ausser der Anmeldung von extern erhalten.ok, das ist gut
Der Benutzer
für den externen Zugang soll dann über einen VPN-Client eine
Verbindung aufbauen können.VPN = Netzwerk, d.h. die Verbindung ist so, als ob er im
„normalen“ Netz wäre.Er soll seine Mails abfragen
können, was eine Verbindung zum Exchange voraussetzt.aber mit dem zweiten Benutzeraccount?
Der zweite Benutzer bekommt über den Exchange die nötigen Rechte dazu, das funktioniert ohne Probleme. (normales Recht für den Mailaccount und Recht für senden als)
Zudem soll er über eine Freigabe auf sein PST-File zugreifen können.
sorry, auf welches PST-File? Das lokale PST-File ist nur eine
Kopie der Exchange-Ordner.
Bei uns hat jeder Benutzer auf einer Freigabe auf dem Exchange-Server ein eigenes PST-File. Dieses wird für Archivzwecke verwendet. Es wird bei erreichen einer bestimmten Grösse mehrfach auf unerschiedlichen Medien gesichert und anschliessend vom Server gelöscht.
Aber er soll sich nicht von extern mit anderen Netzlaufwerken
verbinden können.ok, dann Rechtsklick auf das Festplattenicon und die Rechte
für die Benutzer entsprechend einstellen.
Unser Problem dabei ist nun folgendes:
Als Benutzer1 hat er die Rechte und als Benutzer 2 nicht. Wenn er von extern als Benutzer2 kommt kann er sich unter Verwendung der Anmeldedaten von Benutzer1 mit den Netzlaufwerken verbinden. Da er beide Benutzer braucht kann man ihm das Passwort für den Benutzer1 nicht vorenthalten.
Mit dem Trick über das servergespeicherte Profil kann ich Ihm den Zugriff für einen! Server verwehren. Aber dann könnte er sich auf unserem Terminalserver als Benutzer1 anmelden, wodurch er wiederum alle Rechte hat.
Problematisch wird das, wenn jemand wärend einer Session seinen Laptop hackt und so über die Rechte des Benutzers1 und des Benutzers2 in unser Netzwerk kommt. Da eine VPN-Verbindung über das Internet aufgebaut wird, muss er zwangsläufig dabei mit dem Internet verbunden sein. Dadurch ist er bereits potentiellen Angreifern ausgesetzt.
Wenn er bei anderen Unternehmens-Standorten ist, kann er sich
innerhalb vom Netzwerk mit seinem internen Login anmelden und
hat dann über VPN-Verbindungen auch Zugriff auf alle sonst zur
Verfügung stehenden Daten.also als Benutzer1
Richtig.
Sorry, eventuelle hätte ich das schon in der ersten Mitteilung
erwähnen sollen.ja, das wäre einfacher gewesen.
Grüße aus Essen
Wolfgang
… eventuelle ein Tip für ein Tool oder eine Funktion? MS oder nicht spielt bei uns zunächst keine grosse Rolle.
Bin dankbar für alle Tipps und Anregungen, die mich weiterbringen.
Grüsse aus Kreuzlingen,
Mathias
Vielleicht solltest Du über eine Policy verhindern, dass der Menüeintrag Netzwerklaufwerk vebinden, überhaupt erscheint, und dann alle Mappings per logon skript regeln.
Gruß
Peter
Hallo Mathias,
wenn man nun ein Script schreibt, das Benutzer1 deaktiviert, wenn Benutzer2 sich angemeldet hat!? Dann wäre dein Problem gelöst!?
Was ist alternativ mit einer zeitlichen Limitierung?
Grüße aus Essen
Wolfgang
Vielleicht solltest Du über eine Policy verhindern, dass der
Menüeintrag Netzwerklaufwerk vebinden, überhaupt erscheint,
und dann alle Mappings per logon skript regeln.
Auf gut Deutsch heisst das dann, ich müsste auch dafür sorgen, dass er den Befehl „NET USE“ nicht benutzen kann und sich auch nicht an unserem Terminalserver als Benutzer 1 anmelden kann.
Das bedeutet dann, dass er kein DOS-Fenster öffnen kann, also die Eingabeaufforderung nicht anzeigen lassen und auch die Möglichkeit unter Start „Ausführen…“ aufzurufen unterbunden werden muss. (DOS-Fenster kann hier mit CMD.exe aufgerufen werden)
Dann noch das Recht oder die Möglichkeit entziehen, sich am Terminalserver anzumelden. Also möglicherweise Hyperterminal und Remotedesktopverbindungen nicht anzeigen lassen.
Wenn nun aber der Benutzer schlau ist, (was bei uns der Fall ist, da wir auch ehemalige Administratoren als normale Benutzer hier haben) kann er doch lokal auf seinem Rechner nach den entsprechenden EXE-Dateien suchen und über diese die Eingabeaufforderung und/oder die Remotedesktop-Verbindung benutzen.
Also müssen die Dateien gelöscht werden, damit er sie nicht finden kann. Was nun aber, wenn er von einem anderen Rechner diese Dateien kopiert? Also das Recht nehmen, ausführbare Dateien auf dem Rechner zu schreiben/kopieren…
Bei längerem Überlegen wird der Rattenschwanz dann immer länger, zumal der Benutzer um den es hauptsächlich geht, lokale Administrationsrechte auf seinem Laptop benötigt.
Du siehst, ganz so einfach ist die Lösung leider nicht.
Aber trozdem vielen Dank für deinen Hinweis. Vermutlich ist es wirklich am sinnvollsten den ersten Benutzer zu deaktivieren, wenn der zweite Benutzer sich von extern verbindet. (http://www.wer-weiss-was.de/cgi-bin/forum/showarchiv…)
Gruß
Peter
Grüsse,
Mathias
Hallo Wolfgang
Die Zeitliche Limitierung? vermutlich eher nicht. Dann müssten wir mit dem Benutzer definieren, wann er sich von extern anmelden darf und wann nicht. Wenn wir dann z. Bsp. Nachts seinen internen Logon sperren, er aber dringend noch in der Firma etwas fertig machen muss, kann er sich nicht anmelden. Das wird vermutlich zu kompliziert.
Hmmmm… - Ein Script - Nun ja, warscheinlich ist das DIE Lösung. Nur: Leider habe ich in Bezug auf Scripte quasi keine Erfahrung.
Wenn Du ein Script vorschlägst hast Du doch sicher Erfahrungen mit Scripten. Gibt es eine Methode, um sich möglichst rasch umfassend zu informieren, welche Art von Script hier sinnvoll ist und sich dann in die Thematik einzuarbieten?
Gibt es da sinnvolle Bücher?
Grundlagen-Tutorials?
Anfänger-Hints?
Eventuelle die Möglichkeit irgendwo Teile von Scripten einzusehen, die man modifizieren und dann zusammenfügen kann um ein funktionierendes Ergebis zu erhalten?
Vermutlich müsste ich ein Script wie folgendes erstellen:
START
IF {Benutzer_2=online}
THAN {Benutzer_1.sperren}
ELSE {Benutzer_1.freigeben}
GOTO START
oder besser …
START
IF {Benutzer_2=online}
THAN {IF {Benutzer_1=gesperrt}
THAN {GOTO START}
ELSE {Benutzer_1.sperren}
}
ELSE {IF {Benutzer_1=gesperrt}
THAN {Benutzer_1.freigeben}
ELSE {GOTO START}
}
GOTO START
… weil hier das Setzen des Wertes für (gesperrt/nicht gesperrt) nur einmal gemacht wird.
Das fertige Script müsste dann vermutlich auf einem der DC´s gestartet werden und ständig im Hintergrund laufen (Registry-Eintrag unter …\RUN, damit es nach einem Reboot auch wieder läuft). Wie sieht es aber dann mit der Performance aus? Wir haben nur 2 DC´s im Netz, von denen einer zudem noch ein File- und Printserver ist. Die sollten nicht überlastet werden.
Wenn man nun mehrere Benutzer hat, bei denen es identisch sein soll, kann man dann das Script für mehrere Benutzer anpassen oder muss man dann mehrere scripte laufen lassen? Kann man eine Tabelle mit Benutzernamen-Paaren anlegen auf die das Script zugreift und welche der Reihe nach immer wieder von vorne beginnend ausgelesen wird?
Du siehst, vom logischen Denken her sollte es eigentlich kein Problem sein, nur die Grundlagen zum Scripting und die Erfahrung brauchen wohl noch viel „Nachhilfe“.
Eventuelle hast Du mir ja ein paar nützliche Tipps zum Scripting, damit ich das hinbekommen kann? oder ist es eventuelle besser ich wandere mit dem Thema jetzt in ein Brett zum Thema Scripting?
Danke und Grüsse aus Kreuzlingen,
Mathias
[Bei dieser Antwort wurde das Vollzitat nachträglich automatisiert entfernt]
Hallo Mathias,
Hmmmm… - Ein Script - Nun ja, warscheinlich ist das DIE
Lösung. Nur: Leider habe ich in Bezug auf Scripte quasi keine
Erfahrung.
das sind eigentlich ganz normale Batch-, Java-, VB-Scripte.
Wenn Du ein Script vorschlägst hast Du doch sicher Erfahrungen
mit Scripten.
no, sorry, bin kein Scriptmaster
Gibt es eine Methode, um sich möglichst rasch
umfassend zu informieren, welche Art von Script hier sinnvoll
ist und sich dann in die Thematik einzuarbieten?
nun ja, da hilft das I-Net:
http://www.administrator.de/Benutzer_per_Skript_hinz…
http://www.mcseboard.de/showthread.php?t=13316&page=2
Gibt es da sinnvolle Bücher?
bestimmt 
Grundlagen-Tutorials?
M$ - Knollagebase
Anfänger-Hints?
I-Net, google mal nach:
Script +benutzer +abmeldung
bzw. nach der englischen Variante:
Script +user +disable
Eventuelle die Möglichkeit irgendwo Teile von Scripten
einzusehen, die man modifizieren und dann zusammenfügen kann
um ein funktionierendes Ergebis zu erhalten?
s.o.
Vermutlich müsste ich ein Script wie folgendes erstellen:
nö, nicht so kompliziert, beim Anmelden von B1 den B2 deaktivieren.
Allerdings bringt das auch alles nichts, wenn der User B1 sich gleich mit B2 anmeldet, fällt mir gerade so ein …??
Das fertige Script müsste dann vermutlich auf einem der DC´s
gestartet werden und ständig im Hintergrund laufen
(Registry-Eintrag unter …\RUN, damit es nach einem Reboot
auch wieder läuft).
nein nur als Anmeldescript für den entspr. Benutzer.
Wenn man nun mehrere Benutzer hat, bei denen es identisch sein
soll, kann man dann das Script für mehrere Benutzer anpassen
oder muss man dann mehrere scripte laufen lassen?
pro Benutzer 1 x ein Anmeldescript!
Kann man
eine Tabelle mit Benutzernamen-Paaren anlegen auf die das
Script zugreift und welche der Reihe nach immer wieder von
vorne beginnend ausgelesen wird?
ja, siehe die I-Net Beispiele
Du siehst, vom logischen Denken her sollte es eigentlich kein
Problem sein, nur die Grundlagen zum Scripting und die
Erfahrung brauchen wohl noch viel „Nachhilfe“.
wir lernen alle täglich hinzu
Eventuelle hast Du mir ja ein paar nützliche Tipps zum
Scripting, damit ich das hinbekommen kann? oder ist es
eventuelle besser ich wandere mit dem Thema jetzt in ein Brett
zum Thema Scripting?
schneller und effektiver wäre ein Posting im entsprechnden Brett!
Grüße aus Essen
Wolfgang
Hallo Mathias,
I-Net, google mal nach:
Script +benutzer +abmeldung
S(K)RIPT in deutsch
gerade noch gefunden:
http://www.microsoft.com/technet/prodtechnol/windows…
hier einige sehr gute Beispiele:
http://www.cruto.com/resources/vbscript/vbscript-exa…
gesucht nach: 2003 +server +script +disable +user
Grüße aus Essen
Wolfgang
Hallo Mathias,
ich möchte Dir einmal kurz schildern, wie die Sicherheit in unserem Netz gewährleistet wird:
Jeder „normale“ Domänen-Benutzer bekommt ein Homeshare als Laufwerk U: per VB-Skript gemapped. Darauf hat nur der entprechende User Zugriff und die Dom.Admins (wegen Backup usw.)
Es gibt noch weitere Laufwerke, jeweils abhängig von Standort und Gruppenmitgliedschaft.
Alle anderen Verzeichnisrechte werden über Gruppen gesteuert.
Als wichtigste Policies haben wir eine userpolicy, in der wir nicht Programme verbieten, sondern erlauben. (Eine Liste kann ich Dir gerne zukommen lassen).
Hier setzen wir auch folgende Einstellungen:
Natürlich haben wir noch eine Adminpolicy, die die Userpol überschreibt
Wenn der ehemalige Admin nun ein normaler User ist, erreichst du, mit noch ein paar kleinen gimmicks mehr, eine relative Sicherheit auf Benutzerebene.
Jetzt musst Du noch die Clientseite betrachten:
Wir lassen nur Anmeldungen von Rechnern zu, die Mitglied der Domäne sind. Damit wirken auch die Dom. Policies. Du hast dann zwar Adminrechte auf der Maschine, aber nicht im Netz.
Jetzt muss sich der User komplett als anderer User neu anmelden, um die Laufwerke zu bekommen.
OK, ich weiss, dass sowas eine Menge Arbeit und Pflege bedeutet, da in unserem Netz aber verschiedene Firmen in unterschiedlichen Lokationen integriert sind, ist das unbedingt notwendig.
somit,
Vielleicht solltest Du über eine Policy verhindern, dass der
Menüeintrag Netzwerklaufwerk vebinden, überhaupt erscheint,
und dann alle Mappings per logon skript regeln.Auf gut Deutsch heisst das dann, ich müsste auch dafür sorgen,
dass er den Befehl „NET USE“ nicht benutzen kann und sich auch
nicht an unserem Terminalserver als Benutzer 1 anmelden kann.
da nicht in userpolicy eingetragen, darf diese nicht ausgeführt werden
am TS anmelden schon, aber nicht gleichzeitig.
Warum kennt der eigentlich das Passwort der anderen Users ?
Das bedeutet dann, dass er kein DOS-Fenster öffnen kann, also
die Eingabeaufforderung nicht anzeigen lassen und auch die
Möglichkeit unter Start „Ausführen…“ aufzurufen unterbunden
werden muss. (DOS-Fenster kann hier mit CMD.exe aufgerufen
werden)
cmd.exe ist nicht erlaubt
Dann noch das Recht oder die Möglichkeit entziehen, sich am
Terminalserver anzumelden. Also möglicherweise Hyperterminal
und Remotedesktopverbindungen nicht anzeigen lassen.
Bei uns:
RDP ist nur admins erlaubt.
ICA (Citrix) darf jeder
MSTSC.EXE ist auch nicht in der Liste der erlaubten Programme
Wenn nun aber der Benutzer schlau ist, (was bei uns der Fall
ist, da wir auch ehemalige Administratoren als normale
Benutzer hier haben) kann er doch lokal auf seinem Rechner
nach den entsprechenden EXE-Dateien suchen und über diese die
Eingabeaufforderung und/oder die Remotedesktop-Verbindung
benutzen.
Er kann alles mit den Programmen machen, ausser in der Domäne ausführen.
mstsc kann er ausführen, darf sich aber nicht an unseren Servern per RDP anmelden, sondern nur mit Citrix an den richtigen Terminalservern.
Also müssen die Dateien gelöscht werden, damit er sie nicht
finden kann. Was nun aber, wenn er von einem anderen Rechner
diese Dateien kopiert? Also das Recht nehmen, ausführbare
Dateien auf dem Rechner zu schreiben/kopieren…
Keine Datei muss gelöscht werden. Es hat ja je nach Berechtigung nur der eine, oder der andere User Zugriff, ausser auf gemeinsame Laufwerke.
Gruß
Peter
Hallo Wolfgang
Vielen Dank für die Links, zusammen mit einem Kollegen haben wir nun zwei VB-Skripte geschrieben bzw. kopiert und angepasst. Eines zum Deaktivieren und eines zum Aktivieren eines Benutzers.
Wir müssen jetzt nur noch das Skript anpassen, sodass aus dem Namen des aktuell angemeldeten Benutzers der Name des zu bearbeitenden Benutzers generiert werden kann. Das sollte aber kein Problem sein, da wir vorhaben die Namen internen Benutzer zu nehmen und durch einen Anhang zu erweitern. (Benutzer Benutzer_ext)
Diese Anpassung ist nötig, da über das Profil lediglich ein Anmeldeskript ausgeführt werden kann. Das Abmeldeskript muss also zwangsläufig über die Policy der OU gestartet werden, wobei es dann für alle Benutzer funktionieren muss.
Ach so, fast vergessen: Die Berechtigung die der BenutzerX_ext auf das Konto von BenutzerX haben muss sind Read & Write Account Restrictions. Ohne diese Berechtigungen kann das Skript nicht ausgeführt werden.
Nochmals vielen Dank für die Infos und Unterstützung. Eigentlich hättest Du einige Sternchen verdient, aber leider kann ich noch keine vergeben.
Grüsse aus Kreuzlingen,
Mathias
Hallo Mathias,
ich möchte Dir einmal kurz schildern, wie die Sicherheit in
unserem Netz gewährleistet wird:Jeder „normale“ Domänen-Benutzer bekommt ein Homeshare als
Laufwerk U: per VB-Skript gemapped. Darauf hat nur der
entprechende User Zugriff und die Dom.Admins (wegen Backup
usw.)
Bei uns gibt es keine Homeshares in diesem Sinne.
Es gibt noch weitere Laufwerke, jeweils abhängig von Standort
und Gruppenmitgliedschaft.
Alle anderen Verzeichnisrechte werden über Gruppen gesteuert.
Ist bei uns auch so.
Als wichtigste Policies haben wir eine userpolicy, in der wir
nicht Programme verbieten, sondern erlauben. (Eine Liste kann
ich Dir gerne zukommen lassen).
Hier setzen wir auch folgende Einstellungen:
- Ausblenden von „Ausführen“
- Ausblenden von „Ausführen als“
- Es dürfen keine FQN’s im Explorer eingegeben werden ( BSP.:
\server\freigabe$)- InternetExplorer Einstellungen werden vorgegeben und dürfen
nicht geändert werden.Natürlich haben wir noch eine Adminpolicy, die die Userpol
überschreibtWenn der ehemalige Admin nun ein normaler User ist, erreichst
du, mit noch ein paar kleinen gimmicks mehr, eine relative
Sicherheit auf Benutzerebene.
Jetzt musst Du noch die Clientseite betrachten:
Wir lassen nur Anmeldungen von Rechnern zu, die Mitglied der
Domäne sind. Damit wirken auch die Dom. Policies. Du hast dann
zwar Adminrechte auf der Maschine, aber nicht im Netz.
Jetzt muss sich der User komplett als anderer User neu
anmelden, um die Laufwerke zu bekommen.OK, ich weiss, dass sowas eine Menge Arbeit und Pflege
bedeutet, da in unserem Netz aber verschiedene Firmen in
unterschiedlichen Lokationen integriert sind, ist das
unbedingt notwendig.
Klingt sehr kompliziert. Da wir das Problem sehr warscheinlich mit An- und Abmelde-Scripten erschlagen können (Siehe Diskussion mit Netwolf) lasse ich das Thema mal draussen. Es lohnt sich wohl erst sich darin zu vertiefen, wenn man damit arbieten muss. Ansonsten eignet man sich Wissen an, welches braach liegt und nach und nach wieder verlohren geht.
somit,
Vielleicht solltest Du über eine Policy verhindern, dass der
Menüeintrag Netzwerklaufwerk vebinden, überhaupt erscheint,
und dann alle Mappings per logon skript regeln.Auf gut Deutsch heisst das dann, ich müsste auch dafür sorgen,
dass er den Befehl „NET USE“ nicht benutzen kann und sich auch
nicht an unserem Terminalserver als Benutzer 1 anmelden kann.da nicht in userpolicy eingetragen, darf diese nicht
ausgeführt werden
am TS anmelden schon, aber nicht gleichzeitig.
Warum kennt der eigentlich das Passwort der anderen Users ?
Er benutzt einen User, wenn er sich im Netz Anmeldet. Den anderen Benutzt er, wenn er sich über VPN verbindet. Der Benutzer für VPN soll weniger Rechte besitzen als der interne User. Deshalb muss verhindert werden, dass er sich, wenn er über VPN mit dem externen User kommt über die Rechte des internen Users an gewissen Ressourcen anmelden kann. Das funktioniert, wenn man beim Login den internen User sperrt und beim Logout wieder freigibt.
Sollte die Freigabe des internen Users beim Logout des externen Users mal nicht funktioineren kann sich der User intern mit dem externen User anmalden und wieder abmelden. Danach sollte der interne User freigegeben sein.
Das bedeutet dann, dass er kein DOS-Fenster öffnen kann, also
die Eingabeaufforderung nicht anzeigen lassen und auch die
Möglichkeit unter Start „Ausführen…“ aufzurufen unterbunden
werden muss. (DOS-Fenster kann hier mit CMD.exe aufgerufen
werden)cmd.exe ist nicht erlaubt
Dann noch das Recht oder die Möglichkeit entziehen, sich am
Terminalserver anzumelden. Also möglicherweise Hyperterminal
und Remotedesktopverbindungen nicht anzeigen lassen.Bei uns:
RDP ist nur admins erlaubt.
ICA (Citrix) darf jeder
MSTSC.EXE ist auch nicht in der Liste der erlaubten ProgrammeWenn nun aber der Benutzer schlau ist, (was bei uns der Fall
ist, da wir auch ehemalige Administratoren als normale
Benutzer hier haben) kann er doch lokal auf seinem Rechner
nach den entsprechenden EXE-Dateien suchen und über diese die
Eingabeaufforderung und/oder die Remotedesktop-Verbindung
benutzen.Er kann alles mit den Programmen machen, ausser in der Domäne
ausführen.
mstsc kann er ausführen, darf sich aber nicht an unseren
Servern per RDP anmelden, sondern nur mit Citrix an den
richtigen Terminalservern.Also müssen die Dateien gelöscht werden, damit er sie nicht
finden kann. Was nun aber, wenn er von einem anderen Rechner
diese Dateien kopiert? Also das Recht nehmen, ausführbare
Dateien auf dem Rechner zu schreiben/kopieren…Keine Datei muss gelöscht werden. Es hat ja je nach
Berechtigung nur der eine, oder der andere User Zugriff,
ausser auf gemeinsame Laufwerke.Gruß
Peter
Vielen Dank trozdem für Deine ausführlichen Beschreibungen, aber wir versuchen erst mal mit den Skripten das Problem zu lösen. Lokal hat es bereits gut funktioniert, jetzt müssen wir die Skripte noch ein wenig modifizieren, sodass man sie universell für alle User benutzen kann und dann das Ganze von extern und unter realen Bedingungen testen. Das sollte aber eigentlich kein Problem darstellen.
Grüsse,
Mathias