Ausgangslage: WinRM ist oft offen genug, bis es auffällt

WinRM und PowerShell Remoting sind für Windows-Betrieb keine exotischen Sonderwege. Sie werden für Serververwaltung, Inventarisierung, Health Checks, Build-Prozesse, Patch-Automation, Exchange-, Hyper-V-, Failover-Cluster- und AD-nahe Administration genutzt. In einer sauberen Domäne ist das kein Problem. Problematisch wird es, wenn alte Management-Werkzeuge, Workgroup-Szenarien oder schnelle Troubleshooting-Änderungen die Baseline aufweichen.

Typische Muster sind Basic Authentication am WinRM-Client oder -Service, AllowUnencrypted = true, breite TrustedHosts, lokal gespeicherte Admin-Credentials, dauerhafte Credential-Dateien in Profilen oder Skripte, die bei Authentifizierungsproblemen auf den nächsten Fallback umgestellt wurden. Der Betrieb merkt das oft nicht sofort, weil Remoting weiter funktioniert. Das Risiko entsteht leise: ein administrativer Kanal akzeptiert wieder Passwort-basierte Authentifizierungspfade, die in einer AD-Umgebung nicht benötigt werden sollten.

Basic Auth ist nicht automatisch gleichbedeutend mit Klartext über das Netz, wenn HTTPS korrekt erzwungen wird. Genau darin liegt aber die Falle. Die Sicherheit hängt dann vollständig an TLS, Zertifikatsprüfung, Listener-Konfiguration, Client-Verhalten und daran, dass niemand später doch wieder HTTP oder unverschlüsselte WinRM-Pfade zulässt. Für domänengebundene Windows-Systeme ist das unnötig fragil.

Das Ziel ist deshalb nicht, WinRM abzuschalten. Das Ziel ist ein kontrollierter Remote-Administrationspfad: Kerberos oder sauber begründete Zertifikatsauthentifizierung, keine Basic-Fallbacks, kein unverschlüsselter Transport, keine breit gespeicherten privilegierten Zugangsdaten und klare Sicht auf Ausnahmen.

Zielbild: Kerberos zuerst, Basic aus

Ein belastbares Zielbild hat konkrete Eigenschaften:

  1. WinRM Basic Auth ist auf Client und Service deaktiviert. Systeme bieten Basic nicht an und nutzen es auch nicht als Client-Fallback.
  2. Unverschlüsselte WinRM-Verbindungen sind verboten. AllowUnencrypted bleibt für Client und Service auf false.
  3. Domain-Systeme nutzen Kerberos. Innerhalb der Domäne ist Kerberos der Standardpfad für PowerShell Remoting und WinRM-basierte Verwaltung.
  4. HTTPS ist Ausnahme oder Zusatzschutz, nicht Ausrede für Basic. Wenn HTTPS für Nicht-Domain- oder Cross-Forest-Szenarien nötig ist, werden Zertifikate und Namen sauber gepflegt.
  5. TrustedHosts ist leer oder eng begrenzt. Wildcards wie * sind kein Betriebsstandard.
  6. Privilegierte Credentials werden nicht dauerhaft abgelegt. Keine Admin-Passwörter in Skripten, Profilen, cmdkey, Task-Definitionen oder exportierten Credential-Dateien.
  7. Ausnahmen haben Owner und Ablaufdatum. Legacy-Management bekommt keinen dauerhaften Freifahrtschein.

Der praktische Zielzustand: WinRM bleibt als Admin-Werkzeug nutzbar, aber ein System kann nicht heimlich auf Basic Auth oder unverschlüsselte Remoting-Pfade zurückfallen.

Umsetzung: erst sichtbar machen, dann per GPO festziehen

1) WinRM-Zustand lesen, nicht raten

