7
RDP-Verbindung (nicht Host) auf eine einzige Verbindung beschränken
Hallo,
ich betreibe einen älteren Rechner mit Win10 Pro als "Remotedesktop-Server", auf dem zwei ältere Programme installiert sind, welche die Benutzer bei Bedarf nutzen können, in dem sie sich über RDP mit einem bestimmten (Domänen-)Benutzer darauf anmelden. Es gibt nur diesen einen Benutzer, damit nicht für jeden einzelnen Benutzer Profile mit entsprechendem Speicherbedarf erstellt werden.
Nachteil daran ist, dass die Benutzer vorher oder während des Anmeldens nicht sehen, ob schon ein anderer Kollege angemeldet ist. Die Sitzung des einen Kollegen wird abgemeldet, die des anderen Kollegen aufgebaut bzw. übernommen.
Die Verbindungsbeschränkung auf 1 max. gleichzeitige Verbindung über eine GPO auf dem RDP-Host-Server fällt weg, da im Einzelfall an anderer Stelle mehr als eine gleichzeitige Verbindung benötigt wird.
gpedit auf dem betreffenden "Server" und dort die Richtlinie lokal anpassen bewirkt nichts, weil die Einstellung, wie auch in der Beschreibung erwähnt, nur für den "richtigen" RDP-Host vorgesehen ist.
Einen neuen Domänen-Benutzer anlegen, welcher nur für den einzelnen Rechner funktioniert, nutzt ebenfalls nichts, weil damit dasselbe Problem bestehen würde, wie im 2. Absatz beschrieben.
Gibt es sonst irgendeine Möglichkeit dafür zu sorgen, dass es nur einen einzigen Zugang/Benutzer (außer den Admins) für den Rechner gibt, damit nur eine einzige Anmeldung möglich ist und bei einem weiteren Verbindungsversuch durch einen weiteren Kollegen eine Fehlermeldung oder Abfrage erscheint?
Danke & Gruß
Marius83
ich betreibe einen älteren Rechner mit Win10 Pro als "Remotedesktop-Server", auf dem zwei ältere Programme installiert sind, welche die Benutzer bei Bedarf nutzen können, in dem sie sich über RDP mit einem bestimmten (Domänen-)Benutzer darauf anmelden. Es gibt nur diesen einen Benutzer, damit nicht für jeden einzelnen Benutzer Profile mit entsprechendem Speicherbedarf erstellt werden.
Nachteil daran ist, dass die Benutzer vorher oder während des Anmeldens nicht sehen, ob schon ein anderer Kollege angemeldet ist. Die Sitzung des einen Kollegen wird abgemeldet, die des anderen Kollegen aufgebaut bzw. übernommen.
Die Verbindungsbeschränkung auf 1 max. gleichzeitige Verbindung über eine GPO auf dem RDP-Host-Server fällt weg, da im Einzelfall an anderer Stelle mehr als eine gleichzeitige Verbindung benötigt wird.
gpedit auf dem betreffenden "Server" und dort die Richtlinie lokal anpassen bewirkt nichts, weil die Einstellung, wie auch in der Beschreibung erwähnt, nur für den "richtigen" RDP-Host vorgesehen ist.
Einen neuen Domänen-Benutzer anlegen, welcher nur für den einzelnen Rechner funktioniert, nutzt ebenfalls nichts, weil damit dasselbe Problem bestehen würde, wie im 2. Absatz beschrieben.
Gibt es sonst irgendeine Möglichkeit dafür zu sorgen, dass es nur einen einzigen Zugang/Benutzer (außer den Admins) für den Rechner gibt, damit nur eine einzige Anmeldung möglich ist und bei einem weiteren Verbindungsversuch durch einen weiteren Kollegen eine Fehlermeldung oder Abfrage erscheint?
Danke & Gruß
Marius83
Auf Facebook teilen
Auf X (Twitter) teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 923589524
Url: https://administrator.de/forum/rdp-verbindung-nicht-host-auf-eine-einzige-verbindung-beschraenken-923589524.html
Ausgedruckt am: 15.04.2025 um 15:04 Uhr
7 Kommentare
Neuester Kommentar
Hi,
Du könntest es mit Scheduled Task versuchen.
Einen mit
- Trigger "Beim Verbinden mit Benutzersitzung", Bestimmter Benutzer: dieser besagte Benutzer
- Ausführen als SYSTEM: change logon /disable
Und einen mit
- Trigger "Beim Trennen von Benutzersitzung", Bestimmter Benutzer: dieser besagte Benutzer
- Ausführen als SYSTEM: change logon /enable
E.
Du könntest es mit Scheduled Task versuchen.
Einen mit
- Trigger "Beim Verbinden mit Benutzersitzung", Bestimmter Benutzer: dieser besagte Benutzer
- Ausführen als SYSTEM: change logon /disable
Und einen mit
- Trigger "Beim Trennen von Benutzersitzung", Bestimmter Benutzer: dieser besagte Benutzer
- Ausführen als SYSTEM: change logon /enable
E.
Hallo.
Du könntest die RDP-Verbindung über eine Verknüpfung zu einem Batch-Skript starten lassen, in dem der mstsc-befehl enthalten ist, zuerst aber in dem Skript abgeprüft wird, ob an bestimmtem Ort (Pfad) eine Sperrdatei (*.lck) vorhanden ist. Ist eine vorhanden, kriegt der User von dem Skript per echo die Meldung, das schon jemand mit der Verbindung arbeitet und das Skript wird abgebrochen und gelangt somit erst gar nicht zu dem mstsc-Aufruf. Besteht jedoch keine Sperrdatei, dann kann sich der User anmelden und es wird durch seine Anmeldung für den Nächsten User die Sperrdatei geschrieben. Nach der Abmeldung wird die Sperrdatei gelöscht. Alles über ein einziges Skript.
Ich könnte dieses Skript jetzt nicht selber schreiben, hab' sowas aber schon mal gesehen, funktioniert.
Viele Grüße
von
departure69
Du könntest die RDP-Verbindung über eine Verknüpfung zu einem Batch-Skript starten lassen, in dem der mstsc-befehl enthalten ist, zuerst aber in dem Skript abgeprüft wird, ob an bestimmtem Ort (Pfad) eine Sperrdatei (*.lck) vorhanden ist. Ist eine vorhanden, kriegt der User von dem Skript per echo die Meldung, das schon jemand mit der Verbindung arbeitet und das Skript wird abgebrochen und gelangt somit erst gar nicht zu dem mstsc-Aufruf. Besteht jedoch keine Sperrdatei, dann kann sich der User anmelden und es wird durch seine Anmeldung für den Nächsten User die Sperrdatei geschrieben. Nach der Abmeldung wird die Sperrdatei gelöscht. Alles über ein einziges Skript.
Ich könnte dieses Skript jetzt nicht selber schreiben, hab' sowas aber schon mal gesehen, funktioniert.
Viele Grüße
von
departure69
@emeriks:
Die Idee war richtig gut, allerdings funktioniert das leider nicht. Zumindest nicht automatisch, wenn man sich mit dem entsprechenden Benutzer remote am Rechner anmeldet. Starte ich die Tasks jeweils von Hand, funktioniert es, aber irgendwie auch nicht so ganz zuverlässig. Vielleicht hängt das auch irgendwie damit zusammen, dass ich wegen der eingeschränkten Berechtigungen des anzumeldenden Users meinen User als ausführenden User einsetzen musste, was mir eigentlich auch nicht so ganz geheuer ist.
@departure69:
Danke für den Tipp. Von derartigen Scripts habe ich leider nur wenig Ahnung und bin bisher auch nicht mit einer halbwegs fertigen Lösung fündig geworden. Zudem will ich an der grundlegenden Form der Anmeldung für die User möglichst nichts ändern, denn das sorgt meistens eher für Probleme.
Viele Grüße
Marius83
Die Idee war richtig gut, allerdings funktioniert das leider nicht. Zumindest nicht automatisch, wenn man sich mit dem entsprechenden Benutzer remote am Rechner anmeldet. Starte ich die Tasks jeweils von Hand, funktioniert es, aber irgendwie auch nicht so ganz zuverlässig. Vielleicht hängt das auch irgendwie damit zusammen, dass ich wegen der eingeschränkten Berechtigungen des anzumeldenden Users meinen User als ausführenden User einsetzen musste, was mir eigentlich auch nicht so ganz geheuer ist.
@departure69:
Danke für den Tipp. Von derartigen Scripts habe ich leider nur wenig Ahnung und bin bisher auch nicht mit einer halbwegs fertigen Lösung fündig geworden. Zudem will ich an der grundlegenden Form der Anmeldung für die User möglichst nichts ändern, denn das sorgt meistens eher für Probleme.
Viele Grüße
Marius83
Zitat von @marius83:
Vielleicht hängt das auch irgendwie damit zusammen, dass ich wegen der eingeschränkten Berechtigungen des anzumeldenden Users meinen User als ausführenden User einsetzen musste, was mir eigentlich auch nicht so ganz geheuer ist.
Du hast sicherlich überlesen, dass ich schrieb:Vielleicht hängt das auch irgendwie damit zusammen, dass ich wegen der eingeschränkten Berechtigungen des anzumeldenden Users meinen User als ausführenden User einsetzen musste, was mir eigentlich auch nicht so ganz geheuer ist.
Ausführen als SYSTEM:
@emeriks:
Überlesen hatte ich das nicht, aber ich hatte gar keine Möglichkeit, unter dem Benutzer als SYSTEM ausführen zu lassen. Wenn ich die Aufgabenplanung wiederum als Admin ausführe, kann ich den Task als SYSTEM laufen lassen. Nutzt mir jedoch nichts, weil die Tasks bei dem Benutzer, um den es hier geht, nicht gelistet und demnach auch nicht ausgeführt werden.
Überlesen hatte ich das nicht, aber ich hatte gar keine Möglichkeit, unter dem Benutzer als SYSTEM ausführen zu lassen. Wenn ich die Aufgabenplanung wiederum als Admin ausführe, kann ich den Task als SYSTEM laufen lassen. Nutzt mir jedoch nichts, weil die Tasks bei dem Benutzer, um den es hier geht, nicht gelistet und demnach auch nicht ausgeführt werden.
Der Wald! Der Wald! Wo sind die Bäume?
Du erstellt diese Task als ein Administrator.
Unter "Ausführen als" gibst Du "SYSTEM" an.
Im Trigger gibst Du das betreffende Benutzerkonto an.
Der Benutzer muss diesen Task nicht sehen, damit SYSTEM diesen ausführen kann.
Du erstellt diese Task als ein Administrator.
Unter "Ausführen als" gibst Du "SYSTEM" an.
Im Trigger gibst Du das betreffende Benutzerkonto an.
Der Benutzer muss diesen Task nicht sehen, damit SYSTEM diesen ausführen kann.
Genau so bin ich bereits vorgegangen. Da passiert beim fröhlichen An- und Abmelden rein gar nichts. Sprich bei einer 2. Verbindung mit dem gleichen Benutzer wird weiterhin der erste angemeldete Benutzer aus seiner Session rausgeschmissen. 
Edit: Es tut sich schon irgendwas, aber es sperrt die Anmeldung einfach nicht:
"Die Aufgabenplanung hat die Aufgabe "\Verbinden mit der XXXXXXX-Benutzersitzung", Instanz "C:\Windows\System32\change.exe" mit der Prozess-ID 123456 gestartet."
Im Task unter Aktionen habe ich unter "Programm/Skript" C:\Windows\System32\change.exe eingetragen und unter "Argumente" den Rest eingtragen (logon /disable), beim anderen Task entsprechend angepasst.
Wenn ich in der CMD eine Abfrage mache, ist die Anmeldung derzeit auch gesperrt, aber eine 2. Anmeldung ist dennoch weiterhin möglich...
"Sitzungsanmeldungen sind zurzeit DEAKTIVIERT"
Edit: Es tut sich schon irgendwas, aber es sperrt die Anmeldung einfach nicht:
"Die Aufgabenplanung hat die Aufgabe "\Verbinden mit der XXXXXXX-Benutzersitzung", Instanz "C:\Windows\System32\change.exe" mit der Prozess-ID 123456 gestartet."
Im Task unter Aktionen habe ich unter "Programm/Skript" C:\Windows\System32\change.exe eingetragen und unter "Argumente" den Rest eingtragen (logon /disable), beim anderen Task entsprechend angepasst.
Wenn ich in der CMD eine Abfrage mache, ist die Anmeldung derzeit auch gesperrt, aber eine 2. Anmeldung ist dennoch weiterhin möglich...
"Sitzungsanmeldungen sind zurzeit DEAKTIVIERT"
