Ausgangslage: WinRM ist oft offen genug, bis es auffaellt

WinRM und PowerShell Remoting sind fuer Windows-Betrieb keine exotischen Sonderwege. Sie werden fuer Serververwaltung, Inventarisierung, Health Checks, Build-Prozesse, Patch-Automation, Exchange-, Hyper-V-, Failover-Cluster- und AD-nahe Administration genutzt. In einer sauberen Domaene ist das kein Problem. Problematisch wird es, wenn alte Management-Werkzeuge, Workgroup-Szenarien oder schnelle Troubleshooting-Aenderungen 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 naechsten 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 benoetigt werden sollten.

Basic Auth ist nicht automatisch gleichbedeutend mit Klartext ueber das Netz, wenn HTTPS korrekt erzwungen wird. Genau darin liegt aber die Falle. Die Sicherheit haengt dann vollstaendig an TLS, Zertifikatspruefung, Listener-Konfiguration, Client-Verhalten und daran, dass niemand spaeter doch wieder HTTP oder unverschluesselte WinRM-Pfade zulaesst. Fuer domaenengebundene Windows-Systeme ist das unnoetig fragil.

Das Ziel ist deshalb nicht, WinRM abzuschalten. Das Ziel ist ein kontrollierter Remote-Administrationspfad: Kerberos oder sauber begruendete Zertifikatsauthentifizierung, keine Basic-Fallbacks, kein unverschluesselter 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. Unverschluesselte WinRM-Verbindungen sind verboten. AllowUnencrypted bleibt fuer Client und Service auf false.
  3. Domain-Systeme nutzen Kerberos. Innerhalb der Domaene ist Kerberos der Standardpfad fuer PowerShell Remoting und WinRM-basierte Verwaltung.
  4. HTTPS ist Ausnahme oder Zusatzschutz, nicht Ausrede fuer Basic. Wenn HTTPS fuer Nicht-Domain- oder Cross-Forest-Szenarien noetig 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-Passwoerter 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 unverschluesselte Remoting-Pfade zurueckfallen.

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 repraesentativen 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
}

Fuer eine Projektaufnahme gehoert das zentralisiert: per PowerShell Remoting, Config Management, EDR-Inventar oder GPO-Resultant-Set. Ziel ist eine Liste von Systemen, auf denen Basic Auth oder unverschluesselte WinRM-Pfade erlaubt sind, plus der GPO oder lokalen Aenderung, die das verursacht.

Pruefe zusaetzlich, 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 duerfen aber nicht mit Basic Auth und AllowUnencrypted kombiniert werden. HTTPS-Listener sind nur dann besser, wenn Zertifikate, Namen und Clientpruefung wirklich stimmen.

2) GPO fuer 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)

Fuer den WinRM Client:

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

Fuer den WinRM Service:

  • Allow Basic authentication: Disabled.
  • Allow unencrypted traffic: Disabled.
  • Allow remote server management through WinRM: nur mit bewusstem Scope fuer 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 duerfen es weiterhin gegen andere Ziele verwenden. Fuer AD-Hardening ist das zu kurz gedacht. Client- und Service-Seite gehoeren 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.

Pruefe und begrenze:

  • Windows Defender Firewall-Regeln fuer 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 ueberall, weil Kerberos stark ist". Besser ist: WinRM nur aus definierten Admin-Netzen, von PAWs, Jump Hosts oder Management-Systemen, mit getrennten Regeln fuer Tier-0-Systeme.

4) Kerberos-Probleme nicht mit Basic kaschieren

Basic Auth wird haeufig aktiviert, weil Kerberos nicht sauber funktioniert. Das ist ein Symptom, kein Grund fuer einen dauerhaften Fallback.

Typische Ursachen:

  • Zugriff per IP-Adresse statt FQDN.
  • fehlende oder falsche SPNs.
  • DNS- oder Namensaufloesungsprobleme.
  • 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 pruefen, Trusts sauber planen oder fuer echte Nicht-Domain-Szenarien HTTPS mit Zertifikaten und eng begrenzten Zielen verwenden. Basic Auth sollte nicht der Standard-Workaround fuer kaputte Namens- oder Kerberos-Hygiene sein.

5) Gespeicherte WinRM-Credentials aufraeumen

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

Pruefe besonders:

  • cmdkey-Eintraege 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 loesen.

Saubere Alternativen haengen vom Einsatzzweck ab: gMSA fuer Dienste, dedizierte niedrig privilegierte Servicekonten, SecretManagement oder Vault-Anbindung fuer Automationen, Just Enough Administration fuer eingeschraenkte Admin-Aufgaben, Kerberos Constrained Delegation nur mit sauberem Scope und Break-Glass-Konten fuer echte Notfaelle. Entscheidend ist: keine dauerhaft abgelegten Tier-0- oder Domain-Admin-Passwoerter als Betriebsabkuerzung.

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. Abhaengige Tools und Jobs identifizieren.
  4. GPO in einer Pilot-OU fuer Client und Service setzen.
  5. Standard-Remoting mit Kerberos testen.
  6. Nicht-Domain- oder Cross-Forest-Szenarien separat mit HTTPS und Zertifikaten pruefen.
  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 Realitaet getestet.

Vorteile

  • Weniger Passwort-Fallbacks: WinRM kann nicht still auf Basic Auth ausweichen.
  • Bessere AD-Hygiene: Kerberos, Namen, SPNs und Trusts muessen sauber funktionieren statt umgangen zu werden.
  • Weniger Credential-Ablage: Alte Skripte und Jobs mit gespeicherten Admin-Passwoertern 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 pruefen.
  • Geringe technische Komplexitaet: Die wichtigsten Kontrollen sind Windows-Bordmittel.

Nachteile und Grenzen

  • Legacy-Tools koennen 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 muessen 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 Zertifikatspruefung, schwache Prozesse oder breite Ausnahmen koennen das Zielbild wieder aufweichen.

Typische Stolperfallen

  • Nur den WinRM-Service haerten: Der Client darf dann weiter Basic gegen andere Ziele nutzen.
  • AllowUnencrypted vergessen: Basic aus, aber unverschluesselte Pfade erlaubt, ist keine saubere Baseline.
  • **TrustedHosts = * stehen lassen:** Damit wird die Zielpruefung fuer 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 wuerde.
  • Admin-Workstations auslassen: Genau dort entstehen haeufig Client-Fallbacks und gespeicherte Credentials.
  • Ausnahmen nicht befristen: Ein Legacy-Tool bleibt sonst jahrelang der Grund fuer 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 fuer Basic Auth, AllowUnencrypted und TrustedHosts inventarisieren.
  • [ ] WinRM-Listener, Firewall-Regeln und erreichbare Netze fuer Admin-, Management- und Tier-0-Systeme pruefen.
  • [ ] GPO fuer WinRM Client und WinRM Service mit Basic Auth disabled und unverschluesseltem 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-Eintraege 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 fuer Kerberos-Remoting und negative Tests fuer Basic Auth durchfuehren.
  • [ ] Monitoring auf WinRM-Konfigurationsdrift, ungewoehnliche Remoting-Fehler und neue Ausnahmen einrichten.