19
Win 7 Prof 32bit - Wie das "Klauen" einer bestehenden RDP-Verbindung verhindern
Hallo Leute.
Wir nutzen mit verschiedenen Mitarbeitern für ein Projekt eine RDP-Session zu einem bestimmten Windows 7 Prof. (32bit)-PC. Dort wird sich mit derselben Benutzerkennung angemeldet.
Doof ist, dass man sich eine bereits bestehende RDP-Session des Mitarbeiters A einfach von einem anderen Mitarbeiter (B, C, D etc.) klauen kann.
Wie kann ich das unterbinden?
Erst wenn Mitarbeiter A fertig ist und das Programm dort geschlossen und sich (dadurch automatisch) vom RDP-Client abgemeldet hat, soll ein anderer Mitarbeiter sich per RDP einloggen können.
Geht das?
Herzlichen Dank.
Jörg
Wir nutzen mit verschiedenen Mitarbeitern für ein Projekt eine RDP-Session zu einem bestimmten Windows 7 Prof. (32bit)-PC. Dort wird sich mit derselben Benutzerkennung angemeldet.
Doof ist, dass man sich eine bereits bestehende RDP-Session des Mitarbeiters A einfach von einem anderen Mitarbeiter (B, C, D etc.) klauen kann.
Wie kann ich das unterbinden?
Erst wenn Mitarbeiter A fertig ist und das Programm dort geschlossen und sich (dadurch automatisch) vom RDP-Client abgemeldet hat, soll ein anderer Mitarbeiter sich per RDP einloggen können.
Geht das?
Herzlichen Dank.
Jörg
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 356354
Url: https://administrator.de/contentid/356354
Ausgedruckt am: 22.11.2024 um 17:11 Uhr
19 Kommentare
Neuester Kommentar
Hi,
Das wird dein Problem sein, geht es nicht mit mehreren Benutzern?
Dann bekommt der angemeldete eine Meldung und kann das klauen auch verhindern.
Anders weiß ich da auch nichts.
VG,
Deepsys
Das wird dein Problem sein, geht es nicht mit mehreren Benutzern?
Dann bekommt der angemeldete eine Meldung und kann das klauen auch verhindern.
Anders weiß ich da auch nichts.
VG,
Deepsys
Hi,
mit ein und demselben Benutzerkonto geht das nicht. Aber warum hat nicht jeder Mitarbeiter sein eigenes Konto? Das hast Du dieses Problem überhaupt nicht. Selbst wenn eine Sitzung getrennt werden sollte, so würde ein anderer Mitarbeiter mit seinem Konto nicht an die Sitzung der anderen Mitarbeiter (Konten) kommen (Inhalte sehen).
E.
mit ein und demselben Benutzerkonto geht das nicht. Aber warum hat nicht jeder Mitarbeiter sein eigenes Konto? Das hast Du dieses Problem überhaupt nicht. Selbst wenn eine Sitzung getrennt werden sollte, so würde ein anderer Mitarbeiter mit seinem Konto nicht an die Sitzung der anderen Mitarbeiter (Konten) kommen (Inhalte sehen).
E.
Hallo,
Aus Sicherheitsgründen immer: 1 Login = 1 Mitarbeiter !
Gruß
SH
Aus Sicherheitsgründen immer: 1 Login = 1 Mitarbeiter !
Gruß
SH
Hallo SachsenHessi,
für fast alle Anwendungen wird das bei uns so gehandhabt und das ist klar.
Bei EINER bestimmten Anwendung machen wir es bewusst anders und das hat seine Gründe.
Deshalb einfach die Frage: Wie verhindere ich konkurrierende RDP-Nutzung bei einer Benutzerkennung? Geht das? Ja oder nein?
Grüße
Jörg
für fast alle Anwendungen wird das bei uns so gehandhabt und das ist klar.
Bei EINER bestimmten Anwendung machen wir es bewusst anders und das hat seine Gründe.
Deshalb einfach die Frage: Wie verhindere ich konkurrierende RDP-Nutzung bei einer Benutzerkennung? Geht das? Ja oder nein?
Grüße
Jörg
Moin,
Deswegen gibt es Terminal-Server.
Mit einem normalen W7 hast Du keine Möglichkeit, die Session vor dem "gleichen" User zu schützen.
Wenn die User "gutmütig" sind, kann man das durch einen für alle sichtbaren Semaphor lösen.
lks
Deswegen gibt es Terminal-Server.
Mit einem normalen W7 hast Du keine Möglichkeit, die Session vor dem "gleichen" User zu schützen.
Wenn die User "gutmütig" sind, kann man das durch einen für alle sichtbaren Semaphor lösen.
lks
Hi Lochkartenstanzer,
ja, das würde dann auch der nächste Schritt sein. Um es aber für Versuche zur Entscheidungsfindungen einfach zu halten, eben eine RDP-Lösung mit einer Benutzerkennung.
Das wäre schade, wenn das nicht zu unterbinden ist. Nun gut.
Dann eben nicht RDP, sondern eine Bildschirmfreigabe ala VNC oder TeamViewer etc. Da müsste konkurrierende ANmeldung zu unterbinden sein, denke ich.
LG
Jörg
ja, das würde dann auch der nächste Schritt sein. Um es aber für Versuche zur Entscheidungsfindungen einfach zu halten, eben eine RDP-Lösung mit einer Benutzerkennung.
Das wäre schade, wenn das nicht zu unterbinden ist. Nun gut.
Dann eben nicht RDP, sondern eine Bildschirmfreigabe ala VNC oder TeamViewer etc. Da müsste konkurrierende ANmeldung zu unterbinden sein, denke ich.
LG
Jörg
Moin,
AUch das löst dein Problem nicht, denn dann sehen alle immer den selben Desktop.
Wenn USer A dann Liebesbriefe an die Sekretärin schreibt, sehen das die anderen User direkt mit.
Außer, du lässt (via VNC) immer nur eine Verbindung zu, aber wenn Mitarbeiter A dann vergisst, seinen VNC-Client zu schließen, kommt keiner mehr dran...
Dein Problem lässt sich somit nur sauber mit einem TerminalServer lösen...
Gruß
em-pie
Zitat von @Server-Nutzer:
Dann eben nicht RDP, sondern eine Bildschirmfreigabe ala VNC oder TeamViewer etc. Da müsste konkurrierende ANmeldung zu unterbinden sein, denke ich.
Dann eben nicht RDP, sondern eine Bildschirmfreigabe ala VNC oder TeamViewer etc. Da müsste konkurrierende ANmeldung zu unterbinden sein, denke ich.
AUch das löst dein Problem nicht, denn dann sehen alle immer den selben Desktop.
Wenn USer A dann Liebesbriefe an die Sekretärin schreibt, sehen das die anderen User direkt mit.
Außer, du lässt (via VNC) immer nur eine Verbindung zu, aber wenn Mitarbeiter A dann vergisst, seinen VNC-Client zu schließen, kommt keiner mehr dran...
Dein Problem lässt sich somit nur sauber mit einem TerminalServer lösen...
Gruß
em-pie
Was Du versuchen kannst:
(alle diese zusammen!)
1. Eine Geplante Aufgabe mit Trigger "Bei Anmeldung"
hier das Kommando "change logon /disable" ausführen lassen ---> Das können standardmäßig nur Admins. Müsste man testen
2. Eine Geplante Aufgabe mit Trigger "Bei Verbindung mit der Benutzersitzung"
hier das Kommando "change logon /disable" ausführen lassen ---> Das können standardmäßig nur Admins. Müsste man testen
3. Eine Geplante Aufgabe mit Trigger "Bei Trennung von Benutzersitzung"
hier das Kommando "change logon /enable" ausführen lassen ---> Das können standardmäßig nur Admins. Müsste man testen
4. Eine Benutzer-Logoffscript (z.B. per GPO)
hier das Kommando "change logon /enable" ausführen lassen ---> Das können standardmäßig nur Admins. Müsste man testen
5. Eine Computer-Startupscript (z.B. per GPO)
hier das Kommando "change logon /enable" ausführen lassen ---> Das können standardmäßig nur Admins. Müsste man testen
Oder
Ein Powershell-Script im Hintergrund, welches beim Starten des Computers startet und welches immer läuft. Dieses überwacht die Sitzungen. Solange die Sitzung verbunden ist gilt "change logon /disable"
Wenn die Sitzung abgemeldet oder getrennt ist wird "change logon /enable" ausgeführt
Dieses Script würde als LocalSystem laufen und hätte damit ausreichend Berechtigungen.
(alle diese zusammen!)
1. Eine Geplante Aufgabe mit Trigger "Bei Anmeldung"
hier das Kommando "change logon /disable" ausführen lassen ---> Das können standardmäßig nur Admins. Müsste man testen
2. Eine Geplante Aufgabe mit Trigger "Bei Verbindung mit der Benutzersitzung"
hier das Kommando "change logon /disable" ausführen lassen ---> Das können standardmäßig nur Admins. Müsste man testen
3. Eine Geplante Aufgabe mit Trigger "Bei Trennung von Benutzersitzung"
hier das Kommando "change logon /enable" ausführen lassen ---> Das können standardmäßig nur Admins. Müsste man testen
4. Eine Benutzer-Logoffscript (z.B. per GPO)
hier das Kommando "change logon /enable" ausführen lassen ---> Das können standardmäßig nur Admins. Müsste man testen
5. Eine Computer-Startupscript (z.B. per GPO)
hier das Kommando "change logon /enable" ausführen lassen ---> Das können standardmäßig nur Admins. Müsste man testen
Oder
Ein Powershell-Script im Hintergrund, welches beim Starten des Computers startet und welches immer läuft. Dieses überwacht die Sitzungen. Solange die Sitzung verbunden ist gilt "change logon /disable"
Wenn die Sitzung abgemeldet oder getrennt ist wird "change logon /enable" ausgeführt
Dieses Script würde als LocalSystem laufen und hätte damit ausreichend Berechtigungen.
Hallo Jörg,
man könnte die Windows-Firewall skripten, sodass RDP allgemein (bis auf die aktuelle Client IP) geblockt wird, wenn sich ein Nutzer anmeldet.
Grüße
Richard
man könnte die Windows-Firewall skripten, sodass RDP allgemein (bis auf die aktuelle Client IP) geblockt wird, wenn sich ein Nutzer anmeldet.
Grüße
Richard
...ich finde ja immer prima, welche Phantasien da doch hochpoppen ("Wenn USer A dann Liebesbriefe an die Sekretärin schreibt, sehen das die anderen User direkt mit."), haha Meine Güte...
Der RDP-PC ist derzeit so konfiguriert, dass bei Remote-Anmeldung eine ganz bestimmte Programmoberfläche startet, man diese nutzen kann, dann das Programm beendet und automatisch wird der User sofort disconnectet (Prozess des Programmes wird ge-monitort und meldet bei Verschwinden den Benutzer ab).
Das Powershell-Script klingt interessant. Wie ginge denn das, emeriks?
Ich denke da an Autostart-Ordner, Powershell-Script führt "change logon /disable" aus, startet mein Programm, wenn Programm beendet, "change logon /enable", dann automatisch abmelden des Nutzers. Wäre das so?
Meine Güte...Der RDP-PC ist derzeit so konfiguriert, dass bei Remote-Anmeldung eine ganz bestimmte Programmoberfläche startet, man diese nutzen kann, dann das Programm beendet und automatisch wird der User sofort disconnectet (Prozess des Programmes wird ge-monitort und meldet bei Verschwinden den Benutzer ab).
Das Powershell-Script klingt interessant. Wie ginge denn das, emeriks?
Ich denke da an Autostart-Ordner, Powershell-Script führt "change logon /disable" aus, startet mein Programm, wenn Programm beendet, "change logon /enable", dann automatisch abmelden des Nutzers. Wäre das so?
Mein genanntes Beispiel sollte eigentlich nur zeigen, dass selbst mit VNC o.Ä. kein gleichzeitiges Arbeiten von mehreren Mitarbeitern möglich ist.
Übrigens gilt das auch nicht für emeriks Trigger:
Wenn User A sich angemeldet hat, werden weitere Anmeldungen blockiert. Auch hier können keine zwei User gleichzeitig arbeiten.
Und wenn das eh nicht der Fall ist (also das ein Parallelbetrieb stattfindet), dann hast du doch gar kein Problem!?
Nochmal zusammengefasst:
Du bist mit Windows7 nicht in der Lage zwei Desktops parallel zu nutzen, selbst bei verschiedenen Benutzern.
EIn CLIENT-Betriebssystem ist eine SingleUser-Umgebung, gemacht für einen User. TerminalServer indes erlaubt es, je nach Ressourcen 1-50 User parallel arbeiten zu lassen (mehr als 50 sicherlich auch machbar, aber will man das!?)
Übrigens gilt das auch nicht für emeriks Trigger:
Wenn User A sich angemeldet hat, werden weitere Anmeldungen blockiert. Auch hier können keine zwei User gleichzeitig arbeiten.
Und wenn das eh nicht der Fall ist (also das ein Parallelbetrieb stattfindet), dann hast du doch gar kein Problem!?
Nochmal zusammengefasst:
Du bist mit Windows7 nicht in der Lage zwei Desktops parallel zu nutzen, selbst bei verschiedenen Benutzern.
EIn CLIENT-Betriebssystem ist eine SingleUser-Umgebung, gemacht für einen User. TerminalServer indes erlaubt es, je nach Ressourcen 1-50 User parallel arbeiten zu lassen (mehr als 50 sicherlich auch machbar, aber will man das!?)
Nicht Autostart-Ordner.
Computer-Startup-Script oder Scheduled Task "bei Systemstart".
Das PS-Script könnte z.B. einfach die Ausgabe von "query session" auswerten.
Computer-Startup-Script oder Scheduled Task "bei Systemstart".
Das PS-Script könnte z.B. einfach die Ausgabe von "query session" auswerten.
Nochmal zusammengefasst:
Du bist mit Windows7 nicht in der Lage zwei Desktops parallel zu nutzen, selbst bei verschiedenen Benutzern.
EIn CLIENT-Betriebssystem ist eine SingleUser-Umgebung, gemacht für einen User. TerminalServer indes erlaubt es, je nach Ressourcen 1-50 User parallel arbeiten zu lassen (mehr als 50 sicherlich auch machbar, aber will man das!?)
Du bist mit Windows7 nicht in der Lage zwei Desktops parallel zu nutzen, selbst bei verschiedenen Benutzern.
EIn CLIENT-Betriebssystem ist eine SingleUser-Umgebung, gemacht für einen User. TerminalServer indes erlaubt es, je nach Ressourcen 1-50 User parallel arbeiten zu lassen (mehr als 50 sicherlich auch machbar, aber will man das!?)
Bitte NOCHMALS LESEN, was ich EINGANGS schrieb; "Erst wenn Mitarbeiter A fertig ist und das Programm dort geschlossen und sich (dadurch automatisch) vom RDP-Client abgemeldet hat, soll ein anderer Mitarbeiter sich per RDP einloggen können."
Eine sequentielle Nutzung, NICHT parallel!
Nicht persönlich nehmen, ich habe das Gefühl, das man heutzutage einfach nicht mehr gründlich liest. Dabei versuche ich, exakt zu formulieren, damit Klarheit über die Anforderung herrscht.
Ich nehme das nicht nur hier war, sondern es scheint ein Zeitgeist-Problem zu sein...
oh...
Mein Fehler, sorry.
Den Part hatte ich in der Tat übersehen. Dann vergiss meinen Mist Text
Mein Fehler, sorry.
Den Part hatte ich in der Tat übersehen. Dann vergiss meinen
1
Hallo.
Ein Batch-Skript schreiben, an zentraler Stelle in einer Netzwerkfreigabe ablegen, den Usern verknüpfen und den Usern beibringen, daß sie nur noch dieses Skript (bzw. die für alle gleiche Verknüpfung zu dem Skript) zur Verbindung verwenden sollen/müssen/dürfen.
In dem Skript steht natürlich der mstsc-Befehl drin, der erste der den Befehl ausführt, kriegt den Connect und das Skript schreibt eine Sperrdatei (*.lck) in die gleiche Freigabe, in der das Skript liegt. Vor dem mstsc-Befehl wird natürlich abgeprüft, ob schon eine Sperrdatei vorhanden ist (if exist). Falls ja, goto Echo Textausgabe "Ein anderer Benutzer verwendet bereits die Verbindung, bitte gedulden sie sich blablabla und versuchen Sie es später noch einmal"" und goto Ende, Skript beendet. Der, der den Connect mangels Sperrdatei vorher bekommen hat, muß das Skript natürlich im Hintergrund offenlassen, schließt er die Anwendung, wird die Sperrdatei gelöscht und das Skript beendet. So oder so ähnlich würde ich es mit einem Batch-Skript lösen. Aufbau, Syntax? Keine Ahnung, deswegen reine Theorie. Aber so müßte es gehen, meine ich.
Viele Grüße
von
departure69
Ein Batch-Skript schreiben, an zentraler Stelle in einer Netzwerkfreigabe ablegen, den Usern verknüpfen und den Usern beibringen, daß sie nur noch dieses Skript (bzw. die für alle gleiche Verknüpfung zu dem Skript) zur Verbindung verwenden sollen/müssen/dürfen.
In dem Skript steht natürlich der mstsc-Befehl drin, der erste der den Befehl ausführt, kriegt den Connect und das Skript schreibt eine Sperrdatei (*.lck) in die gleiche Freigabe, in der das Skript liegt. Vor dem mstsc-Befehl wird natürlich abgeprüft, ob schon eine Sperrdatei vorhanden ist (if exist). Falls ja, goto Echo Textausgabe "Ein anderer Benutzer verwendet bereits die Verbindung, bitte gedulden sie sich blablabla und versuchen Sie es später noch einmal"" und goto Ende, Skript beendet. Der, der den Connect mangels Sperrdatei vorher bekommen hat, muß das Skript natürlich im Hintergrund offenlassen, schließt er die Anwendung, wird die Sperrdatei gelöscht und das Skript beendet. So oder so ähnlich würde ich es mit einem Batch-Skript lösen. Aufbau, Syntax? Keine Ahnung, deswegen reine Theorie. Aber so müßte es gehen, meine ich.
Viele Grüße
von
departure69
Hi departure69,
klingt von Aufbau logisch und durchdacht. Wenn ich bloß programmieren könnte...
LG
Jörg
klingt von Aufbau logisch und durchdacht. Wenn ich bloß programmieren könnte...
LG
Jörg
klingt von Aufbau logisch und durchdacht. Wenn ich bloß programmieren könnte...
Na ja. Diese Lösung verhindert zum einem nicht, dass MSTSC auf andere Weise gestartet wird und damit die RDP-Verbindung, und zum anderen kannst Du Dir damit Arbeit machen, wenn die Sperr-Dateien nicht wieder gelöscht werden (z.B. weil die Batch - warum auch immer - abgebrochen wird). Dann müsste man jedes Mal manuell eingreifen und diese Dateien löschen, damit sich wieder jemand über diese Batch verbinden kann.Hast Du es schon mal mit den von mir erwähnten geplanten Aufgaben und Login- sowie Startup-Scripten versucht?
Ansonsten wäre vielleicht auch die Software "WinConnect Server" was für dich. Damit kannst du ganz einfach aus einem Client (Win7 / Win 10 etc.) einen Terminalserver / Remotedesktopserver erstellen. Dieses ermöglicht dir dann mehrere Verbindungen zu dieser Maschine.
Habe es selbst bei einem Kunden schon mal im Einsatz gesehen und es funktioniert wirklich zuverlässig.
Habe es selbst bei einem Kunden schon mal im Einsatz gesehen und es funktioniert wirklich zuverlässig.
@emeriks:
Der Faktor "Mensch" ist bei meinem Lösungsvorschlag natürlich die größte Schwäche, stimmt:
Andererseits fragt sich dann, wenn die sich nicht an die Anweisung halten würden, obwohl ihnen das "Wie" und "Warum" erklärt wurde, ob das Menschen mit Verstand oder Blödis sind
Bei meinem vorletzten AG war ein solches Skript im Einsatz, und es hat eigentlich gut funktioniert, war allerdings kein mstsc, deswegen hatten die Anwender keine Alternative. Ich bring' die Befehle und die Befehlssyntax aus der Erinnerung allerdings nicht mehr zusmammen.
Viele Grüße
von
departure69
Der Faktor "Mensch" ist bei meinem Lösungsvorschlag natürlich die größte Schwäche, stimmt:
und den Usern beibringen, daß sie nur noch dieses Skript (bzw. die für alle gleiche Verknüpfung zu dem Skript) zur Verbindung verwenden sollen/müssen/dürfen.
Andererseits fragt sich dann, wenn die sich nicht an die Anweisung halten würden, obwohl ihnen das "Wie" und "Warum" erklärt wurde, ob das Menschen mit Verstand oder Blödis sind
Bei meinem vorletzten AG war ein solches Skript im Einsatz, und es hat eigentlich gut funktioniert, war allerdings kein mstsc, deswegen hatten die Anwender keine Alternative. Ich bring' die Befehle und die Befehlssyntax aus der Erinnerung allerdings nicht mehr zusmammen.
Viele Grüße
von
departure69
