WinRM innerhalb der Domain

Bei jeder WinRM-Verbindung bevorzugt TLSPilot HTTPS auf Port 5986 mit vollständiger Prüfung des Listener-Zertifikats: Die Kette muss bei einem Root-Zertifikat enden, dem der Management-Host vertraut, und das Zertifikat muss für den im Deployment eingegebenen Hostnamen ausgestellt sein. Lehnt Port 5986 die Verbindung ab oder antwortet nicht, oder schlägt die Zertifikatsprüfung oder der TLS-Handshake fehl, verwendet TLSPilot HTTP auf Port 5985 mit Negotiate-Nachrichtenverschlüsselung (Kerberos oder NTLM). Basic-Authentifizierung und unverschlüsseltes WinRM werden nie verwendet. Eine fehlgeschlagene Anmeldung über HTTPS führt nicht zum Rückfall auf HTTP.

TLSPilot merkt sich das Ergebnis für jeden Zielhost. Jeder Lauf, den Sie selbst starten, also Deploy…, ein Health-Check oder Test (dry run)…, in der Desktop Admin Console oder in der WebUI, prüft HTTPS auf Port 5986 erneut und aktualisiert das gemerkte Ergebnis. Ein neu eingerichteter HTTPS-Listener wird deshalb beim nächsten Lauf verwendet, den Sie starten. Der tägliche Zyklus verwendet das gemerkte Ergebnis; die Transportzeile zeigt dann, wann es geprüft wurde, zum Beispiel WinRM over HTTPS (5986) (checked 07:02).

Das Deploy-Log, das Ergebnis des Deployments, der Dry Run und der Tab Health & History zeigen den verwendeten Transport für jeden Windows-Deployment-Typ auf einer eigenen Zeile: WinRM over HTTPS (5986) oder WinRM over HTTP (5985), nach einem Rückfall mit dem Grund, zum Beispiel HTTPS on 5986 not used: connection refused., timed out., certificate not trusted., certificate name does not match <host>. oder TLS handshake failed. Die Desktop Admin Console, die WebUI und der PDF-Bericht zeigen dieselben Informationen. Exchange-Deployments sind davon ausgenommen: TLSPilot verbindet sich mit dem Exchange-Endpunkt http://<server FQDN>/PowerShell/ über Kerberos, siehe Kapitel Exchange.

Sind der Management-Host und das Ziel Mitglieder derselben Active-Directory-Domain oder vertrauender Domains, wird ein Ziel ohne HTTPS-Listener mit Kerberos über HTTP (Port 5985) erreicht. Der Datenverkehr wird durch Kerberos verschlüsselt.

1. Aktivieren Sie WinRM auf dem Ziel in einer PowerShell mit erhöhten Rechten: Enable-PSRemoting -Force. Auf Windows Server ist WinRM meist bereits aktiviert.
2. Erlauben Sie in der Windows-Firewall des Ziels TCP 5985 vom Management-Host. Best Practice: Verwenden Sie für beide Schritte eine Gruppenrichtlinie.
3. Erstellen Sie ein eigenes Dienstkonto oder ein Group Managed Service Account, siehe Kapitel Managed Service Accounts verwenden, und fügen Sie es nur der lokalen Gruppe Administrators des Ziels hinzu. Verwenden Sie keinen Domain-Administrator.
4. Geben Sie den Zielhost als FQDN ein, zum Beispiel web01.example.com, da Kerberos den Namen des Computerkontos braucht. IP-Adressen fallen auf NTLM zurück und scheitern in den meisten Konfigurationen.
5. Testen Sie die Verbindung vom Management-Host aus: Test-WSMan web01.example.com -Authentication Kerberos, und führen Sie dann im Deployment Test (dry run)… aus.

Der Tab Helper eines Windows-Deployments listet die benötigten Berechtigungen und die WinRM-Konfiguration für dieses Ziel auf, auf dem Management-Host und auf dem Ziel, und hält fest, dass TLSPilot sich zuerst über HTTPS (TCP 5986) und sonst über HTTP (TCP 5985) mit Negotiate-Verschlüsselung verbindet, siehe Abbildung Tab Helper eines Windows-Deployments mit der WinRM-Konfiguration.