Einführung in PowerShell Remoting (WinRM) ── Mehrere Windows-Rechner gebündelt verwalten

„Prüf nach dem Windows-Update mal, ob alle zwanzig Server ordentlich hochgefahren sind.“ „Finde heraus, wie dieser Einstellungswert auf den PCs an allen Standorten gerade steht.“ ── Erledigen Sie solche Anfragen, indem Sie sich per Remotedesktop nacheinander in jeden Rechner einloggen? Selbst bei drei Minuten pro Rechner sind zwanzig Rechner eine Stunde. Menschen werden dabei unaufmerksam, und Prüfungen fallen unter den Tisch.

PowerShell Remoting ist der Mechanismus, der aus „derselben Arbeit auf vielen Rechnern“ einen einzigen Befehl macht. Windows bringt mit WinRM eine Grundlage für Remoteverwaltung von Haus aus mit, die auf Windows Server standardmäßig aktiviert ist. Das heißt, an vielen Arbeitsplätzen können Sie es noch heute nutzen, ohne zusätzliche Software zu installieren. Dennoch hört man häufig „das wirkt irgendwie riskant“ oder „es hat sich in unserer Arbeitsgruppe nicht verbunden, also habe ich aufgegeben“.

Dieser Artikel richtet sich an IT-Verantwortliche und Betriebspersonal in kleinen und mittleren Unternehmen. Er behandelt, wie Remoting funktioniert (was auf welchem Port läuft und wer sich verbinden kann), die Ausführung über mehrere Rechner hinweg mit Invoke-Command, den Unterschied zwischen Domänen- und Arbeitsgruppenumgebung, bekannte Fallen wie das Second-Hop-Problem sowie den sicheren Alltagsbetrieb, der „mit Lesezugriff beginnt“.

1. Zunächst das Ergebnis

• PowerShell Remoting läuft auf WinRM (einer Implementierung von WS-Management) und nutzt standardmäßig die Ports HTTP 5985 / HTTPS 5986. Selbst über HTTP wird der Datenverkehr durch eine vom Authentifizierungsprotokoll bereitgestellte Verschlüsselung auf Nachrichtenebene geschützt.¹
• Standardmäßig können sich nur Mitglieder der Gruppe Administratoren auf der Remoteseite verbinden, und die Sitzung läuft im Kontext des verbindenden Benutzers. Remoting zu aktivieren bedeutet nicht, dass „jeder hineinkommt“.¹
• Was Enable-PSRemoting bewirkt, ist klar definiert. Es startet den WinRM-Dienst und setzt ihn auf automatischen Start, erstellt einen Listener, fügt eine Firewall-Ausnahme hinzu und aktiviert die Sitzungskonfigurationen. Auf Windows Server ist es standardmäßig aktiviert; auf Windows-Clienteditionen aktivieren Sie es manuell.²¹
• Eine Domänenumgebung funktioniert unverändert mit Kerberos; eine Arbeitsgruppe benötigt NTLM + TrustedHosts + ausdrückliche Anmeldeinformationen. TrustedHosts ist keine Einstellung, die besagt „ich vertraue diesem Rechner“ ── es ist eine Liste von Rechnern, deren Identitätsprüfung Sie aufgegeben haben, also halten Sie sie minimal.³¹
• Nutzen Sie Invoke-Command, um etwas überall auszuführen, Enter-PSSession für interaktive Arbeit und New-PSSession, wenn Sie Zustand behalten und die Verbindung wiederverwenden möchten. Invoke-Command verarbeitet standardmäßig bis zu 32 Rechner parallel.⁴⁵
• Was von der Remoteseite zurückkommt, ist ein deserialisiertes Objekt ohne Methoden. Schließen Sie die eigentlichen Vorgänge innerhalb des ScriptBlocks (auf der Remoteseite) ab, und werten Sie die Ergebnisse nur lokal aus.⁶⁵
• Sie können von dem Rechner, mit dem Sie sich verbunden haben, keinen weiteren Server erreichen (das Second-Hop-Problem). Das ist kein Defekt, sondern die Folge eines sicheren Designs, das Ihre Anmeldeinformationen nicht an die Remoteseite sendet. Es gibt mehrere Abhilfen, je nach Anforderung.⁷
• PowerShell 7 unterstützt außerdem SSH-basiertes Remoting. Das ist eine Option, wenn Sie Linux zusammen mit Windows verwalten müssen oder in Umgebungen, in denen Sie WinRM lieber nicht öffnen möchten.⁸

