# WinRM: PowerShell Remoting für Enterprise-Admins

TL;DR / Management Summary WinRM (Windows Remote Management) ist das Standard-Management-Protokoll für Windows. Es basiert auf dem WS-Management (WS-Man) Standard und ermöglicht die Ausführung von PowerShell-Befehlen auf entfernten Systemen (PSRemoting). Für Senior Admins ist es das Rückgrat der Automatisierung: Weg von RDP (Einzelzugriff), hin zu paralleler Verwaltung von hunderten Systemen via Invoke-Command. Sicherheit wird durch Kerberos (AD) oder HTTPS (Zertifikate) gewährleistet.

# 1. Einführung & Architektur

Die Shell über das Netzwerk.

PSRemoting nutzt HTTP (Port 5985) oder HTTPS (Port 5986) als Transportweg. Wichtig: Die Daten werden bei Kerberos-Authentifizierung (Domain) immer verschlüsselt, auch über HTTP.

# Kern-Komponenten

• WinRM Service: Der Listener auf dem Ziel-PC.
• Listener: Definiert IP und Port, auf denen WinRM lauscht.
• Session Configuration (Endpoint): Definiert, was der User im Remote-Kontext darf (z.B. eingeschränkte Befehlssätze).

# Architektur-Übersicht (Mermaid)

graph LR
    ADMIN[Admin Workstation] -->|WS-Man / HTTPs| TARGET[Target Client / Server]
    TARGET -->|Auth| DC[Active Directory / Kerberos]
    ADMIN -->|Invoke-Command| PS_SESS[PowerShell Session]
    PS_SESS -->|Result Objects| ADMIN

# 2. PSRemoting in der Praxis

Verbinden und Verwalten.

# Aktivierung (One-Liner)

# Aktiviert WinRM, erstellt Firewall-Ausnahmen und startet den Dienst
Enable-PSRemoting -Force

# Interaktive Session (wie SSH)

Enter-PSSession -ComputerName "PC-Marketing-01"
# [PC-Marketing-01]: PS C:\> ...

# Parallele Ausführung (Der echte Mehrwert)

# Installiert ein Update auf allen PCs aus einer Liste gleichzeitig
Invoke-Command -ComputerName (Get-Content "C:\PCs.txt") -ScriptBlock { 
    Start-Process winget -ArgumentList "upgrade --all --silent" -Wait 
}

# 3. Deep Dive: Authentifizierung & Security

Schutz vor Missbrauch.

WinRM ist ein mächtiges Ziel für Angreifer (Lateral Movement).

# 1. Trusted Hosts (Nicht empfohlen!)

Nutzen Sie TrustedHosts nur in isolierten Test-Umgebungen ohne Domäne. In der Produktion ist Kerberos der Standard.

# 2. HTTPS-Listener (Zwingend für Workgroups)

Wenn Sie PCs außerhalb der Domäne verwalten (z.B. Proxmox-Hosts, die Windows-VMs steuern):

# Erstellt einen HTTPS-Listener mit einem SSL-Zertifikat
New-Item -Path WSMan:\Localhost\Listener -Transport HTTPS -Address * -CertificateThumbprint "ABCD..."

# 3. JEA (Just Enough Administration)

Erlauben Sie dem Helpdesk nur spezifische Befehle (z.B. “Dienst neustarten”), ohne dass diese volle Admin-Rechte auf dem Ziel-PC benötigen.

# 4. Day-2 Operations: WinRM-Quotas

Ressourcen-Limits setzen.

Standardmäßig begrenzt WinRM den RAM und die Anzahl der parallelen Shells pro User.

# Zeigt die aktuellen Limits
winrm get winrm/config/winrs

# Erhöht das Memory-Limit pro Shell (Wichtig für schwere Skripte)
winrm set winrm/config/winrs '@{MaxMemoryPerShellMB="1024"}'

# 5. Troubleshooting & “War Stories”

Wenn der Connect scheitert.

# Top 3 Fehlerbilder

1. Symptom: “Der Client kann keine Verbindung zum im Ziel angegebenen Ziel herstellen”.

   • Ursache: Firewall auf dem Ziel-PC blockiert Port 5985/5986 oder der Dienst läuft nicht.
   • Lösung: tnc <IP> -p 5985 prüfen (Artikel 468).

2. Symptom: “Access Denied” trotz Admin-Rechten.

   • Ursache: Lokaler User-Kontext. WinRM erlaubt standardmäßig keine Elevation von lokalen Accounts ohne Registry-Härtung.
   • Lösung: LocalAccountTokenFilterPolicy = 1 setzen (nur für lokale Admins nötig).

3. Symptom: “WinRM cannot process the request… Kerberos error”.

   • Ursache: Uhrzeit-Differenz (> 5 Min) zwischen Admin-PC und Ziel-PC.
   • Lösung: Zeit-Sync (NTP) prüfen.

# “War Story”: Das “Double-Hop” Dilemma

Ein Admin wollte via PSRemoting ein Skript auf einem Client ausführen, das wiederum Daten von einem Fileserver ziehen sollte. Das Ergebnis: Das Skript auf dem Client schlug mit “Access Denied” auf den Fileserver fehl. Die Ursache: Kerberos erlaubt standardmäßig keine Weitergabe der Credentials über zwei Hops (Admin -> Client -> Fileserver). Lösung: Nutzung von CredSSP (Unsicher!) oder besser: Delegierung via GPO oder gMSAs.

# 6. Monitoring & Alerting

Remote-Zugriffe auditieren.

# Event Logs

• Quelle: Microsoft-Windows-WinRM.
• Event ID 91: Neue Verbindung aufgebaut.
• Event ID 142: Fehler bei der Authentifizierung.

# 7. Fazit & Empfehlung

WinRM ist das Herzstück des modernen Windows-Managements.

• Empfehlung: Nutzen Sie HTTPS-Listener für alle Verbindungen über Netzwerkgrenzen hinweg.
• Wahl: Verwenden Sie Invoke-Command statt interaktiver Enter-PSSession, um Ergebnisse als Objekte zurückzuerhalten und diese lokal weiterzuverarbeiten.

# Anhang: Cheatsheet

# Referenzen

• Microsoft Learn: PowerShell Remoting Security Considerations
• WinRM TrustedHosts Documentation
• Just Enough Administration (JEA) Guide