Remote-PowerShell-Zugriff für alle nicht relevanten Benutzer sperren
Hallo,
weiß jemand den besten Weg, um schnellstmöglich alle relevanten User den Remote-Power-Shell zugriff zu sperren?
Hat das schon mal jemand gemacht.
Klar könnte man jetzt jeden User anfassen, aber bei mehr als 1000 User wird es ewig dauern.
Danke im Voraus.
Ich hatte dies schon gefunden, aber die Methode benötigt halt auch viel Zeit:
$<VariableName> = Get-Content <text file>
$<VariableName> | foreach {Set-User -Identity $_ -RemotePowerShellEnabled $false}
weiß jemand den besten Weg, um schnellstmöglich alle relevanten User den Remote-Power-Shell zugriff zu sperren?
Hat das schon mal jemand gemacht.
Klar könnte man jetzt jeden User anfassen, aber bei mehr als 1000 User wird es ewig dauern.
Danke im Voraus.
Ich hatte dies schon gefunden, aber die Methode benötigt halt auch viel Zeit:
$<VariableName> = Get-Content <text file>
$<VariableName> | foreach {Set-User -Identity $_ -RemotePowerShellEnabled $false}
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 4147491788
Url: https://administrator.de/contentid/4147491788
Ausgedruckt am: 25.11.2024 um 09:11 Uhr
11 Kommentare
Neuester Kommentar
Wie wäre es, RemotePowerShell für alle außer die "relevanten User" zu deaktivieren?
etwa so:
Müsstest dann die relevanten User in eine Gruppe packen (Falls sie das nicht schon sind)
Sorry für die ganzen Edits. Jetzt müsste es passen. Ich empfehle immer ein -WhatIf bei Set-User für einen Trockenlauf.
etwa so:
$group = get-adgroup "RELEVANTE USER"
Get-Aduser -Filter "-not memberof -RecursiveMatch '$group'" | % { Set-User -Identity $_.sAMAccountName -RemotePowerShellEnabled $false}
Müsstest dann die relevanten User in eine Gruppe packen (Falls sie das nicht schon sind)
Sorry für die ganzen Edits. Jetzt müsste es passen. Ich empfehle immer ein -WhatIf bei Set-User für einen Trockenlauf.
Hallo,
na das klingt ja so, als habe da jemand vom aktuellen 0-day-Exploit erfahren und verfällt jetzt in leichte Panik.
Die Kernfrage ist aber: Ist es für normale User überhaupt freigegeben. Ohne explizite Konfiguration benötigt ein invoke-command bzw. auch ein enter-pssession erstmal Adminrechte. Es sei denn, du hast eure Benutzer als Remote Management Users eingetragen: Siehe hier. Ist letzteres der Fall, entzieh ihnen die Rechte auf die gleiche Art und Weise, wie du sie hinzugefügt hast. In meinen Augen gibt es keinen Grund, wieso ein normaler Anwender remote PowerShell-Befehle ausführen sollte.
Ansonsten würde ich dir noch empfehlen die GP zu konfigurieren, die du unter Computerrichtlinie > Windows-Komponenten > Windows-Remoteverwaltung findest, mit dem Namen Remoteserververwaltung über WinRM zulassen. Hier gehört eine sauber gepflegte Liste eingetragen, welche Rechner/Server überhaupt WinRM nutzen können dürfen. In meinen Augen reicht auch hier der Managementserver völlig aus. Es gibt auch hier keinen nachvollziehbaren Grund, wieso jedes Gerät WinRM starten können muss.
Und wenn nur der Admin von einem Gerät aus WinRm nutzen kann, dann ist das ganze schonmal recht gut gesichert.
Gruß
Doskias
na das klingt ja so, als habe da jemand vom aktuellen 0-day-Exploit erfahren und verfällt jetzt in leichte Panik.
Die Kernfrage ist aber: Ist es für normale User überhaupt freigegeben. Ohne explizite Konfiguration benötigt ein invoke-command bzw. auch ein enter-pssession erstmal Adminrechte. Es sei denn, du hast eure Benutzer als Remote Management Users eingetragen: Siehe hier. Ist letzteres der Fall, entzieh ihnen die Rechte auf die gleiche Art und Weise, wie du sie hinzugefügt hast. In meinen Augen gibt es keinen Grund, wieso ein normaler Anwender remote PowerShell-Befehle ausführen sollte.
Ansonsten würde ich dir noch empfehlen die GP zu konfigurieren, die du unter Computerrichtlinie > Windows-Komponenten > Windows-Remoteverwaltung findest, mit dem Namen Remoteserververwaltung über WinRM zulassen. Hier gehört eine sauber gepflegte Liste eingetragen, welche Rechner/Server überhaupt WinRM nutzen können dürfen. In meinen Augen reicht auch hier der Managementserver völlig aus. Es gibt auch hier keinen nachvollziehbaren Grund, wieso jedes Gerät WinRM starten können muss.
Und wenn nur der Admin von einem Gerät aus WinRm nutzen kann, dann ist das ganze schonmal recht gut gesichert.
Gruß
Doskias
Ansonsten sollten doch grade aktuell diverse Empfehlungen dazu im Umlauf sein:
https://www.borncity.com/blog/2022/10/04/exchange-server-microsofts-0-da ...
Vor allem ganz wichtig der Hinweis sich nicht selber auszusperren
https://www.borncity.com/blog/2022/10/04/exchange-server-microsofts-0-da ...
Vor allem ganz wichtig der Hinweis sich nicht selber auszusperren
Zitat von @ukulele-7:
Ansonsten sollten doch grade aktuell diverse Empfehlungen dazu im Umlauf sein:
https://www.borncity.com/blog/2022/10/04/exchange-server-microsofts-0-da ...
Vor allem ganz wichtig der Hinweis sich nicht selber auszusperren
Ansonsten sollten doch grade aktuell diverse Empfehlungen dazu im Umlauf sein:
https://www.borncity.com/blog/2022/10/04/exchange-server-microsofts-0-da ...
Vor allem ganz wichtig der Hinweis sich nicht selber auszusperren
Wenn du die WinRM Konfiguration via GPO vornimmst, dann kannst du dich im Prinzip nicht selbst aussperren. Und wenn doch, dann änderst du die WinRM Einstellung halt wieder und kommst nach kurzer Zeit selbst wieder rauf. Aber ja, kann passieren. Im Zweifelsfall gibst du halt WinRM erstmal für alle Server frei (siehe oben). Es bleibt auf jeden Fall dabei, dass nicht jeder User und nicht jeder Client WinRM ausführe können muss
Weil ich leider nicht richtig nachgedacht habe, habe ich alle ausgesperrt!!
Ein
$RPSE = Get-User -ResultSize Unlimited
$RPSE | foreach {Set-User -Identity $_ -RemotePowerShellEnabled $false}
sollte man tunlichst vermeiden!!
Damit dürfen ALLE nichts mehr machen auf den Exchange Server!!
Die Exchange-Verwaltungskonsole: Fehler beim Versuch mit HTTPS-Protokoll "URL": Kerberos
PS Konsole: Get-User // Fehler beim Starten eines Befehls auf dem Remoteserver. Die folgende Fehlermeldung wird ausgegeben: Der WinRM-Client hat einen Status in Bezug auf einen HTTP-Serverfehler (500) empfangen, aber der Remotedienst hat keine anderen Informationen zur Fehlerursache bereitgestellt. Weitere Informationen finden Sie im Hilfethema "about_Remote_Troubleshooting".
und so weiter ...
Natürlich stehe ich jetzt dumm da und suche Hilfe ...
Ein
$RPSE = Get-User -ResultSize Unlimited
$RPSE | foreach {Set-User -Identity $_ -RemotePowerShellEnabled $false}
sollte man tunlichst vermeiden!!
Damit dürfen ALLE nichts mehr machen auf den Exchange Server!!
Die Exchange-Verwaltungskonsole: Fehler beim Versuch mit HTTPS-Protokoll "URL": Kerberos
PS Konsole: Get-User // Fehler beim Starten eines Befehls auf dem Remoteserver. Die folgende Fehlermeldung wird ausgegeben: Der WinRM-Client hat einen Status in Bezug auf einen HTTP-Serverfehler (500) empfangen, aber der Remotedienst hat keine anderen Informationen zur Fehlerursache bereitgestellt. Weitere Informationen finden Sie im Hilfethema "about_Remote_Troubleshooting".
und so weiter ...
Natürlich stehe ich jetzt dumm da und suche Hilfe ...
Ich frage mich, wo das gespeichert wird. Ein entsprechendes AD-Attribut finde ich nicht..
Ich würde einen neuen Post erstellen, nicht dass das hier untergeht.
Ich würde einen neuen Post erstellen, nicht dass das hier untergeht.
Lässt sich korrigieren, entweder hiermit auf dem EX ...
Oder durch Hinzufügen der jeweiligen User zur Gruppe der "Remote Management Users" am Exchange.
Set-PSSessionConfiguration -Name Microsoft.Exchange -showSecurityDescriptorUI
Habe inzwischen auch das zugehörige AD-Attribut gefunden:
Es ist ein Eintrag im Multistring-Attribut "protocolSettings"
aktiviert: RemotePowerShell§1 oder kein Eintrag
deaktiviert: RemotePowerShell§0
Es ist ein Eintrag im Multistring-Attribut "protocolSettings"
aktiviert: RemotePowerShell§1 oder kein Eintrag
deaktiviert: RemotePowerShell§0
Noch den Thread als gelöst markieren und alle sind glücklich Prost