2. Wie es funktioniert ── wer kommt wie hinein, oberhalb von WinRM

Die Grundlage von PowerShell Remoting ist WinRM (Windows Remote Management). WinRM ist Microsofts Implementierung des Standardprotokolls WS-Management, und PowerShell Remoting liefert darüber Befehle an PowerShell auf einem Remotecomputer.¹ Die Kommunikation nutzt standardmäßig die Ports 5985 (HTTP) und 5986 (HTTPS).¹³

Man befürchtet oft, „HTTP bedeutet Klartext“, aber sobald die anfängliche Authentifizierung abgeschlossen ist, verschlüsselt WinRM den Datenverkehr. Über HTTPS ist das TLS, über HTTP eine vom Authentifizierungsprotokoll ausgehandelte Verschlüsselung auf Nachrichtenebene (bei Kerberos in einer modernen Umgebung AES-256).¹ Zudem können sich standardmäßig nur Mitglieder der Gruppe Administratoren auf der Remoteseite verbinden, und da die Sitzung im Kontext des verbindenden Benutzers läuft, greift die Zugriffssteuerung für Dateien und Registrierung genau wie sonst auch.¹

Die Vorbereitung auf der empfangenden Seite ist Enable-PSRemoting. Was dieses Cmdlet bewirkt, ist offiziell aufgezählt. Es führt intern Set-WSManQuickConfig aus, um (1) den WinRM-Dienst zu starten, (2) den Starttyp auf automatisch zu setzen, (3) einen Listener zu erstellen, der Anfragen auf jeder IP-Adresse annimmt, (4) die Firewall-Ausnahme für WS-Management-Datenverkehr zu aktivieren und (5) die Sitzungskonfigurationen (Endpunkte) zu erstellen und zu aktivieren sowie Remotezugriff zu gewähren ── und startet dann den WinRM-Dienst neu.²

# Einmal auf dem Rechner ausführen, der Verbindungen ENTGEGENNIMMT, aus einer erhöhten PowerShell-Sitzung
# (auf Windows Server meist unnötig, da standardmäßig aktiviert; auf Windows-Clients erforderlich)
Enable-PSRemoting

# Verbindungstest vom Rechner aus, von dem aus Sie sich VERBINDEN ── gelingt das, ist die Grundlage für Remoting gelegt
Test-WSMan -ComputerName sv-app01

Es gibt zwei Verhaltensweisen, die Sie ins Stolpern bringen, wenn Sie sie nicht kennen. Die erste ist die Firewall. Auf Server-Editionen von Windows erstellt Enable-PSRemoting auch für öffentliche Netzwerke eine Regel, die auf „nur vom selben Subnetz“ beschränkt ist; auf Clienteditionen schlägt die Aktivierung bei öffentlichem Netzwerkprofil ganz fehl (ein klassisches Problem, wenn Sie einen Testrechner mit dem Büro-WLAN verbinden). In diesem Fall fügen Sie -SkipNetworkProfileCheck hinzu oder ändern das Profil auf Privat.²

