WinRM auf DCs

[al3x 11]

Hi,

 

spricht etwas dagegen WinRM-HTTPS (Zertifikate) auch auf den DCs zu nutzen?

In div. Anleitungen wird immer nur auf die Dom.Computer hingewiesen:

https://www.infrastrukturhelden.de/microsoft-infrastruktur/active-directory/windows-winrm-ueber-https/

[MurdocX 953]

Hi,

 

ich wüsste nichts, was dagegen spricht.

 

Grüße

[al3x 11]

Hallo.. ich habe hierbei folgendes Problem:

 

1) Alle Serversysteme lassen sich zB über Enter-PSSession -ComputerName fqdn -UseSSL erreichen.

 

2) Alle Clientsysteme, die die gleichen Einstellungen besitzen wie o.g. Server (eingehend HTTPS:5986, Zertifikat, winrm quickconfig -transport:https, etc) liefern über

Enter-PSSession -ComputerName fqdn -UseSSL die ErrorID: CreateRemoteRunspaceFailed

Eine reine HTTP-Verbindung über Enter-PSSession -ComputerName fqdn funktioniert.

 

Bisher habe ich keine Erklärung gefunden, was bei den Clients der Unterschied ist. Hat hier jemand ne Idee?

 

 

[daabm 1.366]

Passen die FQDNs und SANs in den Zertifikaten zum Clientnamen? Und die CA-Chain ist vertrauenswürdig auf dem zugreifenden System? Wenn zweimal ja, hab ich auch keine spontane Idee...

[al3x 11]

Hallo Martin,

 

ich habe alles nach og Anleitung gemacht und in der CA sieht man die ausgestellten WinRMSSL-Zertifikate von den Servern und Clients. Bis auf den fqdn sind die ja analog.

Unterscheiden sind per default Memberserver und Client was das CA-Chain-Vertrauen angeht? Wie kann ich das prüfen? Ich habe hier Server und Clients nicht unterschiedlich behandelt.

Enter-PSSession : Beim Verbinden mit dem Remoteserver "FQDN" ist folgender Fehler aufgetreten: WinRM kann den Vorgang nicht abschließen. Überprüfen Sie, ob der
angegebene Computername gültig, der Computer über das Netzwerk erreichbar und eine Firewallausnahme für den WinRM-Dienst aktiviert ist und den Zugriff von diesem Computer zulässt.
Standardmäßig wird der Zugriff auf Remotecomputer innerhalb desselben lokalen Subnetzes von der WinRM-Firewallausnahme für öffentliche Profile eingeschränkt. Weitere Informationen
finden Sie im Hilfethema "about_Remote_Troubleshooting".
In Zeile:1 Zeichen:1
+ Enter-PSSession -ComputerName FQDN -UseSSL
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : InvalidArgument: (FQDN:String) [Enter-PSSession], PSRemotingTransportException
    + FullyQualifiedErrorId : CreateRemoteRunspaceFailed

..das ist die Meldung beim Verbindungsversuch.

 

-FQDN ist erreichbar

-WinRM aktiviert

PS C:\WINDOWS\system32> winrm quickconfig -transport:https
Der WinRM-Dienst wird auf diesem Computer bereits ausgeführt.
WinRM ist bereits für die Remoteverwaltung auf diesem Computer eingerichtet.

-FW-Ausnahme auf tcp/5986 eingehend eingetragen

 

 

 

[al3x 11]

okay....obwohl winrm eingerichtet und eingehend/5986 aktiv ist, scheint es ein Problem zwischen FW und dem HTTPS-Listener zu sein.
manuell funktioniert es ...aber als GPO nach dem howto scheint dies das Problem zu sein..ich bin etwas überfragt

 

-> also die FW-Regel wird sauber eingetragen, aber netstat zeigt keinen Port 5986, obwohl winrm quickconfig durchläuft... das scheint das Problem zu sein!

 

Ideen?

bearbeitet 17. Februar 2021 von al3x

[daabm 1.366]

Was meinst Du mit "manuell funktioniert es"? Und was genau steht in Deiner GPO dazu? Zu wenig Info

[al3x 11]

Es funktioniert bei einem Client, wenn man die Einstellungen bzgl Portfreigabe, winrm etc vornimmt.

Knüpfe ich aber eine GPO lt. Anleitung an die OU, wird die Portfreigabe zwar erstellt und auch winrm ist aktiv, aber der port ist nicht offen - trotz angezeigter Freigabe.

 

Nehme ich den Rechner aus der OU, komplett ohne GPO, und setze eine lokale Portfreigabe, dann muss der HTTPS-Listener neu initialisiert werden...verschiebe ich dann den Rechner wieder in die OU und lösche die lokale Freigabe wieder, dann greift wieder die Freigabe über die GPO und der Port bleibt auch offen. Ich kann das aber nicht für jeden Client einzeln machen

Ich habe in der OU 6 "Firewall-GPOs", die jeweils für sich einen oder mehrere sep. Ports freigeben (je nach Anwendung)..dachte schon ob es irgendwie an der Reihenfolge der GPOs liegt, finde aber nix Widersprüchliches.

 

 

bei allen GPOs ist eingestellt:

 

• Richtlinien / ../ Sicherheitseinstellungen / eingehende Regeln -> jeweilige Ports definiert
• AdminVorlagen / Windows Defender / Domänenprofil -> WindowsDefender - Alle Netzwerkverbindungen schützen = aktiviert

da die Ports ja immer unterschiedlich sind, dürfte sich ja auch nix überschneiden!?

[daabm 1.366]

Kann es sein, daß WinRM zu schnell startet? Wenn das versucht den Listener zu erstellen, bevor die FW aus der Boot Protection raus ist, bleibt der Port zu. Kannst mal versuchen, WinRM auf delayed autostart umzustellen.

Wobei das nicht dazu paßt, daß http geht und https nicht - dann wäre ich raus :-(

[al3x 11]

..hab ich probiert, hilft aber nix, wenn wird immer nur ein https-listener auf 443 erstellt.

Ich werde wohl die policy mal komplett neu machen.

Macht es Sinn die rules immer  von autarken Clients zu exportieren und dann in eine GPO zu importieren oder kann man Regeln auch ohne Bedenken direkt auf einem Server in einer GPO festlegen?

[MurdocX 953]

vor 35 Minuten schrieb al3x:

Macht es Sinn die rules immer  von autarken Clients zu exportieren und dann in eine GPO zu importieren

Meiner Meinung nach ja, auch wenn wir es selbst nicht immer so handhaben. Den Grund für das „Warum“ hast du gerade selbst erlebt. Das Gleiche habe ich schon mit dem einer RDP-Rule erlebt. Deshalb versuchen wir die Builds immer für alle gleich zu ziehen.