RDP für Administratoren verweigern
Hallo,
Hat jemand ne Idee wie ich für alle Administratoren Remotedesktop verbieten kann.
Wie haben es früher via Batch und WMIC gemacht. Da aber WMIC nun in Windows 11 nicht mehr funktioniert, gibt es die Möglichkeit das ganze auch via Powershell zu machen?
Per Gruppenrichtlinien ist das auch zu machen aber da es keine Domäne gibt ist das nicht so einfach.
Ich nehm alles was geht via CMD / Powershell oder Registry.
Grüße
TicTuc
Hat jemand ne Idee wie ich für alle Administratoren Remotedesktop verbieten kann.
Wie haben es früher via Batch und WMIC gemacht. Da aber WMIC nun in Windows 11 nicht mehr funktioniert, gibt es die Möglichkeit das ganze auch via Powershell zu machen?
Per Gruppenrichtlinien ist das auch zu machen aber da es keine Domäne gibt ist das nicht so einfach.
Ich nehm alles was geht via CMD / Powershell oder Registry.
Grüße
TicTuc
Please also mark the comments that contributed to the solution of the article
Content-ID: 670876
Url: https://administrator.de/forum/rdp-fuer-administratoren-verweigern-670876.html
Printed on: February 11, 2025 at 08:02 o'clock
37 Comments
Latest comment
Schau mal hier:
https://www.anyviewer.com/how-to/disable-remote-desktop-0007.html
Ich sehe den Sinn dahinter aber nicht. So ein Admin umgeht das ja ratzfatz.
https://www.anyviewer.com/how-to/disable-remote-desktop-0007.html
Ich sehe den Sinn dahinter aber nicht. So ein Admin umgeht das ja ratzfatz.
Moin
lgpo.exe ist Dein Freund: https://www.windowspro.de/tool/lgpoexe-lokale-gruppenrichtlinien-importi ...
Gruß
lgpo.exe ist Dein Freund: https://www.windowspro.de/tool/lgpoexe-lokale-gruppenrichtlinien-importi ...
Gruß
Du bekommst sicherlich die besten Antworten, wenn Du sagst, wozu das Ganze.
Willst Du einem Admin lokal etwas verbieten, so kann er das immer umgehen. Du wirst also auf dem RDP-Ziel verbieten müssen, dass er dort raufkommt. Und hier kann keine Unterscheidung gemacht werden zwischen Nutzern, die auf dem Quellrechner lokale Admins sind und solchen, die es nicht sind, sondern man müsste andere Wege gehen.
Beschreibe doch bitte, warum du das vorhast.
Willst Du einem Admin lokal etwas verbieten, so kann er das immer umgehen. Du wirst also auf dem RDP-Ziel verbieten müssen, dass er dort raufkommt. Und hier kann keine Unterscheidung gemacht werden zwischen Nutzern, die auf dem Quellrechner lokale Admins sind und solchen, die es nicht sind, sondern man müsste andere Wege gehen.
Beschreibe doch bitte, warum du das vorhast.
Sag mal, wenn Du liest, dass es umgangen werden kann, ist das nicht genug? Es wird nicht wirklich sicher.
Nachdem Du schreibst
Geht es darum? Dann wären andere Maßnahmen besser.
Nachdem Du schreibst
Attacken die diese Schnittstelle genutzt haben und mit dem block für admins war es save. War eine Empfehlung des BSi damals.
sollte man meinen, es ginge dir um das Abgreifen (auf dem Remoterechner) von Anmeldeinformationen von Admins.Geht es darum? Dann wären andere Maßnahmen besser.
Moin @TicTuc666,
sorry, wenn ein Admin wirklich ein Admin ist, dann kanst du ihn mit solchen Tricks nicht wirklich aussperren sondern eher nur kurzzeitig belustigen.
Daher sollte man priviligierte Accounts, in erster Linie auch so gut es geht schützen!
Gruss Alex
da geht es auch um den Sicherheitsaspekt. es gab mal ne welle von Attacken die diese Schnittstelle genutzt haben und mit dem block für admins war es save. War eine Empfehlung des BSi damals.
sorry, wenn ein Admin wirklich ein Admin ist, dann kanst du ihn mit solchen Tricks nicht wirklich aussperren sondern eher nur kurzzeitig belustigen.
Daher sollte man priviligierte Accounts, in erster Linie auch so gut es geht schützen!
Gruss Alex
Zitat von @TicTuc666:
da geht es auch um den Sicherheitsaspekt. es gab mal ne welle von Attacken die diese Schnittstelle genutzt haben und mit dem block für admins war es save. War eine Empfehlung des BSi damals.
da geht es auch um den Sicherheitsaspekt. es gab mal ne welle von Attacken die diese Schnittstelle genutzt haben und mit dem block für admins war es save. War eine Empfehlung des BSi damals.
sicherheitstechnisch kann das aber kein argument sein wenn man statdessen anydesk oder teamviewer einsetzt...
da machst du eine nadelspitze zu um ein garagentor offen zu halten....
Also RDP lokal ist hundert mal sicherer als wenn du über die Teamviewer oder AnyDesk Server gehst.
Einfach die Tatsache das sich jemand via Teamviewer oder Anydesk auf meine Server verbinden kann, würde mich sehr beunruhigen, statt das lokale RDP Protokol.
Ich mein zum genauen Support Szenario fehlt ja viele Infos, aber klingt so als wolltet ihr lokale Server administrieren und nur weil es einmal einen Vorfall gegeben hat, wollt ihr statt RDP nun Teamviewer oder AnyDesk nehmen.
Sollte das der Fall sein, aua.
So entstehen dann übrigens die richtigen Fails, man irgendwelche Bastellösungen hinbiegt:
https://www.golem.de/news/windows-7-und-teamviewer-wasserwerk-wohl-ueber ...
Einfach die Tatsache das sich jemand via Teamviewer oder Anydesk auf meine Server verbinden kann, würde mich sehr beunruhigen, statt das lokale RDP Protokol.
Ich mein zum genauen Support Szenario fehlt ja viele Infos, aber klingt so als wolltet ihr lokale Server administrieren und nur weil es einmal einen Vorfall gegeben hat, wollt ihr statt RDP nun Teamviewer oder AnyDesk nehmen.
Sollte das der Fall sein, aua.
So entstehen dann übrigens die richtigen Fails, man irgendwelche Bastellösungen hinbiegt:
https://www.golem.de/news/windows-7-und-teamviewer-wasserwerk-wohl-ueber ...
... war auch eher der Gedanke, wie man ggf. loakle GPOs auf Rechner im Netz verteilt bekommt. Dass es schwierig bis unmöglich ist, Administratoren wirklich auszusperren, ist schon klar 
Moin @miscmike,
und was bitte sollte einen Admin daran hindern, den Dienst wieder zu aktivieren und die Firewall Regeln wieder umzukonfigurieren?
Gruss Alex
Und wenn Du den RDP Dienst auf "deaktiviert" stellst und zusätzlich in der Firewall den Port 3389 (oder den, der für RDP evtl. vorgesehen ist) schließt ?
und was bitte sollte einen Admin daran hindern, den Dienst wieder zu aktivieren und die Firewall Regeln wieder umzukonfigurieren?
Gruss Alex
Zitat von @NordicMike:
Administratoren haben doch automatisch immer Zugriff und sind unter
gar nicht gelistet. Funktioniert das trotzdem mit
?
Administratoren haben doch automatisch immer Zugriff und sind unter
net localgroup “remotedesktopbenutzer”
net localgroup “remotedesktopbenutzer” “administrator” /delete
ja.. hast ja Recht
Moin @kpunkt,
und woher sollte der fremde Admin die Zugangsdaten der lokalen Administratoren kennen? ๐ค
Gruss Alex
Ich denke, es wird befürchtet, dass ein "fremder" Admin über RDP kommt und sich dann mit Admin-Rechten am TS einloggt.
und woher sollte der fremde Admin die Zugangsdaten der lokalen Administratoren kennen? ๐ค
Gruss Alex
Moin @Hubert.N,
das wird auch mit GPO's nichts, denn die kann ein Admin jederzeit auch wieder umschreiben. ๐
Gruss Alex
ja.. hast ja Recht
Ohne GPO wird das nichts...
das wird auch mit GPO's nichts, denn die kann ein Admin jederzeit auch wieder umschreiben. ๐
Gruss Alex
Zitat von @MysticFoxDE:
das wird auch mit GPO's nichts, denn die kann ein Admin jederzeit auch wieder umschreiben. ๐
das wird auch mit GPO's nichts, denn die kann ein Admin jederzeit auch wieder umschreiben. ๐
Zitat von @TicTuc666:
Wir möchten den Administratorzugang via Remotedesktop einfach deaktivieren und nur im Notfall erlauben.
Hier geht es nicht darum den Admins den Zugang zu verwehren. Er soll aus Sicherheitsgründen einfach nur deaktiviert sein.
Die Frage stellt sich nicht, das es leicht umgangen werden kann.
Wir möchten den Administratorzugang via Remotedesktop einfach deaktivieren und nur im Notfall erlauben.
Hier geht es nicht darum den Admins den Zugang zu verwehren. Er soll aus Sicherheitsgründen einfach nur deaktiviert sein.
Die Frage stellt sich nicht, das es leicht umgangen werden kann.
Ich dachte, über den Punkt wäre die Diskussion längst hinaus gekommen
Gruß
Moin @Hubert.N,
Ich dachte, über den Punkt wäre die Diskussion längst hinaus gekommen
ne, mein Logik-Ich macht da immer noch nicht wirklich mit und das Admin-Ich lacht sich die ganze Zeit nur den Ast ab, weil es alles bisher genannte, in 0, nichts wieder umbiegen kann. ๐
Gruss Alex
Die Frage stellt sich nicht, das es leicht umgangen werden kann.
Ich dachte, über den Punkt wäre die Diskussion längst hinaus gekommen
ne, mein Logik-Ich macht da immer noch nicht wirklich mit und das Admin-Ich lacht sich die ganze Zeit nur den Ast ab, weil es alles bisher genannte, in 0, nichts wieder umbiegen kann. ๐
Gruss Alex
Zitat von @MysticFoxDE:
Moin @Hubert.N,
Ich dachte, über den Punkt wäre die Diskussion längst hinaus gekommen
ne, mein Logik-Ich macht da immer noch nicht wirklich mit und das Admin-Ich lacht sich die ganze Zeit nur den Ast ab, weil es alles bisher genannte, in 0, nichts wieder umbiegen kann. ๐
Gruss Alex
Moin @Hubert.N,
Die Frage stellt sich nicht, das es leicht umgangen werden kann.
Ich dachte, über den Punkt wäre die Diskussion längst hinaus gekommen
ne, mein Logik-Ich macht da immer noch nicht wirklich mit und das Admin-Ich lacht sich die ganze Zeit nur den Ast ab, weil es alles bisher genannte, in 0, nichts wieder umbiegen kann. ๐
Gruss Alex
Moin Alex
ich glaub das hier, ist eigentlich viel schlimmer, hier wird aufgrund von Unwissenheit und blindem Aktionismus einfach RDP versucht zu deaktivieren. Man hat jetzt eine News gelesen und meint man würde mega das Security+ damit erhalten, aber eigentlich bringt es gar nichts.
Den jeder erfahrene Administrator weiß wann RDP ein Sicherheitsproblem hat, nämlich wenn ein Angreifer im lokalen Netz ist. Und dann ist RDP nicht das Sicherheitsproblem, sondern das ein möglicher Angreifer im lokalen Netz ist.
Und dann ist RDP nicht das Sicherheitsproblem, sondern das ein möglicher Angreifer im lokalen Netz ist.
Seine Intention war vermutlich: Wenn ein täglich arbeitender Admin infiziert wurde, soll er den RDP Server nicht gleich mit infizieren.Zu Zeiten von RDP Managern mit eigener Passwortdatenbank und getrenten Konten zur Arbeit und Administration sollte das jedoch kein Sicherheitsrisiko mehr sein. Der Admin arbeitet mit einem normalen Usernamen an seiner täglichen Arbeit z.B. mit dem Konto smueller, und wenn er auf den RDP Server muss, loggt er sich mit dem Konto smueller-admin ein. Und noch weiter gestrickt, das 3-Tier Modell. Dann gibt es einen smueller-domainadmin, smueller-serveradmin und smueller-clientadmin, bei dem der domainadmin keinen Zugriff auf die Clients oder Server hat. Dann sollten solche Sicherheitsbedenken gelöst sein. Der lokale Administrator vom RDP Session Host kann dann einfach deaktiviert werden.
Zitat von @MysticFoxDE:
Moin @miscmike,
und was bitte sollte einen Admin daran hindern, den Dienst wieder zu aktivieren und die Firewall Regeln wieder umzukonfigurieren?
Gruss Alex
Moin @miscmike,
Und wenn Du den RDP Dienst auf "deaktiviert" stellst und zusätzlich in der Firewall den Port 3389 (oder den, der für RDP evtl. vorgesehen ist) schließt ?
und was bitte sollte einen Admin daran hindern, den Dienst wieder zu aktivieren und die Firewall Regeln wieder umzukonfigurieren?
Gruss Alex
Hi Alex,
..der lokale Zugriff auf den betreffenden Rechner (incl. lokalem Admin) kann ja zugesperrt werden.
Dann kommt auch ein Admin nur mit Aufwand ran.
Ob das allerdings rechtens ist, steht auf einem ganz anderen Blatt.
Moin @miscmike,
wenn man für einen Domain-Admin nur den RDP Zugang zu einem bestimmten Domain-Member sperrt, dann ist es für einen erfahrenen Admin oder für einen erfahrenen Hacker der einen Admin-Account gekapert hat, eben überhaupt kein Problem auf den entsprechenden Server drauf zu kommen, wenn duzende weiterer Massnahmen nicht auch noch zusätzlich umgesetzt wurden. ๐
Danach kann man einen entsprechend kastrierten Admin, zum Administrieren jedoch meist knicken. ๐
Gruss Alex
Dann kommt auch ein Admin nur mit Aufwand ran.
wenn man für einen Domain-Admin nur den RDP Zugang zu einem bestimmten Domain-Member sperrt, dann ist es für einen erfahrenen Admin oder für einen erfahrenen Hacker der einen Admin-Account gekapert hat, eben überhaupt kein Problem auf den entsprechenden Server drauf zu kommen, wenn duzende weiterer Massnahmen nicht auch noch zusätzlich umgesetzt wurden. ๐
Danach kann man einen entsprechend kastrierten Admin, zum Administrieren jedoch meist knicken. ๐
Gruss Alex
Moin @TicTuc666,
na ja, du wurdes ja schon mehrfach gefragt, was der Sinn dieser Aktion ist und bisher hast du dazu noch keine Antwort geliefert, ausser, dass du das eben so machen möchtest.
Der eine oder andere von uns, möchte jedoch auch wissen warum du das so machen möchtest, weil er z.B. aus Erfahrung weiss, dass eine solche Massnahme, alleine für sich nicht wirklich wirkungsvoll ist.
Du kannst einen Domänen-Admin nicht wirklich mit irgendeinem der hier genannten Tipps aussperren!
Eben nicht, zumindest dann, wenn du es auch wirklich nachhaltig machen möchtest, was jedoch nicht wirklich ganz einfach ist, da ein Domain-Admin eben ein Domain-Admin ist und ein Domain-Admin kann neben RDP noch über diverse andere Wegen auf einen Domain-Member zugreifen.
Wenn es nicht um (mehr) Sicherheit geht, um was denn bitte dann?
Gruss Alex
Ich verstehe die hitzige Diskussion nicht.
na ja, du wurdes ja schon mehrfach gefragt, was der Sinn dieser Aktion ist und bisher hast du dazu noch keine Antwort geliefert, ausser, dass du das eben so machen möchtest.
Der eine oder andere von uns, möchte jedoch auch wissen warum du das so machen möchtest, weil er z.B. aus Erfahrung weiss, dass eine solche Massnahme, alleine für sich nicht wirklich wirkungsvoll ist.
Wir möchten bei uns den Remotedesktop Dienst für Administratoren generell geschlossen halten. FERTIG!
Du kannst einen Domänen-Admin nicht wirklich mit irgendeinem der hier genannten Tipps aussperren!
Es ist doch völlig egal warum weshalb usw.
Eben nicht, zumindest dann, wenn du es auch wirklich nachhaltig machen möchtest, was jedoch nicht wirklich ganz einfach ist, da ein Domain-Admin eben ein Domain-Admin ist und ein Domain-Admin kann neben RDP noch über diverse andere Wegen auf einen Domain-Member zugreifen.
ebenso finde ich es anmaßend unser Sicherheitskonzept zu hinterfragen. Darum geht es mir doch überhaupt nicht.
Wenn es nicht um (mehr) Sicherheit geht, um was denn bitte dann?
Gruss Alex