Der zweite Punkt ist das Verhältnis zwischen PowerShell-Versionen und Endpunkten. Enable-PSRemoting konfiguriert den Endpunkt „für die Version von PowerShell, aus der heraus Sie es ausgeführt haben“. Wird es unter PowerShell 7 ausgeführt, hat das keine Auswirkung auf den Endpunkt von Windows PowerShell 5.1, und umgekehrt.² Mehr noch: Selbst wenn Sie sich von PowerShell 7 aus verbinden, wird standardmäßig der bestehende Endpunkt von Windows PowerShell 5.1 (Microsoft.PowerShell) verwendet,⁹ sodass „ich bin lokal auf 7, aber remote lief eigentlich 5.1“ ganz normal vorkommt. Gewöhnen Sie sich an, zur Kontrolle $PSVersionTable auf der Remoteseite anzuzeigen.

3. Domäne versus Arbeitsgruppe ── hier liegt die Authentifizierungshürde

Der größte Stolperstein für Neulinge bei Remoting ist nicht die Befehlssyntax, sondern die Authentifizierung. Die nötige Vorbereitung ändert sich mit der Umgebung.

In einer Domänenumgebung greift die gegenseitige Kerberos-Authentifizierung (Client und Server prüfen sich gegenseitig), sodass Invoke-Command -ComputerName sv-app01 { ... } einfach funktioniert. In einer Arbeitsgruppe steht Kerberos nicht zur Verfügung,³ daher registrieren Sie das Ziel auf der verbindenden Seite in TrustedHosts.

# Auf dem Rechner ausführen, von dem aus Sie sich VERBINDEN, aus einer als Administrator gestarteten PowerShell-Sitzung (nur Arbeitsgruppen)
# Das Ändern von TrustedHosts erfordert ebenfalls Administratorrechte. Der bestehende Wert wird überschrieben, daher zuerst prüfen
Get-Item WSMan:\localhost\Client\TrustedHosts

# Nur den minimal nötigen Satz an Hostnamen ergänzen. Ohne -Concatenate werden bestehende Einträge gelöscht. Vermeiden Sie eine Freigabe für alle mit '*'
Set-Item WSMan:\localhost\Client\TrustedHosts -Value 'sv-app01,sv-app02' -Concatenate

# Verbindung mit ausdrücklichen Anmeldeinformationen testen
$cred = Get-Credential sv-app01\Administrator
Invoke-Command -ComputerName sv-app01 -Credential $cred -ScriptBlock { hostname }

Wichtig ist hier, was TrustedHosts tatsächlich bedeutet. Die offizielle Dokumentation stellt unmissverständlich fest, dass „Computer in der TrustedHosts-Liste nicht authentifiziert werden und der Client ihnen möglicherweise Anmeldeinformationen sendet“.³ Mit anderen Worten: Das ist weniger „eine Liste vertrauenswürdiger Rechner“ als vielmehr „eine Liste, die die Warnung unterdrückt, dass die Identität des Servers nicht überprüft werden kann“.¹ In einer Umgebung, in der DNS oder ARP manipuliert wurde, riskieren Sie, Administrator-Anmeldeinformationen an einen Betrüger-Server zu übergeben. Vermeiden Sie deshalb Platzhalter-Einträge und listen Sie nur einen minimalen Satz fester Hostnamen oder IP-Adressen. Für eine Arbeitsgruppenumgebung oder DMZ, die Sie ernsthaft betreiben möchten, ist es die solidere technische Entscheidung, ein Zertifikat zu beschaffen und einen HTTPS-Listener (5986) zu konfigurieren.¹

Noch ein Hinweis: Wenn Sie anfangen, mit Get-Credential erhaltene Anmeldeinformationen im Klartext in ein Skript zu schreiben, ist das ein Warnsignal. Die üblichen Vorgehensweisen zum Speichern und Weitergeben von Anmeldeinformationen sind in dem gleichzeitig veröffentlichten Artikel „Anmeldeinformationen in PowerShell sicher handhaben“ zusammengetragen.

4. Invoke-Command ── die Grundform von „dasselbe auf 20 Rechnern tun“

