LDAP, DNS SRV Einträge - PC start

[freakx0 10]

Hallo zusammen,

 

ich habe hier ein Problem bei allen Win-Rechnern. Während des Starts wird ja nach dem Domänencontroller (DC) gesucht. Das läuft ja über das DNS-System.

 

Ich habe mitgeschnitten und festgestellt, dass dort etwas falsch läuft:

 

Der Query (SRV Record): _ldap._tcp.LOKALITAETSNAME._sites.DC-SERVERNAME.SUB.DOMAENE.I

 

Hier ist für mich total irritierend dass vor die SUB.DOMAENE.I noch der DC-Servername vorangestellt wird. Der Servername gehört hier ja nicht hin laut SRV Resource Records

Aber ich habe keine Ahnung wie ich das verhindern kann bzw. woher das kommt.

Hat sich jemand schon einmal mit diesem Problem auseinandergesetzt? Oder sonstige Hinweis?

 

Viele Grüße

Dominik

[carlito 10]

Unabhängig vom SRV Record Query, was konkret ist das Problem?

[freakx0 10]

auf dieses Problem bin ich eigentlich erst gestoßen, während ich den Netlogon Fehler (5719) beim Systemstart bemerkt habe. Ich habe dann den Verkehr mitgeschnitten und dort ist mir aufgefallen dass eben diese Anfrage nicht funktioniert und vermutlich fehlerhaft ist.

Den Auszug aus der Netlogon-Debug-Datei habe ich hier angehängt.

 

Vielleicht haben andere auch solche Probleme (DNS Abfragen nach nicht existierendem oder eben Netlogon).

 

Viele Grüße

Dominik

netlogon.txt

[blub 115]

Hallo freakx,

Man darf nicht einen Netzwerktrace nehmen und hinter jedem Error, jedem Fehlverscuh etc. einen tatsächlichen Fehler vermuten. Die Netzprotokolle versuchen oft verschiedene Standards oder Dialekte von oben her solange durch, bis sie ein successful bekommen. Bis dorthin gibts eben quasi "erwartete" Fehler im Trace,

 

blub

[freakx0 10]

Das stimmt, muss nicht immer gleich ein Fehler sein. Aber in diesem Fall hat es meiner Meinung nach etwas mit dem Netlogon fehler zu tun. Da die Anmeldung am DC nicht zügig klappt, haut es vermutlich den die netlogon-Prozedur raus. Leider auf allen Rechnern...

[blub 115]

5719 kommt am DC, wenn ein Client oder Server nicht sauber in der Domäne hängt beim Restart. Am DC selbst kannst du da nichts machen

[freakx0 10]

Ein Auszug aus der Netlogon-Debug Datei.

 

...
02/11 16:14:30 [LOGON]        Dom Guid: 
02/11 16:14:30 [LOGON]        Dom Sid: 
02/11 16:14:30 [iNIT] Starting RPC server.
02/11 16:14:30 [sESSION] ABCW2K: NlSessionSetup: Try Session setup
02/11 16:14:30 [sESSION] ABCW2K: NlDiscoverDc: Start Synchronous Discovery
02/11 16:14:30 [DNS] NlDnsHasDnsServers: DNS Server is NOT configured on this machine.
02/11 16:14:30 [MISC] NetpDcInitializeContext: DSGETDC_VALID_FLAGS is c01ffff1
02/11 16:14:30 [MAILSLOT] Sent 'Sam Logon' message to ABCW2K[1C] on all transports.
02/11 16:14:30 [CRITICAL] NlBrowserSendDatagram: No transports available
02/11 16:14:30 [CRITICAL] NetpDcGetNameNetbios: ABCW2K: Cannot NlBrowserSendDatagram. (1C) 53
02/11 16:14:30 [MISC] NetpDcGetName: NetpDcGetNameNetbios returned 1355
02/11 16:14:30 [CRITICAL] NetpDcGetName: ABCW2K: IP and Netbios are both done.
02/11 16:14:30 [CRITICAL] ABCW2K: NlDiscoverDc: Cannot find DC.
02/11 16:14:30 [CRITICAL] ABCW2K: NlSessionSetup: Session setup: cannot pick trusted DC
02/11 16:14:30 [MISC] Eventlog: 5719 (1) "ABCW2K" 0xc000005e 7f14dcc8 6c48a92f f9c5d616 c111129e   ..../.Hl........
02/11 16:14:30 [sESSION] ABCW2K: NlSetStatusClientSession: Set connection status to c000005e
02/11 16:14:30 [sESSION] ABCW2K: NlSessionSetup: Session setup Failed
02/11 16:14:30 [iNIT] Started successfully
...

