hyper-p
Goto Top

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

Content-Key: 923589524

Url: https://administrator.de/contentid/923589524

Printed on: April 19, 2024 at 10:04 o'clock

Member: emeriks
emeriks Jul 06, 2021 updated at 13:40:06 (UTC)
Goto Top
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.
Member: departure69
departure69 Jul 06, 2021 at 14:40:46 (UTC)
Goto Top
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
Member: Hyper-P
Hyper-P Jul 07, 2021 updated at 05:56:41 (UTC)
Goto Top
@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. face-wink

Viele Grüße
Marius83
Member: emeriks
emeriks Jul 07, 2021 at 06:12:10 (UTC)
Goto Top
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:
Ausführen als SYSTEM:
Member: Hyper-P
Hyper-P Jul 07, 2021 updated at 06:50:31 (UTC)
Goto Top
@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. face-sad
Member: emeriks
emeriks Jul 07, 2021 updated at 06:57:31 (UTC)
Goto Top
Der Wald! Der Wald! Wo sind die Bäume? face-wink

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.
Member: Hyper-P
Hyper-P Jul 07, 2021 updated at 07:24:58 (UTC)
Goto Top
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. face-confused

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"