Der Star von Remoting ist Invoke-Command. Sie übergeben mehrere Rechner an -ComputerName und schreiben in -ScriptBlock, „was remote geschehen soll“.⁴ Mit einer schreibgeschützten Bestandsaufnahme zu beginnen ist die goldene Regel des sicheren Betriebs.

$servers = 'sv-app01', 'sv-app02', 'sv-db01'

# Statusprüfung nach dem Patchen ── nur lesend, daher unbesorgt ausführbar
$result = Invoke-Command -ComputerName $servers -ScriptBlock {
    # Alles innerhalb dieses Blocks läuft auf der REMOTESEITE
    $os = Get-CimInstance Win32_OperatingSystem
    [PSCustomObject]@{
        LastBoot   = $os.LastBootUpTime                      # Ist der Neustart abgeschlossen?
        SpoolerRun = (Get-Service -Name Spooler).Status      # Status eines geschäftskritischen Diensts
        FreeGB     = [math]::Round((Get-PSDrive C).Free / 1GB, 1)
    }
}

# PSComputerName verrät, welches Ergebnis von welchem Server stammt
$result | Sort-Object PSComputerName |
    Select-Object PSComputerName, LastBoot, SpoolerRun, FreeGB |
    Export-Csv -Path .\patch-check.csv -NoTypeInformation -Encoding UTF8

Die Verbindungen zu den einzelnen Servern werden parallel verarbeitet, und die Standard-Nebenläufigkeit (ThrottleLimit) beträgt 32.⁵ Ergebnisse kommen in der Reihenfolge ihres Eintreffens vermischt zurück, sortieren Sie sie daher wie im obigen Beispiel anhand der automatisch hinzugefügten Eigenschaft PSComputerName.⁶

4.1. Variablen übergeben ── $using: und -ArgumentList

Da der ScriptBlock remote ausgeführt wird, sind Ihre lokalen Variablen dort nicht sichtbar. Es gibt zwei Wege, Werte hineinzubringen.¹¹

$threshold = (Get-Date).AddDays(-30)

# Methode 1: $using: ── bettet eine Kopie des Werts der aufrufenden Variable in die Remoteseite ein
Invoke-Command -ComputerName $servers -ScriptBlock {
    (Get-ChildItem 'D:\AppLogs' -Filter *.log |
        Where-Object LastWriteTime -lt $using:threshold).Count
}

# Methode 2: -ArgumentList ── wird über eine param-Deklaration innerhalb des ScriptBlocks empfangen (bei vielen Argumenten besser lesbar)
Invoke-Command -ComputerName $servers -ScriptBlock {
    param($limit)
    (Get-ChildItem 'D:\AppLogs' -Filter *.log |
        Where-Object LastWriteTime -lt $limit).Count
} -ArgumentList $threshold

Der über $using: übergebene Wert ist auf der Remoteseite eine unabhängige Kopie. Ändern Sie ihn remote, bleibt Ihre lokale Variable unverändert.¹¹

4.2. Was zurückkommt, ist ein „Schnappschuss“ ── deserialisierte Objekte

Das ist das Erste, was bei Remoting-Ergebnissen für Verwirrung sorgt. Lebende .NET-Objekte können kein Netzwerk überqueren, daher wird die Remoteausgabe zu XML (CLIXML) serialisiert, gesendet und lokal als deserialisiertes Objekt wiederhergestellt. Es ist ein Schnappschuss der Eigenschaften zum Ausführungszeitpunkt und besitzt keine Methoden.⁶⁵

Sie können zum Beispiel das lokal empfangene Ergebnis von Get-Service nicht nehmen und darauf .Stop() aufrufen. Möchten Sie einen Dienst stoppen, führen Sie Stop-Service innerhalb des ScriptBlocks aus ── teilen Sie die Rollen also so auf, dass Vorgänge auf der Remoteseite abgeschlossen werden und nur Berichtsdaten mit nach Hause gebracht werden. Die lokale Nachbearbeitung wie Eigenschaftenauswahl, Formatierung und CSV-Erstellung funktioniert genauso wie im gewöhnlichen PowerShell-Alltag (zu diesen Grundoperationen siehe „PowerShell-Befehlsgrundlagen“).

