16
Wie findet ein Windows(AD)-Client seinen zuständigen Domänencontroller?
Hallo,
ich "optimiere" gerade unser Firewallregelwerk. Dabei ist mir aufgefallen, dass ein Client von Standort A gelegentlich (SMB)-Kontakt zu einem DC an Standort B sucht. Das ist ja eigentlich unnötig. Der Client hat zwei DCs am Standort, allerdings nicht innerhalb seines Subnetztes. Ich werde noch mal überprüfen, ob auf dem Client irgendwelche seltsamen Einstellungen/Anwendungen aktiv sind.
Meiner Meinung nach sollte das doch nur passieren, wenn lokal kein DC erreichbar ist? Ist das tatsächlich so? Weiss jemand, wie der Client seinen zuständigen DC findet? Per DNS erhält er ja bei Abfrage des Domänennamens die Liste der DCs. Probiert der die der Reihe nach durch? Oder nimmt er an, dass der DNS-Server auch DC ist?
Bezüglich der Firewall stellt sich mir die Frage, ob für die Clients ALLE DCs einer Domäne erreichbar sein müssen.
Grüße
lcer
ich "optimiere" gerade unser Firewallregelwerk. Dabei ist mir aufgefallen, dass ein Client von Standort A gelegentlich (SMB)-Kontakt zu einem DC an Standort B sucht. Das ist ja eigentlich unnötig. Der Client hat zwei DCs am Standort, allerdings nicht innerhalb seines Subnetztes. Ich werde noch mal überprüfen, ob auf dem Client irgendwelche seltsamen Einstellungen/Anwendungen aktiv sind.
Meiner Meinung nach sollte das doch nur passieren, wenn lokal kein DC erreichbar ist? Ist das tatsächlich so? Weiss jemand, wie der Client seinen zuständigen DC findet? Per DNS erhält er ja bei Abfrage des Domänennamens die Liste der DCs. Probiert der die der Reihe nach durch? Oder nimmt er an, dass der DNS-Server auch DC ist?
Bezüglich der Firewall stellt sich mir die Frage, ob für die Clients ALLE DCs einer Domäne erreichbar sein müssen.
Grüße
lcer
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 7467563550
Url: https://administrator.de/contentid/7467563550
Ausgedruckt am: 24.11.2024 um 12:11 Uhr
16 Kommentare
Neuester Kommentar
Moin,
mit deinem Betreff und einer Suchmaschine wie Google findet man als ersten Treffer das hier: https://sid-500.com/2017/01/07/wie-findet-ein-client-einen-domain-contro ...
und als zweites etwas ausführlicher und offizieller: https://learn.microsoft.com/de-de/troubleshoot/windows-server/identity/h ...
Gruß
mit deinem Betreff und einer Suchmaschine wie Google findet man als ersten Treffer das hier: https://sid-500.com/2017/01/07/wie-findet-ein-client-einen-domain-contro ...
und als zweites etwas ausführlicher und offizieller: https://learn.microsoft.com/de-de/troubleshoot/windows-server/identity/h ...
Gruß
Wichtig ist auch, dass ihr die AD sites/subnets aktuell haltet. Sonst ist das wie bei uns und die Clients wählen erst wieder falsche DCs...
Sg Dirm
Sg Dirm
Genau, ich hätte jetzt auch darauf getippt, das die Sites nicht korrekt gepflegt sind.
Es müssen im normal Fall nicht alle DCs erreichbar sein.
Wobei dies im Failover Fall auch bei eingetragenen Subnetzen versucht wird soweit ich weiß.
Es müssen im normal Fall nicht alle DCs erreichbar sein.
Wobei dies im Failover Fall auch bei eingetragenen Subnetzen versucht wird soweit ich weiß.
Hallo,
Wenn man LDAP
aber:
Laut dem MS-Link oben:
... läuft das so ab:
Wenn ich also LDAP/UDP zu einem DC blockiere, verhindere ich, dass der Client diesen DC nutzt. ... mal sehen.
Grüße
lcer
Wenn man LDAP
Zitat von @Spirit-of-Eli:
Genau, ich hätte jetzt auch darauf getippt, das die Sites nicht korrekt gepflegt sind.
Dafür spricht, dass SMB verwendet wird .... Ich prüfe das.Genau, ich hätte jetzt auch darauf getippt, das die Sites nicht korrekt gepflegt sind.
aber:
Laut dem MS-Link oben:
The Netlogon service sends a datagram to the computers that registered the name. For NetBIOS domain names, the datagram is implemented as a mailslot message. For DNS domain names, the datagram is implemented as an LDAP User Datagram Protocol (UDP) search. (UDP is the connectionless datagram transport protocol that is part of the TCP/IP protocol suite. TCP is a connection-oriented transport protocol.)... läuft das so ab:
- Der Client erhält vom DNS-Server per DNS die Adressen aller DCs
- Der Client fragt per LDAP/UDP JEDEN DC, ob er verfügbar ist
- Der Client verbindet sich, mit dem DC der als erster antwortet und fragt erst dann das AD ab. Erst jetzt können AD-Standorte ins Spiel kommen.
Wenn ich also LDAP/UDP zu einem DC blockiere, verhindere ich, dass der Client diesen DC nutzt. ... mal sehen.
Grüße
lcer
Okay, ich habe mir das gerade folgende MS Artikel angeschaut.
https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/plan/ena ...
Demnach ist geht es hier tatsächlich nur darum, den Traffic auf die Sites zu beschränken. Vorher tritt tatsächlich immer das Scenario in Kraft, dass quasi jeder DC erreichbar sein muss.
Edit:
wobei ich mir dann echt die Frage stellen, was mir ein RODC bringen soll wenn die Clients immer alle anderen DCs erreichen müssen. Ich könnte das höchsten aufwendig per FW und APP Rule auf die entsprechenden RPC Ports beschränken.
Dein Scenario wäre ja prädestiniert für ein DMZ Konstrukt mit RODC.
https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/plan/ena ...
Demnach ist geht es hier tatsächlich nur darum, den Traffic auf die Sites zu beschränken. Vorher tritt tatsächlich immer das Scenario in Kraft, dass quasi jeder DC erreichbar sein muss.
Edit:
wobei ich mir dann echt die Frage stellen, was mir ein RODC bringen soll wenn die Clients immer alle anderen DCs erreichen müssen. Ich könnte das höchsten aufwendig per FW und APP Rule auf die entsprechenden RPC Ports beschränken.
Dein Scenario wäre ja prädestiniert für ein DMZ Konstrukt mit RODC.
Zitat von @Spirit-of-Eli:
Vorher tritt tatsächlich immer das Scenario in Kraft, dass quasi jeder DC erreichbar sein muss.
Vorher tritt tatsächlich immer das Scenario in Kraft, dass quasi jeder DC erreichbar sein muss.
ich habe das eigentlich bisher immer so verstanden, dass schlicht alle abgefragt werden, aber nicht erreichbar sein müssen. "DC" wird halt der DC, der zuerst antwortet...
Zitat von @Kraemer:
ich habe das eigentlich bisher immer so verstanden, dass schlicht alle abgefragt werden, aber nicht erreichbar sein müssen. "DC" wird halt der DC, der zuerst antwortet...
Zitat von @Spirit-of-Eli:
Vorher tritt tatsächlich immer das Scenario in Kraft, dass quasi jeder DC erreichbar sein muss.
Vorher tritt tatsächlich immer das Scenario in Kraft, dass quasi jeder DC erreichbar sein muss.
ich habe das eigentlich bisher immer so verstanden, dass schlicht alle abgefragt werden, aber nicht erreichbar sein müssen. "DC" wird halt der DC, der zuerst antwortet...
Ich eigentlich auch, aber ich finde keinen Beleg dafür. Wie gerade schon erwähnt würde alles andere aber keinen Sinn ergeben und man könnte keine DMZ Auth. mit RODC realisieren.
Hallo,
irgendwie spannend. Jeder Domänenclient wird also gelegentlich versuchen, LDAP-Pakete über UDP an jeden DC der AD-Domäne zu schicken. Sicherlich nicht besonders häufig, da der "zuständige" DC zwischengespeichert wird. Aber auf dem Schirm muss man das haben.
Grüße
lcer
irgendwie spannend. Jeder Domänenclient wird also gelegentlich versuchen, LDAP-Pakete über UDP an jeden DC der AD-Domäne zu schicken. Sicherlich nicht besonders häufig, da der "zuständige" DC zwischengespeichert wird. Aber auf dem Schirm muss man das haben.
Grüße
lcer
wo lest ihr, dass jeder DC erreichbar sein muss? Wenn das AD stehen würde, sobald ein DC nicht erreichbar wäre, wäre unser AD schon lange ganz hinüber.
Beginnt doch immer mit denen der eigenen Site.
Beginnt doch immer mit denen der eigenen Site.
Try to find a domain controller in the same site.
Hallo,
Muss offenbar nicht.
Beginnt doch immer mit denen der eigenen Site.
Eben nicht. Der Client hat keine Infos über andere Subnetze oder AD-Sites, bevor er nicht Kontakt zu einem DC hatte. Er versucht jeden DC zu kontaktieren und nimmt den, der sich zuerst zurückmeldet. Diesen fragt er nach Standorten und sucht sich dann einen passenden aus. Deshalb darf man sich nicht wundern, wenn die Firewall LDAP/UDP Datenverkehr in andere Subnetze an anderen Standorten protokolliert.
Grüße
lcer
Muss offenbar nicht.
Beginnt doch immer mit denen der eigenen Site.
Try to find a domain controller in the same site.
Grüße
lcer
Wobei das ganze glaub ich auch übers DNS laufen kann. Dort sind die Sites ja schon korrekt eingetragen.
Wenn ich wieder Zeit habe, beschäftige ich mich noch mal näher damit.
Wenn ich wieder Zeit habe, beschäftige ich mich noch mal näher damit.
Mal blöd gefragt, hat das nicht auch was mit den Einstellungen am Switch/Router zu tun - Kosten/Hops.
Zitat von @user217:
Mal blöd gefragt, hat das nicht auch was mit den Einstellungen am Switch/Router zu tun - Kosten/Hops.
Mal blöd gefragt, hat das nicht auch was mit den Einstellungen am Switch/Router zu tun - Kosten/Hops.
Mir wäre nicht mehr bekannt als das die Sites an Hand der IP bzw. Subnetz unterschieden werden. Die Einträge müssen im AD händisch angelegt werden.
Hallo,
Router veröffentlichen jedenfalls keine Routeninformationen an die Clients, höchstens an andere Router.
Grüße
lcer
Zitat von @user217:
Mal blöd gefragt, hat das nicht auch was mit den Einstellungen am Switch/Router zu tun - Kosten/Hops.
was genau - welche Einstellungen - meinst Du?Mal blöd gefragt, hat das nicht auch was mit den Einstellungen am Switch/Router zu tun - Kosten/Hops.
Router veröffentlichen jedenfalls keine Routeninformationen an die Clients, höchstens an andere Router.
Grüße
lcer
@lcer00
Es gibt bei jedem routing Kosten welche für die Strecke/Hops/Metric hinterlegt sind. Wenn diese Kosten für den lokalen DC höher sind als für den zentralen kannst du dir vorstellen was passiert..
https://de.wikipedia.org/wiki/Metrik_(Netzwerk)
Mal blöd gefragt, hat das nicht auch was mit den Einstellungen am Switch/Router zu tun - Kosten/Hops.
was genau - welche Einstellungen - meinst Du?Es gibt bei jedem routing Kosten welche für die Strecke/Hops/Metric hinterlegt sind. Wenn diese Kosten für den lokalen DC höher sind als für den zentralen kannst du dir vorstellen was passiert..
https://de.wikipedia.org/wiki/Metrik_(Netzwerk)
Zitat von @user217:
@lcer00
Es gibt bei jedem routing Kosten welche für die Strecke/Hops/Metric hinterlegt sind. Wenn diese Kosten für den lokalen DC höher sind als für den zentralen kannst du dir vorstellen was passiert..
ich kenne die Metriken, der DC aber leider nicht. Was Du hier umreißt ist kein Mechanismus, der vom Client oder vom DC verwendet wird.@lcer00
Mal blöd gefragt, hat das nicht auch was mit den Einstellungen am Switch/Router zu tun - Kosten/Hops.
was genau - welche Einstellungen - meinst Du?Es gibt bei jedem routing Kosten welche für die Strecke/Hops/Metric hinterlegt sind. Wenn diese Kosten für den lokalen DC höher sind als für den zentralen kannst du dir vorstellen was passiert..
Grüße
lcer
