Jul 23, 2019

9110

Windows Server 2016 Firewallregel lässt sich nicht ändern

Hallo Kollegen,

Windows 2016 DC, AD, DNS, DHCP

In der Domäne ist das SMB Protokoll 445 TCP durch eine Regel blockiert.
Die Regel die den Port blockiert ist Remoteverwaltung (NP eingehend), aktiviert, Domäne, alle Blockieren.
Ändern/deaktivieren/löschen geht nicht...

Bisher gibt es außer der default Domain Policy nur 3 weitere GPo. Die aber alle nicht die Regel beinhalten.
Zu finden müsste die Regel sein unter Computerkonfiguration/Richtlinien/Windows Einstellungen/Sicherheitseinstellungen/Windows Firewall/Windows Firewall mit erw Sicherheit/Eingehende Regeln

Auch per Powershell kann ich die Regel anzeigen lassen aber nicht löschen/ändern/deaktivieren.

Bin gerade etwas Ratlos, wo ich die Regel ändern oder löschen kann

Kann mir jemand helfen?

Danke Jörg

Please also mark the comments that contributed to the solution of the article

Content-Key: 476458

Url: https://administrator.de/contentid/476458

Printed on: April 23, 2024 at 12:04 o'clock

38 Comments

Latest comment

Hallo Jörg,

hast du wirklich alle GPOs durchgeschaut? Wenn nein, nochmals Augen reiben und nochmals durchschauen, wenn sonstig kein Tool die Regeln setzen kann muss das da sein.

Viele Grüße,

Christian

Hi,

vllt ein ungewöhnlicher Ansatz aber mal in die Registry geschaut?
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\SharedAccess\Parameters\FirewallPolicy\FirewallRules

Hallo Christian,

das dachte ich auch.
Wenn ich mit der Powershell mit die Firewallregel anzeige ist sie da, wenn ich sie dann ändern oder löschen will wird der Befehl ohne (Fehler)Meldung ausgeführt und die Regel ist noch Da.
Diese Regeln gibts in der gpmc

Alle sind sie im Bereich Firewall/Eingehende Regeln leer
Die Remotediesnteverwaltung habe ich vorhin hinzugefügt und sie ist ebenfalls leer.
Dies ist die Regel, die ich nicht ändern oder löschen kann

Ich finde leider nicht die Einstellung die ich ändern muss.
Sorry, ist ein System, dass ich übernommen habe und muss mich da noch reinfinden

Hallo Bitboy,

danke für den Input,

hab ich gefunden

Ist wohl die mittlere. Da finde ich aber Action=Allow
das bedeutet doch, dass diese Regel den Port 445 eingehend auf TCP öffnet?!
Oder verstehe ich das falsch???

Jörg

Ein Schrittchen weiter,

Es gibt die Regel "2mal"
Einmal für Alle und einmal für Domäne und letztere blockiert

Da du die Regel per Powershell gesetzt hast, häng mal ein
-Profile Domain
an den Befehl.

nee, hab ich nicht.
Oder ich hab keine Ahnung wie es der Kollege von früher gemacht hat.
die die ich angelegt habe, da ist aber die Regel nicht enthalten, habe ich mit der gpmc angelegt.

Mir würde sehr helfen, wenn ich einen Tipp bekommen könnte wo/wie ich die Regel finden kann!?
Oder wie ich die betreffende löschen kann. Mit der Powershell hats nicht geklappt.
Syntax ok, es kommt keine Fehlermeldung, aber anschließend ist sie nicht gelöscht

Moin,
drei Anmerkungen meinerseits:

Die Gruppenrichtlinie, die du in den Screenshots markiert hast, hast du bearbeitet? Die gilt natürlich nur für Server welche als Domain Controller agieren.
Die Gruppenrichtlinie Default Domain Controllers Policywird bis auf wenige Ausnahmen nie, nie, nie verändert/ergänzt. Zu den Ausnahmen gehören die Windows-Firewall Regeln nicht.
Bevor du nun wie wild an den Servern "rumspielst" und evtl. Dinge änderst, die zu Instabilität oder Ausfällen sorgen, erst einmal analyiseren. Wenn du Windows-Firewall Regeln manuell nicht verändern kannst, gibt es zwei Gründe. A) Der Benutzer, unter dem du das versuchst, hat auf dem betroffenen System keine administrativen Rechte. B) Es wird pe Gruppenrichtlinie erzwungen. Welche Gruppenrichtlinie dafür verantwortlich ist, kannst einfach herausfinden. Auf dem betroffenen Server einfach die Befehle rsop.msc und gpresult /r ausführen. Danach solltest du mehr wissen...