5. Enter-PSSession und New-PSSession ── interaktive Arbeit und Wiederverwendung

Möchten Sie einen einzelnen Rechner interaktiv untersuchen, nutzen Sie Enter-PSSession. Die Eingabeaufforderung wechselt zu [sv-app01]: PS>, und die eingegebenen Befehle laufen remote. Mit exit verlassen Sie sie.¹⁰ Anders als Remotedesktop bringt es keine grafische Oberfläche mit, aber für „einen Blick ins Protokoll“ oder „eine Einstellung prüfen“ ist es schneller, und es erfordert ebenso Mitgliedschaft in der Remote-Administratorengruppe für die Verbindung.¹⁰

Andererseits wird bei jedem Aufruf von Invoke-Command mit -ComputerName eine Verbindung auf- und abgebaut.¹² Bei Untersuchungsarbeiten, bei denen Sie derselben Servergruppe viele Befehle zuwerfen, ist es schneller, mit New-PSSession eine dauerhafte Sitzung zu erstellen und wiederzuverwenden ── und Variablen und Zustand auf der Remoteseite bleiben zwischen den Befehlen erhalten.¹²¹³

# Die Sitzung einmal öffnen und über die Variable $s wiederverwenden
$s = New-PSSession -ComputerName $servers
try {
    # Erster Aufruf: eine Variable namens $hotfix auf der Remoteseite erstellen
    Invoke-Command -Session $s { $hotfix = Get-HotFix | Sort-Object InstalledOn -Descending }

    # Zweiter Aufruf: die vom vorigen Befehl erstellte Variable steht weiterhin zur Verfügung (die Sitzung behält den Zustand)
    Invoke-Command -Session $s { $hotfix | Select-Object -First 5 }
}
finally {
    # Immer aufräumen, auch bei Fehler oder Abbruch zwischendurch (gibt Ressourcen auf der Remoteseite frei)
    Remove-PSSession $s
}

6. Fallstricke ── der Second Hop und SSH als Option

6.1. Das Second-Hop-(Doppelsprung-)Problem

Das ist die bekannteste Hürde in der Praxis. Sie verbinden sich von Ihrem PC (A) per Remoting mit Server B, und aus B heraus versuchen Sie, \\fs01\share (Server C) zu lesen ── und erhalten eine Zugriffsverweigerung. Die standardmäßige Kerberos-/NTLM-Authentifizierung ist ein sicheres Verfahren, das Ihre Anmeldeinformationen selbst nicht an B sendet, sodass sich B nicht in Ihrem Namen bei C authentifizieren kann.¹⁷

Es gibt mehrere Abhilfen, und die offizielle Dokumentation ordnet sie in empfohlener Reihenfolge.⁷ Die wichtigsten sind:

• Anmeldeinformationen innerhalb des ScriptBlocks ausdrücklich übergeben ── am einfachsten, ohne Konfigurationsänderung auf der Serverseite. Sie übergeben Anmeldeinformationen mit $using:cred an das innere Invoke-Command.⁷ Da das Anmeldeinformationsobjekt jedoch an die Sitzung auf dem vermittelnden Server (B) übergeben wird, könnte ein kompromittiertes B auch verwenden, was Sie übergeben haben ── die Voraussetzung ist also, dies nur zu tun, wenn Sie B vollständig vertrauen, und dass das übergebene Konto ein dediziertes Konto mit minimal nötigen Rechten auf C ist.
• Ressourcenbasierte eingeschränkte Kerberos-Delegierung ── ein Verfahren, das keine Anmeldeinformationen speichert und stattdessen das Ziel (C) so konfiguriert, dass es „die Delegierung von B akzeptiert“. Es lässt sich ohne Domänenadministratorrechte konfigurieren und bietet eine gute Balance zwischen Sicherheit und Konfigurationsaufwand.⁷
• CredSSP ── Anmeldeinformationen werden auf dem Remoteserver zwischengespeichert, sodass sie bei dessen Kompromittierung ebenfalls gestohlen werden. Es ist standardmäßig deaktiviert, und die Aktivierung sollte auf Ihre vertrauenswürdigsten Umgebungen beschränkt bleiben.⁷