da bei der Windows Start Prozedur per DNS mit den SRV Einträgen der DC ermittelt wird, deutet die Anfrage nach dem nicht existierenden SRV Eintrag nach meiner derzeitigen Meinung auf das Problem hin.

 

Ich denke halt durch die erste Abfrage - die ins Leere läuft - muss ein Timeout greifen (Netlogon fehler). Bei nächsten Anlauf (nicht neustart - beim weiteren Startvorgang)funktioniert es, man kann mit dem PC schon arbeiten. Aber der Netlogon fehler kommt immer 1x beim start....

[olc 18]

Hi,

 

Du suchst hier verkrampft nach einem Problem, wo keines ist. ;)

 

Wie blub schon sagte ist in diesem konkreten Fall nicht entscheidend, ob dort eine aus Deiner Sicht inkorrekte DNS Abfrage läuft. Jede Applikation kann mittels diverser Flags bestimmen, wie genau eine Auflösung erfolgen soll - ggf. also auch aus Deiner Sicht "falsch".

 

Außerdem hast Du nicht erwähnt, was nach der auf den ersten Blick inkorrekten DNS Abfrage geschieht - hier wäre also eher interessant, was der gesamte Startvorgang des Clients in Bezug auf DNS Traffic sagt.

 

Wo genau hast Du den Trace gezogen? An einem Mirror Port des Switches? Stimmen die Zeiten der NETLOGON.log und des Netzwerktraces (Fehler im Log und Anfrage im Trace) überein?

 

Wenn ich mir das NETLOGON.log anschaue, fallen mir zwei Dinge auf:

 

02/11 16:14:30 [MISC] NetpDcInitializeContext: DSGETDC_VALID_FLAGS is c01ffff1

02/11 16:14:30 [MAILSLOT] Sent 'Sam Logon' message to ABCW2K[1C] on all transports.

02/11 16:14:30 [CRITICAL] NlBrowserSendDatagram: No transports available

02/11 16:14:30 [CRITICAL] NetpDcGetNameNetbios: ABCW2K: Cannot NlBrowserSendDatagram. (1C) 53

02/11 16:14:30 [MISC] NetpDcGetName: NetpDcGetNameNetbios returned 1355

02/11 16:14:30 [CRITICAL] NetpDcGetName: ABCW2K: IP and Netbios are both done.

02/11 16:14:30 [CRITICAL] ABCW2K: NlDiscoverDc: Cannot find DC.

02/11 16:14:30 [CRITICAL] ABCW2K: NlSessionSetup: Session setup: cannot pick trusted DC

02/11 16:14:30 [MISC] Eventlog: 5719 (1) "ABCW2K" 0xc000005e 7f14dcc8 6c48a92f f9c5d616 c111129e ..../.Hl........

 

Wenn ich mir den weiteren Verlauf des Logs anschaue, finde ich folgenden Eintrag:

 

02/11 16:14:36 [MISC] DsGetDcName function returns 1355: Dom:(null) Acct:(null) Flags: RET_DNS

02/11 16:14:36 [sESSION] Winsock Addrs: 169.254.172.163 (1) List used to be empty.

02/11 16:14:36 [sESSION] ABCW2K: Zero LastAuth

 

Wenn es sich hier um das Clientlog handelt, dann hat der Client nach meinem Verständnis zu diesem Zeitpunkt scheinbar vom DHCP Server noch keine korrekte Adresse bekommen und nimmt daher eine APIPA Adresse. Das würde das Problem erklären.

 