Oder ich hab keine Ahnung wie es der Kollege von früher gemacht hat.

Da ist die liebe Dokumentation wieder auf der Strecke gelieben. Manche Unternehmen lernen es erst, wenn es zu spät ist oder teuer wird.

Gruß,
Dani

Hi Dani,

- die Default Domain Controller Policy habe ich nicht geänder und hab das auch nicht vor. Das zumindest ist klar (war nur vom umsortieren markiert)
- ich bin mit dem domadmin angemeldet, der sollte doch genügend rechte haben?
- spielen ist nicht!-)
- bei gpresult /r bekomme ich
Angewendete Gruppenrichtlinienobjekte
--------------------------------------
Default Domain Policy
und die beinhaltet nicht die Regel

- bei gpresult /z bekomme ich
Angewendete Gruppenrichtlinienobjekte
--------------------------------------
Default Domain Controllers Policy
Default Domain Policy
WMI-Verwaltung-zulassen

Folgende herausgefilterte Gruppenrichtlinien werden nicht angewendet.
----------------------------------------------------------------------
Richtlinien der lokalen Gruppe
Filterung: Nicht angewendet (Leer)
Und auch bei den 3en finde ich die Regel, die es blockiert nicht. Die habe ich mir ja schon in der Verwaltungskonsole angeschaut

Gruß Jörg

Guten Morgen,
noch ein Gedanke.
Kann ich mir anzeigen lassen wo (welcher User) die Regel konfiguriert ist/hat?
Z.B. per powershell oder sonstwie
Suche da grade die "Nadel im Heuhaufen" wo ich die Regel ändern kann

Wünsche einen sonnigen Tag
Jörg

Moin,

afaik gibts da kein Log für wer wann welche regel geändert hat.

Was passiert denn wenn du die Regel per Powershell ändern möchtest?

Hallo zurück,

danke für die Infos.
Bin einen deutlichen Schritt weiter.
Habe festgestellt, das die DCs sich nicht (richtig) synchronisieren!
Die Regel kommt vermutlich vom anderen DC?!
Das muss ich mir jetzt erstmal anschauen.
Neue Baustelle...

Per Powershell wird der Befehl einfach "ohne Kommentar" ausgeführt und die Regel ist noch da.
Das Log, da habe ich noch nicht nach gesucht. Vermutlich nein

Firewall Problem die Fortsetztung,

Gestern habe ich festgestellt, dass die Replikation zwischen den DCs nicht klappt.
Der Ursache bin ich auf die Spur gekommen. Die lokale Firewall der DCs blockieren die Kommunikation. Vermutlich auch weil der Port 445 und 135 domänenweit blockiert wird.
Nachdem ich die Firewall deaktiviere klappts mit der Replikation.
So,
dann habe ich versucht die Firewallregeln

Per Powershell zu löschen
Firewall Regel, die Blockieren anzeigen durch
Get-NetFirewallRule -Action block -Enabled True -Direction Inbound

Hmm, die Regel wird im GUI angezeigt, aber nicht via powershell!? Oder habe ich da einen Fehler eingebaut?
Eine Firewallregel Port 0815 Domänenweit blockieren erzeugt

Nochmal die Get-NetFirewallRule -Action block -Enabled True -Direction Inbound anzeigen

Und siehe da die 0815 Regel wird angezeigt und die anderen 3, die ich nicht löschen kann NICHT!?
Dann deaktiviere ich einfach die Regel.
Disable-NetFirewallRule -Action Block -Enabled True -Direction Inbound

Hmm hat geklappt.
Keine mehr da (in der Powershell)
Dann schauen wir uns das in der GUI nochmal an.

Siehe da, die Test0815 Regel ist deaktivert, aber nicht die, die ich eigentlich löschen will!!
So, wenn ich jetzt Remove-NetFirewallRule -Action block -Direction Inbound ausführe, müssten eigentlich alle 4 Regeln gelöscht werden