# Der einfachste Workaround: Anmeldeinformationen mit $using:cred an das innere Invoke-Command übergeben
# Verbinden Sie sich mit dem äußeren Rechner (sv-app01) mit Ihren eigenen Anmeldeinformationen, und
# übergeben Sie nach innen nur ein dediziertes Konto mit minimal nötigen Rechten auf fs01 (keine Administrator-Anmeldeinformationen verteilen)
$cred = Get-Credential CONTOSO\svc-fileread
Invoke-Command -ComputerName sv-app01 -ScriptBlock {
    Invoke-Command -ComputerName fs01 -Credential $using:cred -ScriptBlock { hostname }
}

Die günstigste Lösung von allen ist es, zunächst zu fragen, ob sich „das Lesen der Dateien von C über B“ ganz vermeiden lässt, indem Sie stattdessen von Ihrem eigenen Rechner aus direkt Invoke-Command gegen C ausführen.

6.2. Mit PowerShell 7 können Sie auch SSH-basiertes Remoting wählen

Ab PowerShell 6.0 können Sie statt WinRM auch Remoting über SSH nutzen. Invoke-Command / Enter-PSSession / New-PSSession haben SSH-Parametersätze mit -HostName, -UserName und -KeyFilePath erhalten, was die Verwaltung über Windows und Linux hinweg erlaubt.⁸ Das Ziel benötigt einen SSH-Server und ein konfiguriertes PowerShell-SSH-Subsystem, und Funktionen, die in der WinRM-basierten Welt existieren, etwa Endpunktkonfigurationen und JEA, werden derzeit nicht unterstützt.⁸ Das ist eine gute Option, die Sie sich für Umgebungen mit Linux-Servern oder für den Wunsch nach einheitlicher schlüsselbasierter Authentifizierung merken sollten. Windows PowerShell 5.1 besitzt diese Funktion nicht, was bei Bedarf ein Migrationsanreiz sein kann (das Gesamtbild der Unterschiede finden Sie im gleichzeitig veröffentlichten Artikel „Die Unterschiede zwischen Windows PowerShell 5.1 und PowerShell 7“).

Übrigens erzeugt eine Remoting-Sitzung keine Desktopsitzung wie RDP. Wie sich die Bedeutung von „läuft remote“ zwischen beiden unterscheidet, ordnet „Wie Sie die Sitzungstrennung von Windows verstehen sollten“ ein.

7. Bewährte Praxis (Entscheidungstabelle)

Betonen wir die letzte Zeile. Invoke-Command ist gleichzeitig „der Befehl, der 20 Rechner in einem Augenblick repariert“ und „der Befehl, der 20 Rechner in einem Augenblick beschädigt“. Zum Glück unterstützen viele verändernde Cmdlets wie Stop-Service und Set-ItemProperty -WhatIf, und sie funktionieren innerhalb eines ScriptBlocks genauso. Machen Sie sich drei Stufen zur Gewohnheit ── zuerst ein Rechner, dann alle Rechner mit -WhatIf, und erst dann der echte Lauf ── und Ihre Fehlerquote sinkt sichtbar.

8. Zusammenfassung

