Ich habe also ein kleines Labor mit 2 DCs, auf denen beide Server 2019 Core ausführen. Ich habe ein GPO mit einigen Firewall-Regeln erstellt und es oben in der Domäne verknüpft. Es gilt für alle Geräte, einschließlich beider DCs.
DC1, das derzeit noch alle FSMO-Rollen innehat, hat die Richtlinie erhalten, aber die Regeln sind nicht aktiv
DC2 hat die Richtlinie erhalten und alle Regeln sind aktiviert.
Ich kann beim besten Willen nicht herausfinden, warum ein DC die Regeln richtig anwendet, der andere jedoch nicht. Ich kann zur Registrierung navigieren und die Firewall-Regeln auf beiden DCs sehen. In einem RSOP wird angezeigt, dass der Computer die Richtlinie definitiv empfängt und analysiert, und ich kann die Regeln sogar sehen, wenn ich in PowerShell danach suche, aber ... dann gibt es einen Unterschied beim Vergleich der beiden DCs:
DC1 (wo keine Regeln angewendet werden):
EnforcementStatus Name Profile PrimaryStatus
----------------- ---- ------- -------------
ProfileInactive ComPlusNetworkAccess-DCOM-In Domain Inactive
{ProfileInactive, Enforced} RemoteDesktop-UserMode-In-UDP Any OK
{ProfileInactive, Enforced} RemoteDesktop-UserMode-In-TCP Any OK
ProfileInactive RemoteEventLogSvc-RPCSS-In-TCP Domain Inactive
ProfileInactive RemoteEventLogSvc-NP-In-TCP Domain Inactive
ProfileInactive RemoteEventLogSvc-In-TCP Domain Inactive
ProfileInactive RVM-RPCSS-In-TCP Domain Inactive
ProfileInactive RVM-VDSLDR-In-TCP Domain Inactive
ProfileInactive RVM-VDS-In-TCP Domain Inactive
ProfileInactive ComPlusRemoteAdministration-DCOM-In Domain Inactive
ProfileInactive WMI-ASYNC-In-TCP Domain Inactive
ProfileInactive WMI-WINMGMT-In-TCP Domain Inactive
ProfileInactive WMI-RPCSS-In-TCP Domain Inactive
ProfileInactive RemoteTask-RPCSS-In-TCP Domain Inactive
ProfileInactive RemoteTask-In-TCP Domain Inactive
Während sie auf DC2 so aussehen:
EnforcementStatus Name Profile PrimaryStatus
----------------- ---- ------- -------------
Enforced ComPlusNetworkAccess-DCOM-In Domain OK
{ProfileInactive, Enforced} RemoteDesktop-UserMode-In-UDP Any OK
{ProfileInactive, Enforced} RemoteDesktop-UserMode-In-TCP Any OK
Enforced RemoteEventLogSvc-RPCSS-In-TCP Domain OK
Enforced RemoteEventLogSvc-NP-In-TCP Domain OK
Enforced RemoteEventLogSvc-In-TCP Domain OK
Enforced RVM-RPCSS-In-TCP Domain OK
Enforced RVM-VDSLDR-In-TCP Domain OK
Enforced RVM-VDS-In-TCP Domain OK
Enforced ComPlusRemoteAdministration-DCOM-In Domain OK
Enforced WMI-ASYNC-In-TCP Domain OK
Enforced WMI-WINMGMT-In-TCP Domain OK
Enforced WMI-RPCSS-In-TCP Domain OK
Enforced RemoteTask-RPCSS-In-TCP Domain OK
Enforced RemoteTask-In-TCP Domain OK
Kurz gesagt, alle Regeln, die über GPO auf DC1 angewendet werden, haben den Status „Inaktiv“ und zeigen den Durchsetzungsstatus als „ProfilInaktiv“ an – was darauf hindeutet, dass das Domänenprofil deaktiviert ist, aber das ist eigentlich überhaupt nicht der Fall – alle Firewall-Profile sind auf beiden DCs aktiviert und natürlich gibt es einige benutzerdefinierte (Domänenprofil-)Regeln, die sowieso von DCPromo aktiviert werden, sodass dieses Profil aktiv und funktionsfähig sein muss, aber hier von beiden DCs
DC1:
Name : Domain
Enabled : True
DefaultInboundAction : NotConfigured
DefaultOutboundAction : NotConfigured
AllowInboundRules : NotConfigured
AllowLocalFirewallRules : NotConfigured
AllowLocalIPsecRules : NotConfigured
AllowUserApps : NotConfigured
AllowUserPorts : NotConfigured
AllowUnicastResponseToMulticast : NotConfigured
NotifyOnListen : False
EnableStealthModeForIPsec : NotConfigured
LogFileName : %systemroot%\system32\LogFiles\Firewall\pfirewall.log
LogMaxSizeKilobytes : 4096
LogAllowed : False
LogBlocked : False
LogIgnored : NotConfigured
DisabledInterfaceAliases : {NotConfigured}
DC2:
Name : Domain
Enabled : True
DefaultInboundAction : NotConfigured
DefaultOutboundAction : NotConfigured
AllowInboundRules : NotConfigured
AllowLocalFirewallRules : NotConfigured
AllowLocalIPsecRules : NotConfigured
AllowUserApps : NotConfigured
AllowUserPorts : NotConfigured
AllowUnicastResponseToMulticast : NotConfigured
NotifyOnListen : False
EnableStealthModeForIPsec : NotConfigured
LogFileName : %systemroot%\system32\LogFiles\Firewall\pfirewall.log
LogMaxSizeKilobytes : 4096
LogAllowed : False
LogBlocked : False
LogIgnored : NotConfigured
DisabledInterfaceAliases : {NotConfigured}
Hat jemand eine Ahnung, wo das Problem liegen könnte?
Antwort1
Sind Sie in den Netzwerkeinstellungen auf DC1 mit dem Domänenprofil verbunden? Einstellungen -> Netzwerk und Internet -> Netzwerk- und Freigabecenter -> Erweiterte Freigabeeinstellungen ändern -> Sicherstellen, dass die Domäne das aktuelle Profil ist.
Antwort2
KB162 hatte Recht, da DC1 dachte, es befände sich an einem öffentlichen Netzwerkstandort und nicht in einer Domäne.
Was den Grund angeht...
Der Dienst NlaSvc (Network Location Service) ist dafür zuständig, den Netzwerkstandort eines Geräts zu ermitteln. Dabei verlässt er sich (unter anderem) auf DNS.
Die Netzwerkkarte dieses DCs hatte die folgenden 2 DNS-Einträge (in dieser Reihenfolge):
- 127.0.0.1
- DC2
Der DNS-Dienst wurde nach dem NLA-Dienst gestartet, wodurch der Server dachte, er befände sich an einem öffentlichen Standort. Obwohl DC2 ebenfalls 127.0.0.1 als ersten DNS-Server hat, tritt dieses Problem nicht auf. Dies bedeutet, dass ein Race Condition vorliegt und dass DC1 möglicherweise auch nicht immer von diesem Problem betroffen ist.
Ein wenig Recherche zeigt einige mögliche Lösungen:
- Stellen Sie NlaSvc auf Automatisch (verzögerter Start)
- Fügen Sie eine DNS-Abhängigkeit zu NlaSvc hinzu
- Ändern Sie die DNS-Serverreihenfolge, um zuerst zum anderen DC und dann zu sich selbst zu gelangen.
Die erste Option löst das Problem nicht unbedingt, da es sich um einen Race Condition handelt und wir nicht wissen, wie lange der Start des DNS-Servers dauert. Sie wird das Problem höchstwahrscheinlich immer beheben, aber ich glaube nicht, dass wir mit 100-prozentiger Sicherheit garantieren können, dass es nie wieder passiert.
Die zweite Option ist ein bisschen ein Hack und wird meiner Meinung nach nicht unterstützt. Es kann sogar sein, dass Microsoft diese Werte während eines Updates ändert. Man kann es einfach nicht mit Sicherheit wissen.
Was die dritte Option betrifft... obwohl sie das Problem in einer Situation löst, in der mindestens einer der DCs aktiv ist, wird sie immer noch ein Problem darstellen, wenn beide DCs ausgefallen sind: Der erste DC, der gebootet wird, sucht auf dem anderen DC nach DNS, antwortet aber nicht, NlaSvc setzt den Netzwerkstandort auf öffentlich, der DNS-Dienst startet, NlaSvc ändert ihn nicht mehr. Der zweite DC, der gestartet wird, wird jedoch kein Problem darstellen.
Ich denke, ich werde mich für die erste Option entscheiden, da diese vermutlich den besten Support bietet, und werde von dort aus die Überwachung durchführen.
Vielen Dank an KB162, der mir geholfen hat, diese Lösung zu finden.