Die Test0815 ist gelöscht, die 3 anderen nicht…

Die Regeln gibt’s übrigens domänenweit.
Nochmal zu den Einzelheiten der Regeln, die sich nicht löschen lassen

Und der Administrator / Domadmin darf die Regel nicht ändern!
Noch Ideen?
Oder Tipps, wer uns da bei der Lösung helfen kann?

Genervte Grüße Jörg

HI,

der Hinweis dass diese Einstellung vom Systemadministrator gesetzt wird lässt weiter darauf schließen, dass die Regel von einer GPO kommt.
Alternativ könntest mal prüfen ob irgendwelche 3rd Party Sachen installiert sind die da eventuell rumpfuschen.

Zuletzt mal den umgekehrten Weg versuchen: GPO erstellen die explizit den TRaffic zulässt und schauen ob die angewendet wird.

Grüße

Hi Bitboy,

danke für Deine Idee.
Die GPos einthalten NICHT die Regeln.
Eine Test GPo,a cuh mit dem selben Port, wird angewendet, nur steht die Block Regel höher und wirkt dadurch weiterhin.
Question
Sie können nicht über Ihren eigenen Beitrag abstimmen.
Die Regelquelle ist "Lokale Gruppenrichtlinienenstellung"
UND lässt sich leider nicht ändern/löschen/etc. so als wenn sie nicht existiert.
Tut sie aber, da sie wirkt und in der GUI angezeigt wird.
Mit der Poweshell, ist es wie als wenn sie nicht vorhanden ist.
Als Thitparty Produkt sehe ich egentlich nichts, außer Symntec Endpoint Protection...

Noch Ideen?

Jörg

Zitat von @jocologne:
Die Regelquelle ist "Lokale Gruppenrichtlinienenstellung"

Schon in die lokale Sicherheitsrichtlinie geschaut ob da die Regeln definiert sind?
secpol.msc

Hab ich,
unter "Lokale Gruppenrichtlinienenstellung"

Aber auch in der gpdit.msc unter Richtlinie/Computer/Windows/Sicherheit/Windows Firewall/Windows Firewall mit erw/Eingehende Regeln ist KEINE definiert.

auch nichts
Ich bin ratlos

Jörg

Im Endpoint Protection was definiert?

Hallo zurück,

da gehe ich nicht von aus.
Wir haben den Kunden übernommen und ich hoffe wir bekommen auf den Manager mit Hilfe des Supports Morgen (Supporttermin) Zugriff.
Das ist meine letzte Hoffnung.
Leider auch da kein funktionierendes Passwort und die restore Mail geht wohl ins nirvana...

Herzlichen Gruß

Jörg

Hallo All,
in den letzten tagen haben wir
das Problem mit dem Zugriff auf die Symantec Verwaltungskonsole gelöst und die Verwaltung läuft wieder.
Festgestellt habe ich auch, dass die Firewallregeln (von Symantec) nicht funktionieren konnten. Diese habe ich erstmal auf default umgestellt und so die Funktion in der Domain wiederherstellen können.
Soweit so gut.
Nur leider kann ich die 3 oben beschriebenen (domänenweiten) Windows Firewall Regeln noch immer nicht löschen oder ändern.
Wenn ich einen Client oder Server aus der Domäne nehme ist die Regel auch weg. Wird also in der Domäne verteilt und hat nichts mit AV oder lokaler Regel zu tun.
Mir gehen die Ideen aus das Problem zu lösen.
Hat jemand noch Vorschläge?
Herzlichen Gruß
Jörg

Hallo zusammen. Gestern ist und genau das selbe bei einigen unserer Windows Clients aufgefallen. Diese drei Firewall-Regeln sind da und können nicht gelöscht oder bearbeitet werden. Angeblich kommen die von Administrator, aber keine GPO stellt diese ein.

Powershell und netsh finden diese Regeln gar nicht erst. Daher kann man auch nicht versuchen die dadurch zu löschen.

Da durch eine der Regeln der Port 445 und durch eine andere der Port 135 geblockt werden, vermuten wir in dieses Regeln die Verursacher eines SCCM-Softwarecenter Problems das wir haben.

