Client Traffic in "fremde" Subnetze

[MS-Wing 10]

Hallo,

 

ich habe folgende Frage: Warum kontaktieren Clients in einer AD-Site die DCs in einer anderen Site auf Port 138 (tcp) und Port 389 (udp)?

 

Hintergrund:

 

Eine Domäne Windows 2003 im native Mode.

Zentrale Site mit 2 DCs und 3 andere "Sub"-Sites mit jeweils einem DC.

(Also klassisches "Zweigniederlassungsszenario")

"Brücke zwischen allen Standortverknüpfungen" ist abgeschaltet.

Alle DCs sind globaler Katalog und DNS-Server für die jeweilige Site.

Es gibt jeweils 3 IP-Site Links. In jedem Sitelink ist jeweils die zentrale Site und die jeweilige Subsite enthalten. Die IP-Subnetze sind korrekt der jeweiligen Site zugeordnet.

Grund für diese Konfiguration ist, das die "Subsites" durch Firewallblocking keinen Kontakt zu einander haben sollen. Die DCs der Subsites können sich also nicht miteinander unterhalten.

 

Wir beobachten jedoch permanent Traffic von Clients aus den Subsites, die jeweils DCs in anderes Subsites kontaktieren wollen. Dies wird natürlich von der Firewall geblockt.

 

Was veranlasst die Clients dauernd diese ungewollten Connections zu versuchen?

Sie haben doch Ihren lokalen DC im Subnetz....

 

Der MS-Artikel KB306602 könnte die Lösung für das Problem sein, aber ich würde gerne eure Meinung oder Erfahrung dazu wissen.

 

Gruß,

 

Sascha

[Eyeswide 10]

Stellt sich mir zuersteinmal die Frage, wieso verhinderst du, das die DC`s sich "unterhalten" können.

Zudem hast du ja sicherlich die Betreibsmasterrollen auf einem DC ...

Der PDC wird soweit ich weis für gewisse "dinge" (zu meiner Schande müsste ich auch nachlesen ...) kontaktiert.

[MS-Wing 10]

Stellt sich mir zuersteinmal die Frage, wieso verhinderst du, das die DC`s sich "unterhalten" können.

Zudem hast du ja sicherlich die Betreibsmasterrollen auf einem DC ...

Der PDC wird soweit ich weis für gewisse "dinge" (zu meiner Schande müsste ich auch nachlesen ...) kontaktiert.

 

Die Subnetze in den Subsites sollen sich gegenseitig nicht sehen. Das ist einfach mal so gewollt ;)

Mir ist klar das Microsoft immer gerne eine vollgeroutete Umgebung vorraussetzt. Aber das selten mit der Realität zu tun :)

 

Die Betriebsmasterrollen (wie eben PDC-Emulator) sind auf jeden Fall in der zentralen Site verfügbar und dorthin ist der Traffic auch erlaubt. Also bleibt weiterhin die Frage, warum Clients mit anderen DCs in nicht erreichbaren Subnetzen sprechen wollen...

 

Die Clients kennen die anderen DCs durch die _msdcs Zone im DNS und versuchen aus einem mir (noch) nicht bekannten Grund Kontakt zu diesen DCs aufzunehmen. Vielleicht um sich einen funktionierenden DC zu merken, falls der eigene mal nicht zur Verfügung steht?

[Daim 12]

Servus,

 

ganz nach dem Motto "zusammen sind wir startk", habe ich das mal, mit meinem MVP-Kollegen "Robert Pieroth" besprochen.

 

Seine Antwort sieht so aus:

 

Das dürfte damit zu tun haben, wie Clients einen DC zum Anmelden auffinden, gemäß: Auffinden von Domänencontrollern in Windows XP

Sie erhalten eine Liste aller DC vom DNS. Sie pingen alle in der Liste ab. Der DC in der eigenen Site wird dann natürlich zum Anmelden genommen. Aber der wird im DNS-Cache eingetragen. Dieser wird beim Herunterfahren wieder geleert und beim nächsten

Booten geht wieder eine Anfrage an alle per DNS ermittelten DC.

 

Diese kurze Anfrage an die DC ausserhalb der Site anhand der vom DNS bezogenen Liste aller DC dürfte diese Kommunikation sein, welche die Clients da aufbauen wollen.

 

Wenn die so getrennt sein wollen, wie beschrieben, hätten sie besser ihre Sites zu Subdomains gemacht, statt alle Sites in derselben Domäne zu haben.

 

 

Das deckt sich mit meiner Antwort.

 

Der Client fragt im DNS nach, welche DCs es gibt.