Starte mit einer lesenden Bestandsaufnahme auf Admin-Workstations, Management-Servern, Domain Controllern und repräsentativen Memberservern. Wichtig sind beide Seiten: der WinRM-Service auf verwalteten Systemen und der WinRM-Client auf Admin- und Automationssystemen.

Ein lokaler Schnellcheck:

$paths = @(
  'WSMan:\localhost\Service\Auth\Basic',
  'WSMan:\localhost\Service\AllowUnencrypted',
  'WSMan:\localhost\Client\Auth\Basic',
  'WSMan:\localhost\Client\AllowUnencrypted',
  'WSMan:\localhost\Client\TrustedHosts'
)

foreach ($path in $paths) {
  Get-Item -LiteralPath $path | Select-Object PSPath, Value
}

Für eine Projektaufnahme gehört das zentralisiert: per PowerShell Remoting, Config Management, EDR-Inventar oder GPO-Resultant-Set. Ziel ist eine Liste von Systemen, auf denen Basic Auth oder unverschlüsselte WinRM-Pfade erlaubt sind, plus der GPO oder lokalen Änderung, die das verursacht.

Prüfe zusätzlich, welche Listener existieren:

Get-ChildItem WSMan:\localhost\Listener |
  Select-Object PSChildName, Keys, Transport

HTTP-Listener sind in Domain-Netzen nicht automatisch falsch, wenn Kerberos genutzt und der Zugriff sauber begrenzt wird. Sie dürfen aber nicht mit Basic Auth und AllowUnencrypted kombiniert werden. HTTPS-Listener sind nur dann besser, wenn Zertifikate, Namen und Clientprüfung wirklich stimmen.

2) GPO für Client und Service setzen

Lege eine dedizierte Computer-GPO oder einen klaren Abschnitt in der Windows-Hardening-Baseline an. Die relevanten Einstellungen liegen unter:

Computer Configuration
  Administrative Templates
    Windows Components
      Windows Remote Management (WinRM)

Für den WinRM Client:

  • Allow Basic authentication: Disabled.
  • Allow unencrypted traffic: Disabled.
  • Trusted Hosts: Not configured oder eine enge, dokumentierte Liste.

Für den WinRM Service:

  • Allow Basic authentication: Disabled.
  • Allow unencrypted traffic: Disabled.
  • Allow remote server management through WinRM: nur mit bewusstem Scope für IPv4/IPv6-Filter, wenn die Baseline WinRM zentral aktiviert.

Wichtig: Viele Projekte setzen nur die Service-Seite. Dann akzeptieren Server zwar kein Basic, aber Admin-Workstations oder Management-Server dürfen es weiterhin gegen andere Ziele verwenden. Für AD-Hardening ist das zu kurz gedacht. Client- und Service-Seite gehören zusammen.

3) Zugriff auf WinRM nicht netzweit offen lassen

Authentifizierung ist nur eine Ebene. Wenn WinRM von jedem Clientnetz auf Domain Controller, Management-Server oder alle Server erreichbar ist, bleibt der Admin-Kanal zu breit.

Prüfe und begrenze:

  • Windows Defender Firewall-Regeln für WinRM auf Zielsystemen.
  • Netzwerk-Firewall oder ACLs zwischen Client-, Server-, PAW-, Jump-Host- und Management-Netzen.
  • Zugriff auf Domain Controller separat von normalen Memberservern.
  • VPN- und Remote-Access-Pfade auf Admin-Protokolle.

Ein brauchbares Ziel ist nicht "WinRM von überall, weil Kerberos stark ist". Besser ist: WinRM nur aus definierten Admin-Netzen, von PAWs, Jump Hosts oder Management-Systemen, mit getrennten Regeln für Tier-0-Systeme.

4) Kerberos-Probleme nicht mit Basic kaschieren

Basic Auth wird häufig aktiviert, weil Kerberos nicht sauber funktioniert. Das ist ein Symptom, kein Grund für einen dauerhaften Fallback.