Nun bin ich hier auf diesen Beitrag gestoßen und dacht ich schreibe einfach mal. Vielleicht gibt es ja schon neue Erkenntnisse. Ich persönlich vermute in zwischen WIndows Defender Endpointprotection vom SCCM als übeltäter, finde aber keinen entsprechenden Punkt.

Vielleicht hat ja noch jemand eine Idee.

Viele Grüße
Nils

Guten Morgen NilsAcht,

sitze gerade auch wieder dran.
Magst Du Dich mal bei mir melden?

Klar, wie?

Grade festgestellt,

dass die Firewall-Regeln verschwunden sind, wenn der Testclient aus der Domäne genommen wird und wieder auftauchen wenn wieder Domänenmitglied.
UND
Als Regelquelle wird die Lokale Gruppenrichtlinieneinstellung genannt?!

Das widerspricht sich doch?
Noch ne Idee?

Jörg

Moin.

Wenn die hier auf Deaktiviert gesetzt sind kommt das geschilderte Verhalten und der Defender verhindert das Ändern.

Wenn diese Policies in deinen GPOs nicht direkt sichtbar sind, gehe in den SYSVOL-Ordner und checke die GPOs in den Dateien manuell nach, bei älteren Policies kann es mal vorkommen das diese über die MMC nicht sichtbar sind.

Zusätzlich mit rsop.msc am Client die gesetzten Policies prüfen.

Gruß

Ich habe die Einstellungen gemacht und diese werden auch angewendet. Leider habe ich immer noch die drei Regeln die ich nicht löschen kann.

Jörg und ich habe den Vormittag mal geschaut und leider nicht sehr viel mehr neues raus gefunden. Die Regel scheint von einer GPO zu kommen, aber ein GPResult zeigt diese nicht an. Außerdem scheint diese GPO den Zugriff im Domänen-Profil zu erlauben, tut sie aber nicht.

Dann beherzige mal meinen Rat manuell in die GPOs im Sysvol reinzuschauen.

Sorry aber da steige ich nicht durch. Wonach genau soll ich denn dort schauen?

Zitat von @NilsAcht:

Sorry aber da steige ich nicht durch. Wonach genau soll ich denn dort schauen?

Nach Regeln die so nicht selbst in den GPOs ersichtlich sind. Du machst also einen Abgleich mit denen in der GUI sichtbaren Policies.
Denn Policies müssen nicht zwingend alle in der GUI sichtbar sein wenn derjenige eigene ADMX Templates verwendet hat.
Deswegen auch mein Hinweis zu rsop.msc am Client, in der alle einzelnen Einstellungen ersichtlich sind. Genauso wie im GPO-Cache am Client.

Auch auf die Gefahr hin, dass ich sehr dumm dar stehe: Im Sysvol Ordner sehe ich nur GUIDs als Ordnernamen. Klar kann ich mich da überall durch klicken, dauert mir aber zu lange.

Kann ich die Ordnernamen irgendwie auflösen?

Klar, in der GPMC Rechtsklick auf die GPO Eigenschaften, da steht die GUID, oder per Powershell : Get-GPO

Get-GPO -All | ft DisplayName,ID

So, GPO auf dem Server eingestellt. Diese wird auch auf dem Client angewandt. Dennoch kann ich nicht an den Firewall Regeln ändern. Leider ist die Firewall abschalten oder den Softwarecenter Client auf 700 Rechner per Hand zu aktualisieren keine Option.

Gibt es noch andere Ideen?

Zitat von @NilsAcht:

So, GPO auf dem Server eingestellt.

Solltest du aber nicht machen.

Dennoch kann ich nicht an den Firewall Regeln ändern.

Deswegen manuell die GPOs prüfen, wie ist das denn jetzt verlaufen?? Jetzt sag nicht "keine Zeit". Wenn man noch nicht mal diese Grundlegende Aktion durchgeht um sicherzustellen das nicht doch etwas unter der GUI durchrutscht ist alles andere vertane Zeit!
Wie gesagt, wenn derjenige der da hantiert hat eigene ADMX Templates z.B. mit einem speziellen Registry-Eintrag genutzt hat, siehst du das nicht in der GUI!!!

