11
Nativen Windows 10 als RDP-Client nutzen und absichern via GPO
Hallo zusammen,
vor einiger Zeit stand ich vor der Aufgabe, dass wir native Windows 10 Rechner so begrenzen, dass dieser für den User lediglich RDP zulässt. Dafür hatte ich damals unter anderem folgende beide Themen eröffnet, die bis heute noch offen sind.
Eine Lösung habe ich für die beiden dort beschriebene Probleme nicht gefunden, aber eine Alternative. Vielleicht hilft dem einen oder anderem ja weiter, wenn er eine ähnliche Anforderung hat. Ein Windows 10 ioT mit Festplatten-Schreibschutz hat unser Virenscanner einen Strich durch die Rechnung gemacht. Daher jetzt mit einem nativen Windows 10 Pro.
Wir haben einen Besprechungsraum mit einem PC. Von diesem PC soll sich der Anwender auf seinen Arbeitsplatz aufschalten können und sein Arbeitsplatz-Bildschirm im Besprechungsraum darstellen. Auf dem PC soll nichts weiter gemacht werden können, da der PC theoretisch unbeaufsichtigt von Gästen genutzt werden könnte.
Windows 10 PC installieren und in die Domäne heben (heißt hier Besprechung)
Besprechungsraum-Benutzer anlegen (heißt hier Meeting)
Eigene OU im AD für die Besprechungsräume anlegen (bei uns unter der regulären OU für Client-PCs)
Anmerkung: Ich gehe nur auf die Sonderrechte ein, die wir für den Benutzer und/oder den PC vergeben haben. Wenn hier also wichtige Einstellungen fehlen , dann liegt dies darin begründet, dass andere GPOs bereits diese Einstellungen bei uns kontrollieren. Bei uns ist es ein mehr oder weniger frei Zugänglicher PC. Die Anleitung kann aber auch für jeden anderen PC genutzt werden, der nur als Terminalclient genutzt werden soll.
Das Vorgehen ist recht simpel, da beinahe alles via GPO geregelt wird. Für den Besprechungsraum wurden folgenden GPOs wie nun folgt konfiguriert:
Computerkonfiguration -> Administrative Vorlagen -> System -> Wechselmedien:
Das war es für den PC. Der Rest erfolgt am Benutzer und wird deutlich länger und mehr. Deswegen gibt es da jetzt Bilder
JA, die drei Bilder sind alle nur im Startmenü. Der Rest wird weniger
Zum Schluss folgen noch 2 Registry-Keys die verteilt werden.
Software\Microsoft\Windows\CurrentVersion\Policies\NonEnum sorgt dafür, dass auf das Netzwerk aus dem Explorer nicht zugegriffen werden kann. Das dient als doppelter Boden, denn der Zugriff auf den Explorer ist wie oben gezeigt bereits eigentlich deaktiviert.
Software\Microsoft\Windows\CurrentVersion\Policies\Explorer\NoChangeStartMenu sorgt dafür, dass nichts am Startmenü angeheftet werden kann.
Das war es im Prinzip auch schon. Der User kann jetzt fast gar nichts mehr machen. Einige Dinge (wie lesend noch die Computerhardware zu öffnen) sind zwar noch möglich, aber damit kann derjenige keinen Schaden anrichten.
Damit es für jeden User immer gleich aussieht, haben wir noch ein PowerShell Skript erstellt, welches eine MSTSC.EXE öffnet. Sollte keine MSTSC.EXE mehr offen sein, so startet der PC neu. Dadurch bedingt ist der Rechner theoretisch via PS angreifbar. Wer seinen Anwendern diesen Luxus nicht gönnt, der muss einfach powersehll.exe in Bild 4 zusätzlich zum explorer.exe hinzugefügt werden. Das ganze wird per Aufgabenplanung bei der Anmeldung eines Benutzers ausgeführt und sieht bei uns so aus:
Das Skript und die Aufgabe wird ebenfalls via GPO verteilt. Aus Pfadgründen hier jedoch nicht angegeben. Aber das kriegt ihr schon selbst hin, wenn ihr an dieser Stelle angekommen seid.
Die hier beschriebene Lösung hat folgenden Vorteil:
Nachteil:
Der Rechner ist theoretisch durch PS angreifbar, da ich Code in PS eingeben kann. Ja ich kann PS öffnen, aber wenn neben der aus der Aufgabenplanung gestarteten Shell eine weitere geöffnet ist, wird der Computer innerhalb einer Sekunde neu gestartet. Da ich keinerlei Möglichkeit habe, ein vorgefertigtes Skript zu kopieren oder per Doppelklick auszuführen, ist dies nur theoretisch möglich.
So. Das wars mit meiner ersten Anleitung. Wer Fragen oder Anmerkungen konstruktiver Art hat, kann diese hier gerne posten.
Gruß
Doskias
vor einiger Zeit stand ich vor der Aufgabe, dass wir native Windows 10 Rechner so begrenzen, dass dieser für den User lediglich RDP zulässt. Dafür hatte ich damals unter anderem folgende beide Themen eröffnet, die bis heute noch offen sind.
- Welche App für RDP im Kiosk-Modus
- Kiosk-Mode bei Windows 10 und der AssignedAcess-Konfigurationsdienstanbieter
Eine Lösung habe ich für die beiden dort beschriebene Probleme nicht gefunden, aber eine Alternative. Vielleicht hilft dem einen oder anderem ja weiter, wenn er eine ähnliche Anforderung hat. Ein Windows 10 ioT mit Festplatten-Schreibschutz hat unser Virenscanner einen Strich durch die Rechnung gemacht. Daher jetzt mit einem nativen Windows 10 Pro.
Inhaltsverzeichnis
Unsere Situation
Wir haben einen Besprechungsraum mit einem PC. Von diesem PC soll sich der Anwender auf seinen Arbeitsplatz aufschalten können und sein Arbeitsplatz-Bildschirm im Besprechungsraum darstellen. Auf dem PC soll nichts weiter gemacht werden können, da der PC theoretisch unbeaufsichtigt von Gästen genutzt werden könnte.
Vorbereitung
Windows 10 PC installieren und in die Domäne heben (heißt hier Besprechung)
Besprechungsraum-Benutzer anlegen (heißt hier Meeting)
Eigene OU im AD für die Besprechungsräume anlegen (bei uns unter der regulären OU für Client-PCs)
Anmerkung: Ich gehe nur auf die Sonderrechte ein, die wir für den Benutzer und/oder den PC vergeben haben. Wenn hier also wichtige Einstellungen fehlen , dann liegt dies darin begründet, dass andere GPOs bereits diese Einstellungen bei uns kontrollieren. Bei uns ist es ein mehr oder weniger frei Zugänglicher PC. Die Anleitung kann aber auch für jeden anderen PC genutzt werden, der nur als Terminalclient genutzt werden soll.
Vorgehen
Das Vorgehen ist recht simpel, da beinahe alles via GPO geregelt wird. Für den Besprechungsraum wurden folgenden GPOs wie nun folgt konfiguriert:
Computerkonfiguration -> Administrative Vorlagen -> System -> Wechselmedien:
- Alle Wechselmedien: Jeglichen Zugriff in Remotesitzungen verweigern: aktiviert
- Alle Wechselmedienklassen: jeglichen Zugriff Verweigern: aktiviert
Das war es für den PC. Der Rest erfolgt am Benutzer und wird deutlich länger und mehr. Deswegen gibt es da jetzt Bilder
JA, die drei Bilder sind alle nur im Startmenü. Der Rest wird weniger
Zum Schluss folgen noch 2 Registry-Keys die verteilt werden.
Was machen die beiden Registry Keys
Software\Microsoft\Windows\CurrentVersion\Policies\NonEnum sorgt dafür, dass auf das Netzwerk aus dem Explorer nicht zugegriffen werden kann. Das dient als doppelter Boden, denn der Zugriff auf den Explorer ist wie oben gezeigt bereits eigentlich deaktiviert.
Software\Microsoft\Windows\CurrentVersion\Policies\Explorer\NoChangeStartMenu sorgt dafür, dass nichts am Startmenü angeheftet werden kann.
Das war es im Prinzip auch schon. Der User kann jetzt fast gar nichts mehr machen. Einige Dinge (wie lesend noch die Computerhardware zu öffnen) sind zwar noch möglich, aber damit kann derjenige keinen Schaden anrichten.
Damit es für jeden User immer gleich aussieht, haben wir noch ein PowerShell Skript erstellt, welches eine MSTSC.EXE öffnet. Sollte keine MSTSC.EXE mehr offen sein, so startet der PC neu. Dadurch bedingt ist der Rechner theoretisch via PS angreifbar. Wer seinen Anwendern diesen Luxus nicht gönnt, der muss einfach powersehll.exe in Bild 4 zusätzlich zum explorer.exe hinzugefügt werden. Das ganze wird per Aufgabenplanung bei der Anmeldung eines Benutzers ausgeführt und sieht bei uns so aus:
if($env:USERNAME -notlike "*administrator*")
{
mstsc.exe
sleep 2
$RDP=get-process | select-object ProcessName, MainWindowTitle |where {$_.processname -like "mstsc"}
while ($RDP.processname -like "*mstsc*")
{
sleep 1
$RDP=get-process | select-object ProcessName, MainWindowTitle |where {$_.processname -like "mstsc"}
get-process | select-object ProcessName, MainWindowTitle |where {$_.processname -like "mstsc"}
$PS_Check=Get-Process |? processname -like *powershell*
if ($PS_Check.count -ne 1) {restart-Computer -force}
}
restart-Computer -force
}Das Skript und die Aufgabe wird ebenfalls via GPO verteilt. Aus Pfadgründen hier jedoch nicht angegeben. Aber das kriegt ihr schon selbst hin, wenn ihr an dieser Stelle angekommen seid.
Warum habe ich das alles so gemacht wie es ist?
Die hier beschriebene Lösung hat folgenden Vorteil:
- Es kann ein vollwertiger Rechner genutzt werden mit dem vollen Softwarepaket. Die Vorbereitung einen Rechner in diesen Zustand zu versetzen ist nahezu gleich Null. Es müssen nur Mitarbeiter und Rechner in die Entsprechende OU bzw. Gruppe verschoben werden.
- Über die erste Skript-Zeile kann ich steuern wer den Rechner als RDP-Client verwenden muss und wer ihn regulär verwenden kann. Ich kann somit an Arbeitsplätzen definieren, dass der Admin und bestimmte Anwender den Rechner als regulären Arbeitsplatz nutzen können, während der Praktikant auf die RDP-Verbindung gezwungen wird und sich am Terminalserver anmelden muss. Das ganze gesteuert über die AD-Gruppe und das Skript.
Nachteil:
Der Rechner ist theoretisch durch PS angreifbar, da ich Code in PS eingeben kann. Ja ich kann PS öffnen, aber wenn neben der aus der Aufgabenplanung gestarteten Shell eine weitere geöffnet ist, wird der Computer innerhalb einer Sekunde neu gestartet. Da ich keinerlei Möglichkeit habe, ein vorgefertigtes Skript zu kopieren oder per Doppelklick auszuführen, ist dies nur theoretisch möglich.
So. Das wars mit meiner ersten Anleitung. Wer Fragen oder Anmerkungen konstruktiver Art hat, kann diese hier gerne posten.
Gruß
Doskias
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: 1695741315
Url: https://administrator.de/contentid/1695741315
Ausgedruckt am: 21.11.2024 um 14:11 Uhr
11 Kommentare
Neuester Kommentar
Mahlzeit Kollege!
Anleitungen find ich immer cool, wenn die einen Faden haben, dem man folgen kann.
Schau Dir mal aus Spass das hier an: https://www.wioski.com/
So mache ich das mit Clients, die sich nicht ändern sollen.
Zwangsreboot rein und hast die Möhre immer in Ausgangsstellung.
Unsere Konferenzraum-PCs habe ich so gebaut.
Ich war es leid, ständig Teams, Webex und wie sie alle heißen immer runterzuschmeißen.
Gruß
bdmvg
Anleitungen find ich immer cool, wenn die einen Faden haben, dem man folgen kann.
Schau Dir mal aus Spass das hier an: https://www.wioski.com/
So mache ich das mit Clients, die sich nicht ändern sollen.
Zwangsreboot rein und hast die Möhre immer in Ausgangsstellung.
Unsere Konferenzraum-PCs habe ich so gebaut.
Ich war es leid, ständig Teams, Webex und wie sie alle heißen immer runterzuschmeißen.
Gruß
bdmvg
1
Zitat von @beidermachtvongreyscull:
So mache ich das mit Clients, die sich nicht ändern sollen.
Zwangsreboot rein und hast die Möhre immer in Ausgangsstellung.
So mache ich das mit Clients, die sich nicht ändern sollen.
Zwangsreboot rein und hast die Möhre immer in Ausgangsstellung.
Japp. Wobei ich sagen muss: grade die Option, dass ich Anhand des Benutzers entscheide ob der Rechner nu ein TS-Client ist oder ein vollwertiger Rechner, sich in den letzten Wochen doch als sehr nützlich heraus gestellt hat. So kann sich der Praktikant bei der Lagerinventur an jedem Rechner anmelden der grade frei ist und sich per RDP auf den Server schalten ohne die Umgebung des Lagermitarbeiters zu gefährden.
Ich persönlich bin von "Zwangsreboot in Ausgangsstellung" mittlerweile abgerückt. Wenn der User nichts umstellen kann, brauch ich keine Ausgangsstellung und wenn was kaputt ist, dann wird einfach das reguläre Image drüber gebügelt und durch die GPOs ist der Rechner dann auch schnell wieder einsatzbereit. Außerdem kann ich wirklich jeden Rechner den wir im Einsatz haben als Ersatz nehmen und muss nur eine GPOs (obige Computerverwaltung geht derzeit noch auf Rechnernamen) dafür anpassen.
Wenn ich erreichen wollte, dass an einem bestimmten PC nur ein bestimmter Nutzerkreis gezwungen wird, nichts außer rdp machen zu dürfen, nehme ich assigned access und die MS store app für remote Desktop und muss nichts weiter tun.
Der Nutzerkreis bekommt den Namen und das Kennwort des assigned access Nutzers und fertig.
Der Nutzerkreis bekommt den Namen und das Kennwort des assigned access Nutzers und fertig.
Zitat von @DerWoWusste:
Wenn ich erreichen wollte, dass an einem bestimmten PC nur ein bestimmter Nutzerkreis gezwungen wird, nichts außer rdp machen zu dürfen, nehme ich assigned access und die MS store app für remote Desktop und muss nichts weiter tun.
Der Nutzerkreis bekommt den Namen und das Kennwort des assigned access Nutzers und fertig.
Wenn ich erreichen wollte, dass an einem bestimmten PC nur ein bestimmter Nutzerkreis gezwungen wird, nichts außer rdp machen zu dürfen, nehme ich assigned access und die MS store app für remote Desktop und muss nichts weiter tun.
Der Nutzerkreis bekommt den Namen und das Kennwort des assigned access Nutzers und fertig.
Guter Punkt. Das habe ich ursprünglich auch versucht, aber es hat nicht funktioniert. Es hat auch nicht an mir gelegen, wie in meinem damaligen Posting (hier der entsprechende Kommentar andere User bestätigt haben. Zugegeben, es ist seitdem etwas Zeit vergangen und ich habe es mit der MS Store App nicht erneut versucht, aber dafür gibt es auch Gründe. Einer der Gründe ist zum Beispiel, dass unser Firewall die MS-Store-App blockt, weil die Firewall den ganzen MS-Store blockt. Die Lösung kann also auch helfen, wenn ich keinen Zugriff auf die MS-Store-App habe, wie es bei uns der Fall ist
Ich teste das mal und dann seh ich mir auch deine Alternative an.
Hab mir assignedaccess auf Win11 in Verbindung mit der RemotedesktopApp aus dem Store angesehen.
In der Tat startet die App, lässt aber keine Verbindungen zu, was nach Bug aussieht (solche kenne ich schon von assignedaccess).
Deine Methode werde ich mir auch noch ansehen.
In der Tat startet die App, lässt aber keine Verbindungen zu, was nach Bug aussieht (solche kenne ich schon von assignedaccess).
Deine Methode werde ich mir auch noch ansehen.
Wenn der Rechner ohnehin nichts anderes tut, warum dann Windows 10? Es gibt Linux-Distributionen, die genau auf diesen Zweck ("baue mit FAT-Client-Hardware einen Thin-Client") abgestimmt sind oder sich einfach darauf reduzieren lassen. Als mstsc.exe-Ersatz nutzen die oftmals den RDesktop. Oder eben andere RDP-Clients für Linux.
Ansonsten klasse Anleitung, da hast Du Dir sehr viel Arbeit gemacht.
Viele Grüße
Ansonsten klasse Anleitung, da hast Du Dir sehr viel Arbeit gemacht.
Viele Grüße
1
Tolle Anleitung, einzig der Registry Key
Software\Microsoft\Windows\CurrentVersion\Policies\Explorer\NoChangeStartMenu
wäre ganz nett gewesen, wenn das durch die passende GPO "Prevent users from customizing their Start Screen" ersetzt worden wäre ;)
Software\Microsoft\Windows\CurrentVersion\Policies\Explorer\NoChangeStartMenu
wäre ganz nett gewesen, wenn das durch die passende GPO "Prevent users from customizing their Start Screen" ersetzt worden wäre ;)
Zitat von @departure69:
Wenn der Rechner ohnehin nichts anderes tut, warum dann Windows 10? Es gibt Linux-Distributionen, die genau auf diesen Zweck ("baue mit FAT-Client-Hardware einen Thin-Client") abgestimmt sind oder sich einfach darauf reduzieren lassen. Als mstsc.exe-Ersatz nutzen die oftmals den RDesktop. Oder eben andere RDP-Clients für Linux.
Weil der Rechner eben doch was anderes tun kann. Wenn der Rechner ohnehin nichts anderes tut, warum dann Windows 10? Es gibt Linux-Distributionen, die genau auf diesen Zweck ("baue mit FAT-Client-Hardware einen Thin-Client") abgestimmt sind oder sich einfach darauf reduzieren lassen. Als mstsc.exe-Ersatz nutzen die oftmals den RDesktop. Oder eben andere RDP-Clients für Linux.
Mit der gezeigten Lösung kann ich jederzeit jeden Rechner in die entsprechende Position bringen. Ich brauche nur die OU entsprehend anzupassen. Ich kann jeden Client-PC als Ersatz nutzen ohne viel umstellen zu müssen oder auch den RDP-Client-PC im Notfall als vollwertigen Rechner nutzen, indem ich ein zwei Änderungen im AD vornehme.Ein weiterer Vorteil ist,d ass du bei Windows 10 auch die Updates zentral steuern kannst und nicht zwischen Windows und/oder Linux herumwechseln musst. Das Hauptargument ist aber, dass wir (andere vielleicht nicht), aus kompatibilitätsgründen auf eine Handvoll von Systemen beschränkt sind und bei deren Kauf ohnehin immer eine Windows 10 Lizenz on Bord (bald Windows 11) dabei ist.
Ansonsten klasse Anleitung, da hast Du Dir sehr viel Arbeit gemacht.
Danke. Die Problematik hat mir auch sehr viel Arbeit gemacht um es zu lösen.Zitat von @H3GE3406:
Tolle Anleitung, einzig der Registry Key
Software\Microsoft\Windows\CurrentVersion\Policies\Explorer\NoChangeStartMenu
wäre ganz nett gewesen, wenn das durch die passende GPO "Prevent users from customizing their Start Screen" ersetzt worden wäre ;)
Ja, kann man machen. Dann muss ich die Anwender, die sich auf dem Client anmelden allerdings explizit in Gruppen packen, bzw. mit WMI-Filter arbeiten. Dadurch, dass ich den Registry-Key per GPO verteile, wird der Key nur auf dem Rechner gesetzt. Daraus resultiert, dass die entsprechende Option im RDP-Client-Rechner nicht zur Verfügung steht, auf den regulärem Rechner allerdings schon, wenn ich mich mit dem gleichen Benutzer anmelde. Wenn ich es per GPO als Benutzerkonfiguration verteile, muss ich ja wieder einen WMI Filter nur für die RDP-Clients erstellen. Wenn ich aber die User sich ausschließlich am RDP-Client anmelden lasse und nicht noch parallel an "normalen" Workstations, dann hast du recht, dann kann ich es auch per GPO verteilen.Tolle Anleitung, einzig der Registry Key
Software\Microsoft\Windows\CurrentVersion\Policies\Explorer\NoChangeStartMenu
wäre ganz nett gewesen, wenn das durch die passende GPO "Prevent users from customizing their Start Screen" ersetzt worden wäre ;)
Gruß
Doskias
2
In der Enterprise Variante gibt es bei Microsoft einen eingebauten Schreibfilter namens UWF.
Interessant, wenn man keine Drittanbieter Tools nutzen möchte und eine Lizenz für Enterprise hat.
Interessant, wenn man keine Drittanbieter Tools nutzen möchte und eine Lizenz für Enterprise hat.
Zitat von @beidermachtvongreyscull:
Mahlzeit Kollege!
Anleitungen find ich immer cool, wenn die einen Faden haben, dem man folgen kann.
Schau Dir mal aus Spass das hier an: https://www.wioski.com/
So mache ich das mit Clients, die sich nicht ändern sollen.
Zwangsreboot rein und hast die Möhre immer in Ausgangsstellung.
Unsere Konferenzraum-PCs habe ich so gebaut.
Ich war es leid, ständig Teams, Webex und wie sie alle heißen immer runterzuschmeißen.
Gruß
bdmvg
Mahlzeit Kollege!
Anleitungen find ich immer cool, wenn die einen Faden haben, dem man folgen kann.
Schau Dir mal aus Spass das hier an: https://www.wioski.com/
So mache ich das mit Clients, die sich nicht ändern sollen.
Zwangsreboot rein und hast die Möhre immer in Ausgangsstellung.
Unsere Konferenzraum-PCs habe ich so gebaut.
Ich war es leid, ständig Teams, Webex und wie sie alle heißen immer runterzuschmeißen.
Gruß
bdmvg
Cooles Ding!
Gruß Globe!
1