Typische Ursachen:

  • Zugriff per IP-Adresse statt FQDN.
  • fehlende oder falsche SPNs.
  • DNS- oder Namensauflösungsprobleme.
  • Cross-Forest-Szenarien ohne saubere Trust- oder Authentifizierungsplanung.
  • Workgroup-Server ohne Zertifikats- und HTTPS-Konzept.
  • Tools, die aus Bequemlichkeit TrustedHosts und Basic empfehlen.

Die bessere Behebung ist, den Authentifizierungspfad zu reparieren: FQDN nutzen, DNS korrigieren, SPNs prüfen, Trusts sauber planen oder für echte Nicht-Domain-Szenarien HTTPS mit Zertifikaten und eng begrenzten Zielen verwenden. Basic Auth sollte nicht der Standard-Workaround für kaputte Namens- oder Kerberos-Hygiene sein.

5) Gespeicherte WinRM-Credentials aufräumen

Wenn Basic Auth verschwindet, fallen oft Skripte auf, die Credentials dauerhaft speichern. Das ist gut. Diese Stellen sind ohnehin riskant.

Prüfe besonders:

  • cmdkey-Einträge auf Admin- und Management-Systemen.
  • geplante Aufgaben mit statisch hinterlegten privilegierten Konten.
  • PowerShell-Skripte mit ConvertTo-SecureString und hart codierten Strings.
  • exportierte PSCredential-Dateien in Benutzerprofilen oder Shares.
  • CI/CD-, RMM-, Monitoring- oder Backup-Jobs mit wiederverwendeten Domain-Admin-Credentials.
  • Runbooks, die CredSSP aktivieren, um Delegation schnell zu lösen.

Saubere Alternativen hängen vom Einsatzzweck ab: gMSA für Dienste, dedizierte niedrig privilegierte Servicekonten, SecretManagement oder Vault-Anbindung für Automationen, Just Enough Administration für eingeschränkte Admin-Aufgaben, Kerberos Constrained Delegation nur mit sauberem Scope und Break-Glass-Konten für echte Notfälle. Entscheidend ist: keine dauerhaft abgelegten Tier-0- oder Domain-Admin-Passwörter als Betriebsabkürzung.

6) Pilotieren statt global abbrechen

Ein sinnvoller Rollout:

  1. Admin-Workstations, Management-Server, Domain Controller und Standardserver inventarisieren.
  2. Systeme mit Basic Auth, AllowUnencrypted oder breiten TrustedHosts markieren.
  3. Abhängige Tools und Jobs identifizieren.
  4. GPO in einer Pilot-OU für Client und Service setzen.
  5. Standard-Remoting mit Kerberos testen.
  6. Nicht-Domain- oder Cross-Forest-Szenarien separat mit HTTPS und Zertifikaten prüfen.
  7. Gespeicherte Credentials und Legacy-Ausnahmen bereinigen.
  8. Monitoring auf WinRM-Konfigurationsdrift und fehlgeschlagene Remoting-Logons aktivieren.

Der Pilot sollte nicht nur einen Testserver enthalten. Mindestens ein Admin-System, ein Management-Server, ein normaler Memberserver und ein Tier-0-Ziel sollten vertreten sein. Sonst wird nur die halbe Realität getestet.

Vorteile

  • Weniger Passwort-Fallbacks: WinRM kann nicht still auf Basic Auth ausweichen.
  • Bessere AD-Hygiene: Kerberos, Namen, SPNs und Trusts müssen sauber funktionieren statt umgangen zu werden.
  • Weniger Credential-Ablage: Alte Skripte und Jobs mit gespeicherten Admin-Passwörtern werden sichtbar.
  • Klarerer Tier-0-Schutz: Domain Controller und Management-Systeme bekommen enger kontrollierte Admin-Pfade.
  • Einfach auditierbar: GPO, WSMan-Werte, Listener, Firewall-Regeln und Ausnahmen lassen sich konkret prüfen.
  • Geringe technische Komplexität: Die wichtigsten Kontrollen sind Windows-Bordmittel.