oder den Softwarecenter Client auf 700 Rechner per Hand zu aktualisieren keine Option.

Wofür gibt's Softwaredeployment

Gibt es noch andere Ideen?

S.o. Auf ein Ergebnis warten wir noch.

Ich habe die lokalen GPOs überprüft. Aber der GPMC (den ist erst mit den RSAT Tools nachinstallieren musste) zeigt mir nur die Serverrichtlinien. Auch der Powershell-Befehl (welchen ich erst ausführen konnte, nachdem ich den GPMC installiert habe) zeigt mir noch die Serverrichtlinien an. Daher habe ich die Policy einmal auf dem Server eingestellt und an meinen Client verteilt.

Wenn das der flasche Weg war, würde ich mich über eine genauere Erklärung freuen, da ich leider in dem ganzen Thema GPO nicht so bewandert bin.

Und das pushen des Clients über SCCM (Softwaredeployment) geht ja nicht, da durch die Regel der Port 445 geblockt wird. Und ein Block reicht um alle Allows dieses Ports aufzuheben.

Zitat von @NilsAcht:

Ich habe die lokalen GPOs überprüft.

Du solltest die Richtlinien im Sysvol checken nicht nur am Client.

Aber der GPMC (den ist erst mit den RSAT Tools nachinstallieren musste) zeigt mir nur die Serverrichtlinien.

Logisch! Geh an den Server und nutze mal dort die GPMC. Wenn ihr keinen Domänenweiten Central-Store für die Templates nutzt unterscheiden sich die Templates am Server und am Client.

Auch der Powershell-Befehl (welchen ich erst ausführen konnte, nachdem ich den GPMC installiert habe) zeigt mir noch die Serverrichtlinien an.

Auch logisch, deswegen alles erst mal am Server machen.

Daher habe ich die Policy einmal auf dem Server eingestellt und an meinen Client verteilt.

Trial & Error geht aber kostet nur noch mehr Zeit und beseitigt nicht die Ursache.

Und das pushen des Clients über SCCM (Softwaredeployment) geht ja nicht, da durch die Regel der Port 445 geblockt wird. Und ein Block reicht um alle Allows dieses Ports aufzuheben.

Es gibt auch andere Methoden per GPO

So, nach ein paar Tagen ohne Versuche sind die Regeln nun auf Allow gesetzt. Leider kann ich mir nicht erklären warum. Auf meinem Client habe ich viel versucht, aber es ist auch auf Clients aktiv, die drei Wochen nicht eingeschaltet waren. Oder auf denen nichts geändert wurde.

Bei mir lag das Problem darin, dass in der GPO in der RDP-Richtlinie "Windows-Firewall: Eingehende Remotedesktopausnahmen zulassen" einen Eintrag im Bereich "Unerbetene eingehende Meldungen von diesen IP-Adressen zulassen:" als IP-Liste hatte.

Hier dürfen KEINE Leerzeichen zwischen den Einträgen sein.
Also "192.168.2.1,192.168.2.254" und nicht "192.168.2.1, 192.168.2.254" (Leerzeichen nach dem Komma).

Nachdem ich alle Leerzeichen gelöscht hatte und bei den Clients ein "gpupdate /force" durchgeführt habe, konnte ich mich wieder per RDP verbinden.

Wer denkt denn bitteschön an so etwas?
Zumal aus einer Allow-Regel durch das Leerzeichen eine Deny-Regel wird, die sich auf den Clients auch nicht löschen lässt.

Ich hoffe, dass dies bei dem ein oder anderen auch hilft!

@MasterPhlox: habe heute 4 Stunden verbracht nach diesem sch*§$s Fehler zu suchen.
Dein Hinweis mit den Leerzeichen war dann endlich des Rätsels Lösung.

Vielen Dank dafür !

German Question Windows Server Microsoft

Hotly discussed

Check of ZFW Firewallgleixnerd - 5 Comments

Wireguard VPN on UDM Pro behind Fritzbox - Handshake did not completejstricker - 3 Comments

How to set up and configure a Linux GRE tunnelAlexWisha - 3 Comments

End of Support dates for Office 2016, 2019 Apps und Productivity ServersDani - 1 Comment