Muffel 11 Geschrieben 8. Oktober 2010 Melden Teilen Geschrieben 8. Oktober 2010 Ein AD soll implementiert werden. Es wurde entschieden eine einzelne Domain einzurichten (also keine Subdomains). In der Planung wurden keine verschiedenen Standorte berücksichtigt, es gibt also nur einen, also alle Arbeitsplätze befinden sich im gleichen AD-Standort. Ich denke man sollte doch Standorte definieren. Woher weiß aber nun ein Client, der sich in einem nicht definierten IP-Netz befindet, wer sein Ansprechpartner ist? Kann man so etwas wie einen Default-DC festlegen, also einen DC, der für Anfragen von "undefinierten IP-Subnetzen" zuständig ist? Wenn ja wo ist was einzustellen? Zitieren Link zu diesem Kommentar
Daim 12 Geschrieben 8. Oktober 2010 Melden Teilen Geschrieben 8. Oktober 2010 Servus, Ich denke man sollte doch Standorte definieren. warum denkst du das? Woher weiß aber nun ein Client, der sich in einem nicht definierten IP-Netz befindet, wer sein Ansprechpartner ist? DNS, DNS und nochmal DNS. Der Client versucht zuerst einen DC, an "seinem" AD-Standort zu erreichen. Wenn der Client nicht weiß zu welchem AD-Standort er gehört, wie es z.B. bei einem neu installierten Client auch der Fall sein kann, sucht er Dank des DNS nach einem DC in der Domäne. Dann kontaktiert der Client irgendeinen DC der egal an welchem AD-Standort steht. Aber erreichen kann der Client in jedem Fall einen DC. Siehe dazu (bitte lesen): LDAP://Yusufs.Directory.Blog/ - Domänencontroller am Standort Kann man so etwas wie einen Default-DC festlegen, also einen DC, der für Anfragen von "undefinierten IP-Subnetzen" zuständig ist? Wenn ja wo ist was einzustellen? Du suchst das Catch-all Subnetz! Zitieren Link zu diesem Kommentar
dmetzger 10 Geschrieben 14. Oktober 2010 Melden Teilen Geschrieben 14. Oktober 2010 Kann man so etwas wie einen Default-DC festlegen, also einen DC, der für Anfragen von "undefinierten IP-Subnetzen" zuständig ist? Wenn ja wo ist was einzustellen? Ein verbreiteter Ansatz für grössere Umgebungen (viele Standorte mit und ohne DCs) findet sich hier: How to optimize the location of a domain controller or global catalog that resides outside of a client's site "To Configure Domain Controllers or global catalogs to Not Register Generic Records" Zitieren Link zu diesem Kommentar
Daim 12 Geschrieben 14. Oktober 2010 Melden Teilen Geschrieben 14. Oktober 2010 Servus, Ein verbreiteter Ansatz für grössere Umgebungen (viele Standorte mit und ohne DCs) findet sich hier: ich kann dir nicht ganz folgen. Im Fall des OP geht es darum, dass der Client nicht weiß in welchem Subnetz er sich befindet. Aber einen DC findet der Client letztlich ohnehin, da er diese Abfrage stellt: _ldap._tcp.dc._msdcs.<Domäne>. Was bringt der Registry-Eintrag "DnsAvoidRegisterRecords" dem OP? Zitieren Link zu diesem Kommentar
NilsK 2.930 Geschrieben 14. Oktober 2010 Melden Teilen Geschrieben 14. Oktober 2010 Moin, wie groß ist denn die Umgebung? Gibt es überhaupt mehrere Netzwerkstandorte? Wenn ja: Mit oder ohne DCs? Gruß, Nils Zitieren Link zu diesem Kommentar
dmetzger 10 Geschrieben 14. Oktober 2010 Melden Teilen Geschrieben 14. Oktober 2010 ich kann dir nicht ganz folgen. Im Fall des OP geht es darum, dass der Client nicht weiß in welchem Subnetz er sich befindet. Aber einen DC findet der Client letztlich ohnehin, da er diese Abfrage stellt: _ldap._tcp.dc._msdcs.<Domäne>. Du hast selbstverständlich Recht, dass der Client immer einen DC findet, sofern Netzwerkkonnektivität zu mindestens einem DC besteht. Andererseits wissen wir, dass jeder DC generische SRV-Einträge in der _msdcs.<Domäne>-Zone registriert, falls nicht anders konfiguriert. Der DC, den unser herumirrender Client findet, kann demnach auch irgendwo am anderen Ende der Welt an einem untergeordneten Standort stehen, gefunden über die generischen SRV-Einträge. Die ursprüngliche Frage von Muffel bezieht sich darauf, einen Standard-DC für Clients festzulegen, die in einem nicht zugeordneten Subnetz aufstarten. Schränke ich die Registrierung generischer SRV-Einträge z.B. auf DCs ein, die in gut vernetzten Standorten (vorzugsweise Hubs) stehen, wird sich unser Client mit diesen verbinden statt mit irgendeinem DC in irgendeiner Nebenstelle. Ist das so nachvollziehbar? Und selbstverständlich gibt es auch AutoSiteCoverage für Standorte ohne DCs. Ich denke aber, dass das hier nicht das Thema ist, sondern wir von einem nicht fertig konfigurierten Standort (lokales Subnetz nicht zugeordnet) ausgehen und nur einfach mal verhindern wollen, dass unser Client sich unkontrolliert mit irgendeinem DC irgendwo auf der Welt einlässt:wink2: Auch wenn es ggf. nicht EIN Standard-DC ist, sondern mehrere, aber kontrolliert an bestimmten Standorten. Ganz bestimmt ist aber die von NilsK gestellte Umgebungsfrage nach der logischen und physischen Toplogie respektive die Antworten ausschlaggebend, welches Verfahren das geeignete ist. In grösseren Umgebungen mit vielen Standorten ist die Einschränkung der Registrierung generischer SRV-Einträge üblich und nötig. Bei zwi oder drei Standorten mit schnellen WAN-Verbindungen lohnt sich der Aufwand nicht. Am einfachsten ist es, wie Muffel vermutet, die Standorte sauber mit zugeordneten Subnetzen zu konfigurieren. Dann hätten wir aber nicht diese nette Unterhaltung:) Zitieren Link zu diesem Kommentar
Daim 12 Geschrieben 14. Oktober 2010 Melden Teilen Geschrieben 14. Oktober 2010 Du hast selbstverständlich Recht Das wollte ich doch hören. :cool: Andererseits wissen wir, dass jeder DC generische SRV-Einträge in der _msdcs.<Domäne>-Zone registriert, falls nicht anders konfiguriert. Der DC, den unser herumirrender Client findet, kann demnach auch irgendwo am anderen Ende der Welt an einem untergeordneten Standort stehen, gefunden über die generischen SRV-Einträge. Genau, am Ende findet der Client dann doch einen DC, auch wenn dieser suboptimal (Bandbreite, Leitungskosten) zum Client steht. Die ursprüngliche Frage von Muffel bezieht sich darauf, einen Standard-DC für Clients festzulegen, die in einem nicht zugeordneten Subnetz aufstarten. Schränke ich die Registrierung generischer SRV-Einträge z.B. auf DCs ein, die in gut vernetzten Standorten (vorzugsweise Hubs) stehen, wird sich unser Client mit diesen verbinden statt mit irgendeinem DC in irgendeiner Nebenstelle. Klar, in diesem Szenario kann das durchaus Sinn machen. Das kommt wie immer, auf die Umgebung an. Ob nun das Einschränken der Registrierung generischer SRV-Einträge oder ein Catch-all Subnet das geeignete ist, müsste man dazu dann genauer die Umgebung inspizieren. Ist das so nachvollziehbar? Jetzt ja! Und selbstverständlich gibt es auch AutoSiteCoverage für Standorte ohne DCs. Ich denke aber, dass das hier nicht das Thema ist, sondern wir von einem nicht fertig konfigurierten Standort (lokales Subnetz nicht zugeordnet) ausgehen und nur einfach mal verhindern wollen, dass unser Client sich unkontrolliert mit irgendeinem DC irgendwo auf der Welt einlässt:wink2: Das denke ich auch. Das skizzierte Szenario hier, wird auf den OP kaum zutreffen. Aber dazu kann dann ja der OP noch was dazu schreiben. In grösseren Umgebungen mit vielen Standorten ist die Einschränkung der Registrierung generischer SRV-Einträge üblich und nötig. Üblich? Kommt darauf an. Nötig? Kommt auf die Umgebung und vor allem auf die zur Verfügung stehende Bandbreite an. :p Bei zwi oder drei Standorten mit schnellen WAN-Verbindungen lohnt sich der Aufwand nicht. Am einfachsten ist es, wie Muffel vermutet, die Standorte sauber mit zugeordneten Subnetzen zu konfigurieren. Auch hier ist es wichtig zu wissen, um welche Umgebung es sich handelt. Wenn es sich um zwei-drei physikalische Standorte handelt, in denen jeweils vielleicht 20 User sitzen, die nichts anderes machen als sich über die Leitung an der Domäne zu authentisieren, dann genügt auch ein einziger AD-Standort. Aber auch hier kommt es wie so oft und wie wir es wissen, auf die Umgebung und das Ziel an. Dann hätten wir aber nicht diese nette Unterhaltung:) So isses. ;) Zitieren Link zu diesem Kommentar
Empfohlene Beiträge
Schreibe einen Kommentar
Du kannst jetzt antworten und Dich später registrieren. Falls Du bereits ein Mitglied bist, logge Dich jetzt ein.