Nachteile und Grenzen

  • Legacy-Tools können ausfallen: Alte RMM-, Backup-, Monitoring- oder Appliance-Integrationen nutzen manchmal Basic oder breite TrustedHosts.
  • Cross-Forest und Workgroup brauchen Planung: Ohne Kerberos-Vertrauen sind HTTPS, Zertifikate und Zielnamen sauber zu betreiben.
  • WinRM bleibt ein Admin-Kanal: Das Deaktivieren von Basic ersetzt keine Rollen-, Gruppen-, Firewall- oder PAW-Hygiene.
  • Kerberos-Fehler werden sichtbar: DNS-, SPN- und Namensprobleme müssen behoben werden statt per Fallback zu verschwinden.
  • Gespeicherte Credentials verschwinden nicht automatisch: Skripte, Scheduled Tasks und Runbooks brauchen eigene Bereinigung.
  • HTTPS ist kein Freifahrtschein: Falsche Zertifikatsprüfung, schwache Prozesse oder breite Ausnahmen können das Zielbild wieder aufweichen.

Typische Stolperfallen

  • Nur den WinRM-Service härten: Der Client darf dann weiter Basic gegen andere Ziele nutzen.
  • AllowUnencrypted vergessen: Basic aus, aber unverschlüsselte Pfade erlaubt, ist keine saubere Baseline.
  • **TrustedHosts = * stehen lassen:** Damit wird die Zielprüfung für viele Remoting-Szenarien zu breit.
  • Basic durch CredSSP ersetzen: CredSSP delegiert Credentials und ist kein pauschaler Hardening-Ersatz.
  • Mit IP-Adressen testen: Dadurch wird Kerberos umgangen oder scheitert, obwohl der eigentliche FQDN-Pfad funktionieren würde.
  • Admin-Workstations auslassen: Genau dort entstehen häufig Client-Fallbacks und gespeicherte Credentials.
  • Ausnahmen nicht befristen: Ein Legacy-Tool bleibt sonst jahrelang der Grund für eine schwache Baseline.
  • Domain Controller wie normale Server behandeln: Tier-0-Ziele brauchen engere Erreichbarkeit und strengere Auswertung.

Projekt-Checkliste

  • [ ] WinRM-Client- und Service-Werte für Basic Auth, AllowUnencrypted und TrustedHosts inventarisieren.
  • [ ] WinRM-Listener, Firewall-Regeln und erreichbare Netze für Admin-, Management- und Tier-0-Systeme prüfen.
  • [ ] GPO für WinRM Client und WinRM Service mit Basic Auth disabled und unverschlüsseltem Traffic disabled definieren.
  • [ ] Admin-Workstations und Management-Server explizit in den Scope aufnehmen.
  • [ ] Domain Controller und andere Tier-0-Systeme separat bewerten.
  • [ ] Kerberos-Pfade mit FQDN, DNS und SPNs testen, bevor Basic-Ausnahmen akzeptiert werden.
  • [ ] Cross-Forest-, Workgroup- und Appliance-Szenarien separat mit HTTPS, Zertifikaten und engen Zielgruppen planen.
  • [ ] Breite TrustedHosts-Einträge entfernen oder auf dokumentierte Einzelziele reduzieren.
  • [ ] Gespeicherte privilegierte Credentials in Skripten, cmdkey, Scheduled Tasks, Runbooks und Shares bereinigen.
  • [ ] Legacy-Ausnahmen mit Owner, Grund, Systemen, Ablaufdatum und Review-Zyklus dokumentieren.
  • [ ] Positive Tests für Kerberos-Remoting und negative Tests für Basic Auth durchführen.
  • [ ] Monitoring auf WinRM-Konfigurationsdrift, ungewöhnliche Remoting-Fehler und neue Ausnahmen einrichten.