Die Liste aus der DNS-Antwort die der Client erhält, geht der Client durch, um einen DC zu finden der funktioniert und online ist. Bevorzugt nimmt der Client dann einen DC aus seinem Standort.

 

Der Domänencontroller reicht die Clientanfrage an seinen NETLOGON-Prozess durch, der dann die Client-IP in seiner Subnet to Site Mapping Table nachsieht und dann das treffende Site-Object heraussucht.

 

 

Der Netlogon-Prozess übergibt an den DC die folgenden Infos:

 

- Den Namen des Standorts, in der sich der befragte Domänencontroller befindet

- Den Standortnamen, in dem sich der Client befindet

- - Ein Flag das anzeigt wird, wenn sich der angefragte DC im gleichen Standort befindet (Bit gesetzt) oder ob der DC ausserhalb des Standortes ist (Bit nicht gesetzt).

 

 

Dieses Informationen werden dann an den Client gesendet, der sich nun diese Informationen näher anschaut:

 

- Wenn sich der Domänencontroller in der gleichen (oder nächstgelegenen) Standort befindet (gesetztes Bit), dann nimmt der Client bevorzugt dieses DC.

- Befindet sich kein Domänencontroller am gleichen Standort (nicht gesetztes Bit), dann weiß der Client, an welchem Standort er sich befindet und stellt erneut eine Anfrage an das DNS nach einem Domänencontroller. Wird die Anfrage erfolgreich beantwortet, nimmt der Client dieses DC.

 

Der Client der Mitglied in der Domäne ist, setzt in seiner Registry unter

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters - den Wert DynamicSiteName mit dem Standort, an dem sich der Client befindet.

 

Das ganze kann genauer, hier nachgelesen werden:

Microsoft Corporation

 

 

Ich hoffe, die Antwort erklärt einiges.

[MS-Wing 10]

Vielen Dank für die umfangreiche Antwort! :thumb1:

 

Wird es denn Deiner Meinung nach was bringen dem Microsoft KB Artikel 306602 (Section I) zu folgen. Ich erhoffe mir davon, das die Clients nur noch ihren eigenen DC und den DC in der zentralen Site in Erwägung ziehen.

[Daim 12]

Teste es einfach aus ;). Einen Versuch wäre es wert.

Der Client muss lediglich die DC-Informationen seines Standorts übermittelt bekommen und nicht die Infos der DCs, von der ganzen Domäne.

[MS-Wing 10]

Ich habe im DNS unter _tcp.domain.local und _udp.domain.local alle DNS-Records der "Satelliten"-DCs rausgeschmissen und zur Sicherheit noch ein "netdiag /fix" auf all diesen DCs ausgeführt (es wurden aber keine Fehler gefunden).

 

Ich beobachte dann mal das Firewall-Log ob noch unerwünschter Traffic zu sehen ist und melde mich dann.

 

Sascha

[Daim 12]

Ich habe im DNS unter _tcp.domain.local und _udp.domain.local alle DNS-Records der "Satelliten"-DCs rausgeschmissen und zur Sicherheit noch ein "netdiag /fix" auf all diesen DCs ausgeführt (es wurden aber keine Fehler gefunden).

 

Das wird dir nicht viel helfen. Denn nach einem Neustart des jeweiligen DCs, registriert der NETLOGON-Prozess die Einträge aus der "netlogon.dns" Datei erneut im DNS.

[MS-Wing 10]

Hmm... aber laut dem Microsoft KB Artikel soll der DnsAvoidRegisterRecords Regkey genau das verhindern. Und das tut er auch. Habe es gerade getestet.

 

Ich habe einen der Satelliten-DCs (die diesen Regkey gesetzt haben) neugestartet und die ungewollten DNS Records sind wie gewünscht nicht aufgetaucht. Ist doch genau das was wir wollen, oder? :cool:

 

Microsoft nennt diese Records: "generic (non-site-specific) domain controller locator DNS records"

[Daim 12]

Hmm... aber laut dem Microsoft KB Artikel soll der DnsAvoidRegisterRecords Regkey genau das verhindern. Und das tut er auch. Habe es gerade getestet.

 

Ahh ok. Ich dachte du versuchst das ganze ohne den Reg.-Key (den es eben zu testen galt).

 

Ich habe einen der Satelliten-DCs (die diesen Regkey gesetzt haben) neugestartet und die ungewollten DNS Records sind wie gewünscht nicht aufgetaucht. Ist doch genau das was wir wollen, oder? :cool:

 

Na wer sagts denn. Da haben wir aber Schwein gehabt :D.

 

Microsoft nennt diese Records: "generic (non-site-specific) domain controller locator DNS records"

 

Yeppahh.