• Remoting läuft auf WinRM (WS-Management), mit den Standardports HTTP 5985 / HTTPS 5986. Standardmäßig können sich nur Mitglieder der Remote-Administratorengruppe verbinden, und der Datenverkehr wird nach der Authentifizierung verschlüsselt.
• Enable-PSRemoting startet den WinRM-Dienst, erstellt einen Listener, fügt eine Firewall-Ausnahme hinzu und aktiviert die Sitzungskonfigurationen. Beachten Sie, dass der Endpunkt für die Version konfiguriert wird, aus der heraus Sie es ausgeführt haben.
• Domänen funktionieren unverändert mit Kerberos; Arbeitsgruppen benötigen TrustedHosts + ausdrückliche Anmeldeinformationen. TrustedHosts ist eine Liste von Rechnern, deren Identitätsprüfung Sie aufgegeben haben, halten Sie sie deshalb minimal.
• Nutzen Sie Invoke-Command, um etwas überall auszuführen (standardmäßig 32 parallel), Enter-PSSession für interaktive Arbeit, und wiederholen Sie New-PSSession, wenn Sie Zustand behalten müssen. Ergebnisse sind deserialisierte Objekte ohne Methoden, schließen Sie Ihre Vorgänge also auf der Remoteseite ab.
• Sie können über den verbundenen Rechner hinaus nichts erreichen (der Second Hop). Beginnen Sie mit ausdrücklich übergebenen Anmeldeinformationen; erwägen Sie für dauerhaften Betrieb ressourcenbasierte eingeschränkte Kerberos-Delegierung.
• Beginnen Sie den Betrieb mit lesenden Befehlen. Nutzen Sie bei verändernden Vorgängen drei Stufen: ein Rechner → -WhatIf → der echte Lauf. Ein konkretes Beispiel, angewendet auf eine Dateiserver-Bestandsaufnahme, finden Sie im gleichzeitig veröffentlichten Artikel „PowerShell für die Dateiserver-Bestandsaufnahme“.

Verwandte Artikel

• PowerShell-Befehlsgrundlagen ── Die zuerst zu lernenden Operationen und ihre sichere Anwendung
• Praktische PowerShell-Befehlssammlung ── Die kleinen Werkzeuge des Arbeitsalltags erweitern
• PowerShell für die Dateiserver-Bestandsaufnahme ── Kapazitätsanalyse und Zugriffsrechte-(ACL)-Audit
• Anmeldeinformationen in PowerShell sicher handhaben
• Wie Sie die Sitzungstrennung von Windows verstehen sollten ── Sitzung 0, RDP und das gleichzeitige Ausführen mehrerer Benutzer
• Windows-Identitätswechsel-Token richtig handhaben ── Rechteübernahme pro Thread und sicheres Zurücksetzen

Verwandte Beratungsbereiche

Die KomuraSoft LLC übernimmt den Aufbau von Mechanismen zur gebündelten Verwaltung von Servern und Clients mit PowerShell, die Gestaltung und Überprüfung von Betriebsskripten, die Remoting einbinden, sowie die Untersuchung von WinRM- und Authentifizierungsproblemen wie „es verbindet sich nicht“ oder „die Authentifizierung schlägt nur in einer bestimmten Umgebung fehl“.

• Technische Beratung & Designüberprüfung
• Fehleruntersuchung & Ursachenanalyse
• Windows-App-Entwicklung
• Kontakt

Referenzlinks

Verwandte Artikel

Aktuelle Artikel mit denselben Schlagwörtern führen zu verwandten Themen weiter.

Verwandte Themen

Diese Seiten ordnen den Artikel in einen größeren Leistungs- und Entscheidungskontext ein.

Leistungen zu diesem Thema

Dieser Artikel ist direkt mit den folgenden Leistungen verbunden.

Häufige Fragen

Fragen, die in Beratungen zu diesem Artikelthema häufig gestellt werden.

Was passiert, wenn ich Enable-PSRemoting ausführe?

