Win7 + Netlogon Error 5719 + GPO Error 1055

Diese Formel ergibt einen unschönen Mix und führt zu Fehlverhalten bei der korrekten Übernahme von Gruppenrichtlinien bis hin zum verlieren der Domänenmitgliedschaft des Computerkontos (im Extremfall). Und dies alles nur deshalb, weil sich da in Windows 7 ein Bug eingeschlichen hat, der von Microsoft leider erst inoffiziell bestätigt wurde. Ein genaues Datum für einen Patch oder ob dieser Bug in SP1 behoben wurde, ist noch nicht bekannt.Aber erst einmal sollten wir über die Konstellation sprechen, welche zu diesem Verhalten führt – nicht jeder 5719-, resp. 1055-Error hat etwas mit diesem Verhalten zu tun und kann auch an einer fehlerhaften DNS-Konfiguration liegen (wie so oft). Dieser Artikel geht jedoch von den folgenden Grundlagen aus:

  • Der Client verwendet DHCP, um eine IP-Konfiguration zu erhalten
  • Der DHCP-Server befindet sich NICHT im gleichen Subnetz wie der Client, so dass die Anfragen über einen IPHelper weitergeleitet werden
  • Die Clients führen Windows 7 aus
  • Die Windows Firewall (das öffentliche Profil) ist aktiviert
  • Der Reg-Key "DhcpConnForceBroadcastFlag" ist auf den Standardwert von "0" eingestellt

Auswirkungen:

  • Im System-Protokoll wird der NETLOGON-Event 5719 geloggt
  • Im System-Protokoll wird der GPO-Event 1105 geloggt
  • Gruppenrichtlinien werden nicht immer vollständig und korrekt angewendet
  • Im erweiterten Event-Log "DHCP-Client Events Operational" (welches zuerst aktiviert werden muss) werden Events mit der ID 50024 geloggt, welche auf ein "ACK Receive Timeout" hinweisen

Hintergrund: Wenn Windows 7 einen DHCP-Discover absetzt, erwartet es eine Rückantwort als Unicast (obwohl die Anfrage als Broadcast gesendet wurde). Ein Microsoft DHCP im gleichen Subnetz ignoriert diese Forderung und antwortet dennoch mit einem Broadcast. Obwohl dies nicht dem entspricht, was der Client erwartet hatte, läuft dennoch alles wunderbar. Falls die Anfrage jedoch über einen Relay Agent (IPHelper) weitergeleitet wird, da kein DHCP-Server im gleichen Subnetz zur Verfügung steht, so wird dieser die Rückantwort als eine Unicast-Antwort versenden. Dies entspricht zwar genau dem, was der Client möchte – aber leider ist die lokale Firewall auf dem Client nicht dafür konfiguriert und erwartet weiterhin einen Broadcast als Rückantwort. Da der Client zu diesem Zeitpunkt noch nicht prüfen konnte, ob seine Netzwerkschnittstellen einen Domänencontroller seiner Domäne sehen können (er hat ja noch keine IP), zieht hier noch das öffentliche Profil der Firewall – und diese besagt halt eben, dass dieser Traffic nicht rein darf… Hätte der Client hingegen einen Broadcast als Rückantwort verlangt (DhcpConnForceBroadcastFlag = 1), dann hätte der Relay Agent (IPHelper) auch eine Broadcast-Antwort geschickt – im Gegensatz zum Microsoft DHCP, hört der nämlich auf die Wünsche des Clients… Somit wäre alles gut gegangen. Kurzfassung: Die Windows-Firewall lässt grundsätzlich nur Broadcast-Rückantworten von DHCP-Meldungen zu (per Default), obwohl Microsoft unter Windows 7 explizit verlangt, dass Unicast-Antworten gesendet werden. Nur da der Microsoft DHCP im gleichen Subnetz diesen Wunsch ignoriert und dennoch Broadcast-Antworten sendet, klappt das auf diese Weise sauber und führt sonst zu hohen Latenzzeiten… Lösungsansätze: Wie löst man nun dieses Problem, wenn wir mal davon ausgehen, dass Microsoft mit dem Patch noch Zeit benötigt? Jeder der folgenden Punkte stellt dabei eine komplette Lösung dar:

  1. Man setzt den Reg-Key "DhcpConnForceBroadcastFlag" auf "1" – das Problem ist aber, dass sich dieser unter der GUID jedes NW-Adapters befindet und somit nur schwierig über eine GPO-Setting setzen lässt (auch nicht über die Reg-Option in den Extensions) – somit ist diese Lösung nur mit Scripting machbar… Der Flag lässt sich zwar auch Global je nach Interface-Typ setzen – aber dies stellt dennoch einen mühsamen Workaround dar… (siehe erster Link unter weitere Infos)
  2. Man deaktiviert die Firewall im öffentlichen Profil (welches sowieso nur sehr kurzfristig zieht, da der Computer ziemlich sofort danach in das Domänenprofil wechselt). Falls jedoch auch Laptops im Einsatz sind, welche auch mal auswärts auf das Internet verbinden, dann ist diese Option sehr schlecht, da diese auch dann ausgeschaltet bleibt…
  3. Man erstellt eine Eingangsregel auf der Firewall, welche auch DHCP-Unicastantworten zulässt (im öffentlichen Profil) – dies ist wohl die beste Lösung!!!

Ich denke, dass dieser Fall in den meisten grösseren Umgebungen eintreten wird oder schon eingetreten ist und hoffe somit, anderen das lästige Fehlersuchen zu ersparen! Weitere Infos:

VN:R_U [1.9.22_1171]
Rating: 10.0/10 (1 vote cast)
VN:F [1.9.22_1171]
Rating: +5 (from 5 votes)
Win7 + Netlogon Error 5719 + GPO Error 1055, 10.0 out of 10 based on 1 rating

3 Gedanken zu “Win7 + Netlogon Error 5719 + GPO Error 1055

  1. Hallo André
    Danke für den Artikel, dieser war sehr hilfreich.
    Wie genau muss die Firewallregel konfiguriert werden? Leider habe ich es mit der Lösung 3. noch nicht hingekriegt.
    Besten Dank.

  2. Hi,
    Das ist so eine Sache, welche überall etwas anders aussieht… Obwohl es bestimmt die sicherste Lösung wäre, empfehle ich Dir einfachheitshalber dennoch die Deaktivierung des öffentlichen Profils. Das ist auch von Seiten der Sicherheit nicht so schlimm, da dieses nur ganz kurz beim Start des Computers aktiv ist und im Anschluss nicht mehr verwendet wird (bei festinstallierten Desktops).

    Grüessli
    André

  3. Hi,
    Danke für die Antwort. Wir haben leider sehr viele Notebooks und deshalb ist die Variante eher schlecht :-(
    Ich habe eine entsprechende Firewall Regel erstellt, aber leider ohne Erfolg. Nur das Deaktivieren des öffentlichen Profils bringt den gewünschten Erfolg. Kannst Du mir ein Beispiel senden wie die Regel aussehen muss, damit es klappen sollte?
     
    Vielen Dank!
     

Schreib einen Kommentar