02.05.2025
2122
29
0WinRM über https
Hallo,
ich würde gerne WinRM nur über https (Port 5986) erlauben. Dazu bräuchte ich eure Hilfe, da meine Konfiguration nicht funktioniert.
Befehl:
Ergebnis:
Sobald ich von meinem Server auf das Zielsystem über Port 5986 zugreifen will, kommt die Meldung:
Beides Windows 2022 Server
Jemand eine Idee?
Im Voraus besten Dank
Peter
ich würde gerne WinRM nur über https (Port 5986) erlauben. Dazu bräuchte ich eure Hilfe, da meine Konfiguration nicht funktioniert.
Befehl:
winrm get winrm/configErgebnis:
Config
MaxEnvelopeSizekb = 500
MaxTimeoutms = 60000
MaxBatchItems = 32000
MaxProviderRequests = 4294967295
Client
NetworkDelayms = 5000
URLPrefix = wsman
AllowUnencrypted = false
Auth
Basic = true
Digest = true
Kerberos = true
Negotiate = true
Certificate = true
CredSSP = false
DefaultPorts
HTTP = 5985
HTTPS = 5986
TrustedHosts
Service
RootSDDL = O:NSG:BAD:P(A;;GA;;;BA)(A;;GR;;;IU)S:P(AU;FA;GA;;;WD)(AU;SA;GXGW;;;WD)
MaxConcurrentOperations = 4294967295
MaxConcurrentOperationsPerUser = 1500
EnumerationTimeoutms = 240000
MaxConnections = 300
MaxPacketRetrievalTimeSeconds = 120
AllowUnencrypted = false
Auth
Basic = false
Kerberos = true
Negotiate = true
Certificate = true
CredSSP = false
CbtHardeningLevel = Relaxed
DefaultPorts
HTTP = 5985
HTTPS = 5986
IPv4Filter = *
IPv6Filter = *
EnableCompatibilityHttpListener = false
EnableCompatibilityHttpsListener = false
CertificateThumbprint = de 6d 6b 50 e2 ba 4a ce a1 5c 6e 09 35 96 6d 181a 48 57 0e
AllowRemoteAccess = true
Winrs
AllowRemoteShellAccess = true
IdleTimeout = 7200000
MaxConcurrentUsers = 2147483647
MaxShellRunTime = 2147483647
MaxProcessesPerShell = 2147483647
MaxMemoryPerShellMB = 2147483647
MaxShellsPerUser = 2147483647Sobald ich von meinem Server auf das Zielsystem über Port 5986 zugreifen will, kommt die Meldung:
The client cannot connect to the destination specified in the request. Verify that the
service on the destination is running and is accepting requests. Consult the logs and documentation for the WS-Management service running on the destination, most commonly IIS or WinRM. If the destination is the WinRM service, run the following command on the destination to analyze and configure the WinRM service: "winrm quickconfig". Beides Windows 2022 Server
Jemand eine Idee?
Im Voraus besten Dank
Peter
Kommentieren
Teilen
Auf Facebook teilen
Auf X (Twitter) teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 672704
Url: https://administrator.de/forum/winrm-ueber-https-672704.html
Ausgedruckt am: 28.07.2025 um 05:07 Uhr
29 Kommentare
Neuester Kommentar
Hi,
Zertifikat ist vorhanden. Den Artikel hatte ich mir auch schon durchgelesen.
Zertifikat ist vorhanden. Den Artikel hatte ich mir auch schon durchgelesen.
Passt denn das Zertifikat( Winrm enumerate winrm/config/listener) ?
Ist der Port 5986 eingehend frei? Sprichst du den Server via IP oder FQDN an?
Ist der Port 5986 eingehend frei? Sprichst du den Server via IP oder FQDN an?
Ja, das Zertifkat und ...listener haben den gleichen Fingerabdruck
Port 5986:
Test-NetConnection Servename -Port 5986 -->TcpTestSucceeded : True
Die Windows Firewall ist nicht konfiguriert.
Wenn man irgendwo im Log etwas lesen könnte, wäre das schon hilfreich.
Port 5986:
Test-NetConnection Servename -Port 5986 -->TcpTestSucceeded : True
Die Windows Firewall ist nicht konfiguriert.
Wenn man irgendwo im Log etwas lesen könnte, wäre das schon hilfreich.
Wie @Delta9 schon sagte:
1) Ist der Listener auf HTTPs vorbereitet?
2) Passt der Fingerprint des Zertifikates im Listener auch auf den Finngerprint des Zertifikates im lokalen Computerstore?
3) Angesprochen wird über FQDN, der CN im Zertifikat muss auf die WinRM Anfrage matchen.
Ich hab das so am Laufen, ich meine mich zur erinnern, dass es bestimmte Voraussetzungen für das Zertifikat gab, hast du das geprüft?
Ansonsten mal ein Test-Netconnection -Computername "Name des Computers" -Port 5986 per Powershell abfeuern und sicher gehen, dass 5896 eingehend auf ist.
1) Ist der Listener auf HTTPs vorbereitet?
2) Passt der Fingerprint des Zertifikates im Listener auch auf den Finngerprint des Zertifikates im lokalen Computerstore?
3) Angesprochen wird über FQDN, der CN im Zertifikat muss auf die WinRM Anfrage matchen.
Ich hab das so am Laufen, ich meine mich zur erinnern, dass es bestimmte Voraussetzungen für das Zertifikat gab, hast du das geprüft?
Ansonsten mal ein Test-Netconnection -Computername "Name des Computers" -Port 5986 per Powershell abfeuern und sicher gehen, dass 5896 eingehend auf ist.
zu 1: das Ergebnis hatte ich anfangs gepostet. Sieht für mich "Vorbereitet" aus.
zu 2: ja
zu 3: Im Zertifikat unter Subject steht der FQDN
"bestimmte Voraussetzungen" weiß ich jetzt nicht
Test-NetConnection Servename -Port 5986 -->TcpTestSucceeded : True
zu 2: ja
zu 3: Im Zertifikat unter Subject steht der FQDN
"bestimmte Voraussetzungen" weiß ich jetzt nicht
Test-NetConnection Servename -Port 5986 -->TcpTestSucceeded : True
Hey,
was kommt den hierbei raus? Mein Bauchgefühl sagt mir das Zertifikat hat einen anderen allgemeinen Namen als das, was du anwählst..
Schon mal die Quickconfig laufen lassen?
Gruß
was kommt den hierbei raus? Mein Bauchgefühl sagt mir das Zertifikat hat einen anderen allgemeinen Namen als das, was du anwählst..
winrm enumerate winrm/config/listener winrm quickconfig -transport:https
Hi,
zu 1:
das will ich gar nicht auschliessen. Das Zertifikat gibt es schon länger. Niemand weiß, wozu es gebraucht wurde. Nach was muss ich genau schauen? Der Fingerabdruck ist der selbe.
zu 2:
ja. https ist enabled
Gruß
zu 1:
das will ich gar nicht auschliessen. Das Zertifikat gibt es schon länger. Niemand weiß, wozu es gebraucht wurde. Nach was muss ich genau schauen? Der Fingerabdruck ist der selbe.
zu 2:
ja. https ist enabled
Gruß
Hey,
du musst den Allgemeinen Namen (Common Name) vom Zertifikat prüfen. Die SAN (Subject Alternative Names) werden beim WinRM over HTTPS nicht beachtet (afaik).
Gruß
du musst den Allgemeinen Namen (Common Name) vom Zertifikat prüfen. Die SAN (Subject Alternative Names) werden beim WinRM over HTTPS nicht beachtet (afaik).
gci Cert:\LocalMachine\MyGruß
1
Der CN ist der FQDN.
Von meinem Server führe ich diesen Befehl aus:
New-PSsession -ComputerName CN -port 5986
Von meinem Server führe ich diesen Befehl aus:
New-PSsession -ComputerName CN -port 5986
Hey,
hast du beim Client-System mal das Ziel als Trusted Host hinterlegt? Nicht das "nur" die Kerberos Anmeldung nicht klappt..
admx.help/?Category=Windows_10_2016&Policy=Microsoft.Policie ...
Alternativ an der selbenstelle mal "Unverschlüsselten Verkehr" vom Client aus zulassen. Selbiges auch am Server erlauben und dann bitte ohne SSL versuchen. Geht es grundlegend ohne Verschlüsselung mit Kerberos?
Gruß
hast du beim Client-System mal das Ziel als Trusted Host hinterlegt? Nicht das "nur" die Kerberos Anmeldung nicht klappt..
admx.help/?Category=Windows_10_2016&Policy=Microsoft.Policie ...
Alternativ an der selbenstelle mal "Unverschlüsselten Verkehr" vom Client aus zulassen. Selbiges auch am Server erlauben und dann bitte ohne SSL versuchen. Geht es grundlegend ohne Verschlüsselung mit Kerberos?
New-PSSession -ComputerName FQDN -Authentication Kerberos -Debug -VerboseGruß
Ohne SSL funktioniert der Zugriff. So nutzen wir es seit Jahren.
Zitat von @BPeter:
Von meinem Server führe ich diesen Befehl aus:
New-PSsession -ComputerName CN -port 5986
Da fehlt der Parameter -UseSSL, wenn du https nutzen willst, denn Standardmäßig versucht es New-PSSession ohne den Parameter nur über http und das schlägt dann dementsprechend auf den https Port fehl ....Von meinem Server führe ich diesen Befehl aus:
New-PSsession -ComputerName CN -port 5986
learn.microsoft.com/de-de/powershell/module/microsoft.powershell ...
Gibt an, dass dieses Cmdlet das SSL-Protokoll verwendet, um eine Verbindung mit dem Remotecomputer herzustellen. Standardmäßig wird SSL nicht verwendet.
Zertifikatsvoraussetzungen sind noch folgende:
- Genutzter FQDN im CN und als SAN vorhanden (sollte heutzutage immer der Fall sein, denn neuere Implementationen schauen nur noch auf die SANs und nicht mehr in den CN)
- KeyUsage: digitalSignature
- extendedKeyUsage: serverAuth
- Zertifikat darf nicht selbstsigniert sein sondern muss von einer auf dem Computer verrauenswürdigen markierten CA stammen!
2
Hi Biberman
das war die Lösung, der Parameter -useSSL bei New-PSsession
Vielen Dank an alle, die dazu beigetragen haben
Peter
das war die Lösung, der Parameter -useSSL bei New-PSsession
Vielen Dank an alle, die dazu beigetragen haben
Peter
👍 Keine Ursache.
Hallo nochmal,
leider bin ich noch auf ein Problem gestoßen. 2 unserer Domain Controller haben bereits ein Zertifikat zur Authentifizierung. In diesem steht NICHT der Hostname bei Common Name sondern ein Loadbalancer. Das Problem das ich jetzt habe, ist, dass bei der Aktivierung von https (winrm quickconfig -transport:https) die Fehlermeldung kommt, dass CN und Hostname nicht übereinstimmen. Wenn ich unser WinRM Zertifikat, das auf allen anderen Servern läuft, auf den DC's hinzufüge, funktionieren andere Systeme nicht mehr, das sie den Loadbalancer in der Konfig haben.
Jemand eine Idee, wie ich das hinbekommen kann, ohne den Loadbalancer zu entfernen?
VG
Peter
leider bin ich noch auf ein Problem gestoßen. 2 unserer Domain Controller haben bereits ein Zertifikat zur Authentifizierung. In diesem steht NICHT der Hostname bei Common Name sondern ein Loadbalancer. Das Problem das ich jetzt habe, ist, dass bei der Aktivierung von https (winrm quickconfig -transport:https) die Fehlermeldung kommt, dass CN und Hostname nicht übereinstimmen. Wenn ich unser WinRM Zertifikat, das auf allen anderen Servern läuft, auf den DC's hinzufüge, funktionieren andere Systeme nicht mehr, das sie den Loadbalancer in der Konfig haben.
Jemand eine Idee, wie ich das hinbekommen kann, ohne den Loadbalancer zu entfernen?
VG
Peter
Den Thumbprint des passenden Certs bei der Aktivierung angeben ...Oder hostname im anderen Cert als weiteren SAN hinterlegen.
Vielleicht einfach saubere Zertifikate für die Domaincontroller ausstellen?
Oder halt für die betroffenen Maschinen WinRM ohne SSL.
Gruß
Oder halt für die betroffenen Maschinen WinRM ohne SSL.
Gruß
Zitat von @BiberMan:
Den Thumbprint des passenden Certs bei der Aktivierung angeben ...Oder hostname im anderen Cert als weiteren SAN hinterlegen.
Den Thumbprint des passenden Certs bei der Aktivierung angeben ...Oder hostname im anderen Cert als weiteren SAN hinterlegen.
Das Zertifikat bei den DC's haben sie ja nicht. Sonst gehen andere Systeme auf die Bretter.
Kann ich den CN bei SAN hinzufügen? Bei uns stehen DNS Namen.
Zitat von @BPeter:
Das Zertifikat bei den DC's haben sie ja nicht. Sonst gehen andere Systeme auf die Bretter.
Quark, wenn du es nur dem einen Dienst zuweist ist es egal ob ein System mehrere Certs hat.Das Zertifikat bei den DC's haben sie ja nicht. Sonst gehen andere Systeme auf die Bretter.
Kann ich den CN bei SAN hinzufügen? Bei uns stehen DNS Namen.
Neues Cert mit allen benutzten Namen in den SANs ausstellen, fertig ist die Soße.Zitat von @BiberMan:
Zitat von @BPeter:
Das Zertifikat bei den DC's haben sie ja nicht. Sonst gehen andere Systeme auf die Bretter.
Quark, wenn du es nur dem einen Dienst zuweist ist es egal ob ein System mehrere Certs hat.Das Zertifikat bei den DC's haben sie ja nicht. Sonst gehen andere Systeme auf die Bretter.
Kann ich den CN bei SAN hinzufügen? Bei uns stehen DNS Namen.
Neues Cert mit allen benutzten Namen in den SANs ausstellen, fertig ist die Soße.Das hier hat funktioniert: winrm create winrm/config/Listener?Address=*+Transport=HTTPS @{Hostname="HOST";CertificateThumbprint="XXXXXXXXXX"}
Dein Tipp schau ich mir auch noch an
Danke
Zitat von @BPeter:
Das hier hat funktioniert: winrm create winrm/config/Listener?Address=*+Transport=HTTPS @{Hostname="HOST";CertificateThumbprint="XXXXXXXXXX"}
Jepp wie gesagt ...Das hier hat funktioniert: winrm create winrm/config/Listener?Address=*+Transport=HTTPS @{Hostname="HOST";CertificateThumbprint="XXXXXXXXXX"}
Hi,
ich bräuchte nochmals eurer Wissen.
Test von 2 Windows Servern:
Der Listener von Quelle und Ziel hört nur noch auf https (winrm enumerate winrm/config/listener). Wenn ich jetzt eine Remote Desktop Connection aus dem Windows Servermanager starte, sehe ich im Log der Firewall nur Port 5985 (http).
Was muss ich noch konfigurieren, damit der Traffic nur über Port 5986 geht?
VG
ich bräuchte nochmals eurer Wissen.
Test von 2 Windows Servern:
Der Listener von Quelle und Ziel hört nur noch auf https (winrm enumerate winrm/config/listener). Wenn ich jetzt eine Remote Desktop Connection aus dem Windows Servermanager starte, sehe ich im Log der Firewall nur Port 5985 (http).
Was muss ich noch konfigurieren, damit der Traffic nur über Port 5986 geht?
VG
RDP ist 3389 ... hat nix mit winrm zu tun ...
Anscheinend schon. RDP aus dem Servermanager nutzt scheinbar WinRM. ich sehe den Port 5985.
Ach du meinst den Servermanager, der geht per Default über 5985, macht aber nichts denn in einer Domain wird eh per Default Kerberos verwendet, unencrypted Traffic lässt sich zusätzlich per Policy auf beiden Seiten deaktivieren ...
gpsearch.azurewebsites.net/#2770
gpsearch.azurewebsites.net/#2774
gpsearch.azurewebsites.net/#8202
gpsearch.azurewebsites.net/#2770
gpsearch.azurewebsites.net/#2774
gpsearch.azurewebsites.net/#8202
Zitat von @BiberMan:
Ach du meinst den Servermanager, der geht per Default über 5985, macht aber nichts denn in einer Domain wird eh per Default Kerberos verwendet,
Ach du meinst den Servermanager, der geht per Default über 5985, macht aber nichts denn in einer Domain wird eh per Default Kerberos verwendet,
D.h.: Ich muss es nicht umstellen, da die Daten sowieso verschlüsselt übertragen werden
unencrypted Traffic lässt sich zusätzlich per Policy auf beiden Seiten deaktivieren ...
Trotz den Einstellungen auf beiden Seiten sehe ich Port 5985 bei WinRm (Servermanager)
Mittels eines kurzen Traces mit Wireshark könntest du es dir auch selbst beantworten
...Trotz den Einstellungen auf beiden Seiten sehe ich Port 5985 bei WinRm
Wie gesagt, normal, der Servermanager geht ausschließlich über diesen Port, er wird niemals einen anderen benutzen, aber nutzt eben dort Kerberos in einer Domain um einen Session Key zu generieren mit dem der Traffic darüber dann verschlüsselt wird.Zitat von @BiberMan:
Mittels eines kurzen Traces mit Wireshark könntest du es dir auch selbst beantworten
Mittels eines kurzen Traces mit Wireshark könntest du es dir auch selbst beantworten
...Trotz den Einstellungen auf beiden Seiten sehe ich Port 5985 bei WinRm
Wie gesagt, normal, der Servermanager geht ausschließlich über diesen Port, er wird niemals einen anderen benutzen, aber nutzt eben dort Kerberos in einer Domain um einen Session Key zu generieren mit dem der Traffic darüber dann verschlüsselt wird.Danke dir. Ich will mir halt sicher sein, dass meine Antworten auch richtig sind, bevor ich eine Domäne umstelle.
Also gehe ich jetzt auf die Suche, wer noch Port 5985 nutzt (außer Servermanager).