Vergib testweise einmal eine feste IP-Adresse für den Client, aktualisiere den Treiber der Netzwerkkarte und prüfe, ob das Problem dann weiterhin auftritt.

 

Viele Grüße

olc

[zahni 521]

Wenn Netloogon-Trace oben vom DC ist, sind da vielleicht mehr als eine NIC im Server eingebaut ? Wenn nicht, ein DC sollte seine IP-Adresse nicht per DHCP beziehen. Irgendwo muss ja die 169.254.172.163 herkommen....

[freakx0 10]

Wenn Netloogon-Trace oben vom DC ist

 

Die Daten sind alle vom Client. DC hat auch eine Fixe Adresse (Failover auch).

 

Das mit der 169... Adresse kann ja sehr gut auf Probleme im Zusammenhang mit DHCP hinweisen. Ich schneide den Verkehr nochmal mit. Ich werde auch in meinem Test-vlan einen extra DHCP-Server reinstellen, damit die Antwort dann direkt aus dem gleichen Netz kommt.

[olc 18]

...wie oben schon geschrieben bist Du sicherlich schneller und für das Testen effektiver, wenn Du dem Client schlichtweg eine feste IP-Adresse gibst und ggf. auch die Netzwerkkartentreiber aktualisierst.

 

Für ein Troubleshooting einen DHCP Server aufzusetzen halte ich für "overkill" bzw. holst Du Dir damit unter Umständen Probleme an anderen Stellen ins Haus.

 

P.S.: Meine anderen Fragen hast Du auch nicht beantwortet... ;)

 

Viele Grüße

olc

[freakx0 10]

Eine statische Adresse wurde schon vergeben. Dann erscheint der Netlogon Fehler nicht. Deutet also auf DHCP hin. Netzwerkkartentreiber wurden bereits aktualisiert (allerdings die neusten von Dell, nicht direkt vom Kartenhersteller).

 

Wo genau hast Du den Trace gezogen? An einem Mirror Port des Switches? Stimmen die Zeiten der NETLOGON.log und des Netzwerktraces (Fehler im Log und Anfrage im Trace) überein?

 

Ich habe mit einem alten Hub mitgeschnitten, beim SPAN-Port ist komischerwiese der DHCP-Traffic nicht durchgekommen (vermutlich dhcp snooping und co).

 

Was ich zwischenzeitlich herausgefunden habe (anhand des Zeitvergleichs der Daten), Netlogon startet fast gleichzeitig mit der DHCP-Anforderung (also in der gleichen Sekunde). Eigentlich sind es ja nur paar Pakete für DHCP (INFORM + deren ACK kommt aber paar Sekunden später). Aber bei der DHCP-Vergabe verursacht wohl die Probleme ...

 

DHCP Server lass ich hin und wieder direkt auf meinen NB laufen, gibts ja kleine Daemons.

 

Gruß

Dominik

[olc 18]

Hi Dominik,

 

ok, dann lagen wir also richtig mit der DHCP Vermutung. Dann ist "der Rest" ja "ein Kinderspiel"... ;)

 

Viele Grüße

olc

[freakx0 10]

:-D

 

naja, da habe ich heute fast den ganzen tag damit verbracht. So wirklich viel drehen kann man da auch nicht mehr...

Teilweise wurden heute 2x Request rausgeschickt (5 Sekunden nach dem ersten wurde zweiter wegen Timeout abgesetzt). Das muss nun auf dem DHCP Server noch untersuchen ob dort etwas ankommt (also der erste) und falls ja warum keine Antwort und falls nein. Warum kommt nix.

Ich hoffe wirklich dass ich das irgendwie gelöst bekomme und dann die anderen Probleme auch erledigt sind.

 

Gruß

[zahni 521]

Vielleicht beschreibst Du uns mal Deine Netzwerk Infrastruktur und wo welcher DHCP-Server dort angebunden ist.