Intern wird Set-WSManQuickConfig ausgeführt, wodurch der WinRM-Dienst gestartet und auf automatischen Start gesetzt wird, ein Listener erstellt wird, der Anfragen auf jeder IP-Adresse annimmt, die Firewall-Ausnahme für WS-Management-Datenverkehr aktiviert wird und die Sitzungskonfigurationen (Endpunkte) aktiviert werden, wobei ihre Sicherheitsdeskriptoren so geändert werden, dass sie den Remotezugriff erlauben. Auf Windows Server ist dies standardmäßig aktiviert, auf Windows-Clienteditionen müssen Sie es selbst ausführen. Es wird nur auf dem Rechner benötigt, der Verbindungen entgegennimmt; auf dem Rechner, von dem aus Sie sich verbinden, ist es nicht nötig.

Was benötige ich, um PowerShell Remoting in einer Arbeitsgruppenumgebung (ohne Domäne) zu verwenden?

Ohne Domäne gibt es kein Kerberos, sodass die Authentifizierung auf NTLM zurückfällt. Das Grundmuster besteht darin, das Ziel auf dem verbindenden Rechner in der WSMan-Liste TrustedHosts zu registrieren und Anmeldeinformationen mit -Credential ausdrücklich zu übergeben. Beachten Sie jedoch, dass ein in TrustedHosts eingetragener Host Ihre Anmeldeinformationen erhalten kann, ohne dass seine Identität jemals überprüft wird. Registrieren Sie deshalb nur den minimal nötigen Satz an Hostnamen statt eines Platzhalters, und erwägen Sie, wo möglich, einen HTTPS-Listener (5986) zu konfigurieren.

Warum lassen sich auf den von Invoke-Command zurückgegebenen Objekten keine Methoden aufrufen?

Weil die Ausgabe eines Remote-Befehls zur Übertragung über das Netzwerk zu XML (CLIXML) serialisiert und lokal als deserialisiertes Objekt wiederhergestellt wird. Dieses Objekt ist ein Schnappschuss der Eigenschaften zum Ausführungszeitpunkt, kein lebendes Objekt, und besitzt daher keine Methoden. Vorgänge wie das Stoppen eines Diensts müssen innerhalb des ScriptBlocks (auf der Remoteseite) ausgeführt werden, statt eine Methode lokal aufzurufen.

Was ist das Second-Hop-(Doppelsprung-)Problem?

Es ist das Problem, dass Sie sich von PC A per Remoting mit Server B verbinden und dann der Zugriff verweigert wird, wenn B versucht, einen weiteren Server C zu erreichen (etwa einen Dateiserver). Die standardmäßige Kerberos-/NTLM-Authentifizierung sendet Ihre Anmeldeinformationen selbst nicht an B, sodass sich B nicht als Sie bei C authentifizieren kann. Zu den Abhilfen gehören die ausdrückliche Übergabe von Anmeldeinformationen innerhalb des ScriptBlocks, ressourcenbasierte eingeschränkte Kerberos-Delegierung und CredSSP (das das Risiko erhöht, weil Anmeldeinformationen an die Remoteseite gelangen); Sie wählen je nach Anforderung.

Kann sich jeder mit PowerShell Remoting verbinden?

Nein. Standardmäßig können nur Mitglieder der Gruppe Administratoren des Remotecomputers eine Verbindung herstellen. Zudem läuft die Sitzung nach der Verbindung im Kontext des verbindenden Benutzers, sodass die Zugriffssteuerung des Betriebssystems ganz normal greift. Dennoch ist es ein mächtiger Zugang für Administratoren, also betreiben Sie es in Kombination mit mehrschichtigen Schutzmaßnahmen: Überprüfung der Firewallregeln, HTTPS-Listener und Beschränkung auf nur die Administratoren, die es tatsächlich benötigen.

Autorenprofil

Profilseite des Artikelautors.

Go Komura

Geschäftsführer von KomuraSoft LLC

Spezialisiert auf Windows-Softwareentwicklung, technische Beratung und Fehleranalyse, insbesondere bei bestehenden Systemen und schwer reproduzierbaren Störungen.