20
Domain.local sysvol bei mehreren Standorten
Hallo Ihr Lieben,
ich versuche mich tiefer in das Thema "Active Directory" einzuarbeiten, da ich jetzt durch meinen neuen Arbeitgeber mit einem enorm großen System konfrontiert werde mit zig Standorten und Domain-Controllern.
Ich versuche zur Zeit herauszufinden wie ausgehandelt wird von welchem "Group Policy Server" der Client seine GPO erhält.
Der Pfad zu einer der anzuwendende GPO laut ungefähr so: \\domain.local\sysvol\domain.local\Policies\{12345....-54321}
Hinter dem Pfad \\domain.local\sysvol\... kann sich ja jeder x-beliebige DC verbergen, da es sich um einen Namespace handelt. Der DC bzw. Logonserver wird für den Client ja anhand seines Standortes ermittelt. Ist das beim "Group Policy Server" auch so? Hat jemand eine gute Quelle bei der ich das nachlesen und vertiefen kann?
Ich muss irgendwo anfangen und drehe mich zur Zeit im Kreis. Das hier (MS-GPOL) bin ich gerade am durcharbeiten, aber so richtig schlau werde ich nicht daraus, da es etwas zu tief in die Materie geht und man sich in Querverweisen verliert.
Über einen Schups in die richtige Richtung würde ich mich freuen.
Gruß vom Uhli.
ich versuche mich tiefer in das Thema "Active Directory" einzuarbeiten, da ich jetzt durch meinen neuen Arbeitgeber mit einem enorm großen System konfrontiert werde mit zig Standorten und Domain-Controllern.
Ich versuche zur Zeit herauszufinden wie ausgehandelt wird von welchem "Group Policy Server" der Client seine GPO erhält.
Der Pfad zu einer der anzuwendende GPO laut ungefähr so: \\domain.local\sysvol\domain.local\Policies\{12345....-54321}
Hinter dem Pfad \\domain.local\sysvol\... kann sich ja jeder x-beliebige DC verbergen, da es sich um einen Namespace handelt. Der DC bzw. Logonserver wird für den Client ja anhand seines Standortes ermittelt. Ist das beim "Group Policy Server" auch so? Hat jemand eine gute Quelle bei der ich das nachlesen und vertiefen kann?
Ich muss irgendwo anfangen und drehe mich zur Zeit im Kreis. Das hier (MS-GPOL) bin ich gerade am durcharbeiten, aber so richtig schlau werde ich nicht daraus, da es etwas zu tief in die Materie geht und man sich in Querverweisen verliert.
Über einen Schups in die richtige Richtung würde ich mich freuen.
Gruß vom Uhli.
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: 4493008593
Url: https://administrator.de/contentid/4493008593
Ausgedruckt am: 22.11.2024 um 17:11 Uhr
20 Kommentare
Neuester Kommentar
Oha...das .local Unwort!
Hinweise zur Verwendung der Domäne .local in DNS und mDNS
Hinweise zur Verwendung der Domäne .local in DNS und mDNS
Spielt keine Rolle. Ist sogar eine explizit supportete Konfiguration, wenn aucnicht empfohlen.
Wer löst denn in seinem Forrest über mDNS auf? Kann mir das Mal jemand erklären?
Außerdem ist .local im öffentlichen Internet, also im DNS "nach oben" nicht supported.
Entscheidend ist, dass im Forrest das DNS funktioniert und Geräte zu parallel mDNS machen, haben ganz andere Sorgen.
Wer löst denn in seinem Forrest über mDNS auf? Kann mir das Mal jemand erklären?
Außerdem ist .local im öffentlichen Internet, also im DNS "nach oben" nicht supported.
Entscheidend ist, dass im Forrest das DNS funktioniert und Geräte zu parallel mDNS machen, haben ganz andere Sorgen.
Hi,
@aqui 's Hinweis ist sicherlich nicht unbedeutend, aber für Deine Frage irrelevant.
"GPO erhalten" ist zweigeteilt. "Eine GPO" besteht aus 2 AD-Objekten und den zur GPO gehörenden Dateien.
1 AD-Objekt für die GPO
1 AD-Objekt für die GPO-Verlinkung (an Domain, OU oder Site)
1 Ordner im ...\SYSVOL\Policies
Üblicherweise bekommt ein Client beides - AD-Objekte und Dateien - vom selben DC. Aber das ist kein Muss.
Wenn die physischen Standorte mit ihren Subnetzen im AD als logische Standorte abgebildet sind, und auch die Server-Objekt der DC's diesen logischen Standorten zugeordnet sind, dann wenden sich die Clients bevorzugt an einen DC vom selben Standort, an welchem die Clients sind. Wenn da der PDC-Emulator dabei ist, dann vorzugweise an diesen. Sollte ein DC mal nicht reagieren oder erreichbar sein, dann kann es aber auch sein, dass der Zugriff über die Leitung zu einem anderen Standort geht. Oder auch dann, wenn dem logischen AD-Standort des Clients kein DC zugeordnet ist. Welcher andere Standort das dann ist, hängt von den konfigurierten Standortverknüpfungen ab (Site Links).
E.
@aqui 's Hinweis ist sicherlich nicht unbedeutend, aber für Deine Frage irrelevant.
"GPO erhalten" ist zweigeteilt. "Eine GPO" besteht aus 2 AD-Objekten und den zur GPO gehörenden Dateien.
1 AD-Objekt für die GPO
1 AD-Objekt für die GPO-Verlinkung (an Domain, OU oder Site)
1 Ordner im ...\SYSVOL\Policies
Üblicherweise bekommt ein Client beides - AD-Objekte und Dateien - vom selben DC. Aber das ist kein Muss.
Wenn die physischen Standorte mit ihren Subnetzen im AD als logische Standorte abgebildet sind, und auch die Server-Objekt der DC's diesen logischen Standorten zugeordnet sind, dann wenden sich die Clients bevorzugt an einen DC vom selben Standort, an welchem die Clients sind. Wenn da der PDC-Emulator dabei ist, dann vorzugweise an diesen. Sollte ein DC mal nicht reagieren oder erreichbar sein, dann kann es aber auch sein, dass der Zugriff über die Leitung zu einem anderen Standort geht. Oder auch dann, wenn dem logischen AD-Standort des Clients kein DC zugeordnet ist. Welcher andere Standort das dann ist, hängt von den konfigurierten Standortverknüpfungen ab (Site Links).
E.
Zitat von @emeriks:
Hi,
@aqui 's Hinweis ist sicherlich nicht unbedeutend, aber für Deine Frage irrelevant.
"GPO erhalten" ist zweigeteilt. "Eine GPO" besteht aus 2 AD-Objekten und den zur GPO gehörenden Dateien.
1 AD-Objekt für die GPO
1 AD-Objekt für die GPO-Verlinkung (an Domain, OU oder Site)
1 Ordner im ...\SYSVOL\Policies
Üblicherweise bekommt ein Client beides - AD-Objekte und Dateien - vom selben DC. Aber das ist kein Muss.
Wenn die physischen Standorte mit ihren Subnetzen im AD als logische Standorte abgebildet sind, und auch die Server-Objekt der DC's diesen logischen Standorten zugeordnet sind, dann wenden sich die Clients bevorzugt an einen DC vom selben Standort, an welchem die Clients sind. Wenn da der PDC-Emulator dabei ist, dann vorzugweise an diesen. Sollte ein DC mal nicht reagieren oder erreichbar sein, dann kann es aber auch sein, dass der Zugriff über die Leitung zu einem anderen Standort geht. Oder auch dann, wenn dem logischen AD-Standort des Clients kein DC zugeordnet ist. Welcher andere Standort das dann ist, hängt von den konfigurierten Standortverknüpfungen ab (Site Links).
E.
Hi,
@aqui 's Hinweis ist sicherlich nicht unbedeutend, aber für Deine Frage irrelevant.
"GPO erhalten" ist zweigeteilt. "Eine GPO" besteht aus 2 AD-Objekten und den zur GPO gehörenden Dateien.
1 AD-Objekt für die GPO
1 AD-Objekt für die GPO-Verlinkung (an Domain, OU oder Site)
1 Ordner im ...\SYSVOL\Policies
Üblicherweise bekommt ein Client beides - AD-Objekte und Dateien - vom selben DC. Aber das ist kein Muss.
Wenn die physischen Standorte mit ihren Subnetzen im AD als logische Standorte abgebildet sind, und auch die Server-Objekt der DC's diesen logischen Standorten zugeordnet sind, dann wenden sich die Clients bevorzugt an einen DC vom selben Standort, an welchem die Clients sind. Wenn da der PDC-Emulator dabei ist, dann vorzugweise an diesen. Sollte ein DC mal nicht reagieren oder erreichbar sein, dann kann es aber auch sein, dass der Zugriff über die Leitung zu einem anderen Standort geht. Oder auch dann, wenn dem logischen AD-Standort des Clients kein DC zugeordnet ist. Welcher andere Standort das dann ist, hängt von den konfigurierten Standortverknüpfungen ab (Site Links).
E.
Danke, das heißt also er bezieht seine Daten aus dem ..\sysvol\policy\ Ordner des Servers der ihm über "Standorte und Dienste" zugeteilt wird. Also keine Sonderbehandlung sondern es ist wie wie bei der Ermittlung des Logonservers?
Gruß, Uhli.
Mir ist gerade noch was eingefallen.
Bei Zugriff auf DFS-Stämme und -Ordner (hier SYSVOL), welche mehrere Ziele haben (hier die DC's) wird auch über die AD-Standorte priorisiert. So wie ich es oben beschrieben schon habe.
Gibt es ein DFS-Ziel an meinem AD-Standort?
Ja --> dieses bevorzugen
Nein --> anderes Ziel auswählen gemäß den AD-Standortverknüpfungen. Hier wird das nächste Ziel ausgewählt.
Bsp.
Standort A mit B verbunden, und B mit C
DFS hat Ziele in A und B
Zugriffe von einem Client von Standort C erfolgt vorzugweise über DFS-Ziel am Standort B.
Bei Zugriff auf DFS-Stämme und -Ordner (hier SYSVOL), welche mehrere Ziele haben (hier die DC's) wird auch über die AD-Standorte priorisiert. So wie ich es oben beschrieben schon habe.
Gibt es ein DFS-Ziel an meinem AD-Standort?
Ja --> dieses bevorzugen
Nein --> anderes Ziel auswählen gemäß den AD-Standortverknüpfungen. Hier wird das nächste Ziel ausgewählt.
Bsp.
Standort A mit B verbunden, und B mit C
DFS hat Ziele in A und B
Zugriffe von einem Client von Standort C erfolgt vorzugweise über DFS-Ziel am Standort B.
Also keine Sonderbehandlung sondern es ist wie wie bei der Ermittlung des Logonservers?
Weil hier DC's und DFS-Ziele deckungsgleich sind - ja.
Wenn in deiner Domäne der Punkt "IP und Standorte" richtig konfiguriert ist, sollte er immer den lokalen DC adressieren. Oder sieht das jemand anders hier ? https://www.youtube.com/watch?v=Hk_nrQ6T_sE
Zitat von @2423392070:
Wer löst denn in seinem Forrest über mDNS auf? Kann mir das Mal jemand erklären?
Wer löst denn in seinem Forrest über mDNS auf? Kann mir das Mal jemand erklären?
Genau das ist ja das Problem: Nachdem .local per Standard für mDNS reserviert ist, macht ein Client alles richtig, wenn er nicht per Unicast sondern ausschließlich per mDNS nach Hostnames unterhalb .local fragt.
löst deine Domain halt nicht mehr auf.
Und es sei dennoch nochmal der Hinweis gestattet, dass auch Microsoft explizit auf rotem Hintergrund davon abrät, .local zu verwenden.
Natürlich ist es jedem freigestellt, Internetstandards und Hinweise des Herstellers zu interpretieren wie man mag.
1
Welche Client macht das wann im Netzwerk einfach so?
Willst du mir etwas von dem 99 Euro HP Drucker jetzt erzählen?
Willst du mir etwas von dem 99 Euro HP Drucker jetzt erzählen?
Hast du auch mal gelesen was da beschrieben ist? Da ist eine Fehlkonfiguration beschrieben.
Zitat von @LordGurke:
Nachdem .local per Standard für mDNS reserviert ist, macht ein Client alles richtig, wenn er nicht per Unicast sondern ausschließlich per mDNS nach Hostnames unterhalb .local fragt.
Unabhängig davon, dass ich jetzt nicht genau weiß, ob dass so konkret, wie Du das behauptest, richtig ist. Wenn überhaupt, dann trifft das meines Wissens aber auch nur für Namen in der ersten Ebene unterhalb von .local zu. Und auch nur für Namen, welchen keinen Punkt enthalten.Nachdem .local per Standard für mDNS reserviert ist, macht ein Client alles richtig, wenn er nicht per Unicast sondern ausschließlich per mDNS nach Hostnames unterhalb .local fragt.
Wenn Windows-Clients konkret nach "meinedomäne.local" schreien, dann tun sie das nicht über mDNS sondern explizit über DNS. Und für Namen ohne Punkt hat Windows - andere OS bestimmt auch - einen Mechanismus, bei welchen die konfigurierten DNS-Suffixe an solche angehängt werden und dann damit versucht wird, explizit über DNS aufzulösen.
Meine Empfehlung ist:
Wenn man etwas neu aufsetzt, dann sollte man .local nicht nehmen.
Wenn man .local bereits im Einsatz hat, dann sollte man keine DNS-Zone "local." betreiben, um dann in dieser Delegierungen für z.B. "meinedomäne.local." bereitzustellen oder gar eine komplette Subdomain dafür. Dann sollte man für jede *.local-Domain eine eigene DNS-Zone pflegen.
Wir betreiben - historisch gewachsen - ein ganzes Rechenzentrum mit AD-Domänen "*.local". Und hier gibt es deswegen Null Probleme.
Zitat von @2423392070:
Hast du auch mal gelesen was da beschrieben ist?
Sicher!Hast du auch mal gelesen was da beschrieben ist?
Da ist eine Fehlkonfiguration beschrieben.
Nein, das ist keine Fehlkonfiguration sondern das waren Betriebssystem-Standards die ein Auflösen von .local per mDNS priorisieren!Sicher kann man allen OS beibringen mDNS mit niedrigerer Priorität zu verarbeiten aber das benötigt nunmal einen Eingriff und ist eben meist nicht der Default.
Denn deine Frage lautete ja :
Welche Client macht das wann im Netzwerk einfach so?
Und das macht dieser Client eben per Default "einfach so " wenn man ihn nicht entsprechend umkonfiguriert!1
Alles klar. Ein Admin betreibt, einfach so und per default in seinem Netzwerk Anycast und Multicast DNS in seinem Netzwerk, wobei Multicast DNS sich auch noch seine Konfig selber orakeln darf.
Heute ist Freitag?
Heute ist Freitag?
Zitat von @2423392070:
Alles klar. Ein Admin betreibt, einfach so und per default in seinem Netzwerk Anycast und Multicast DNS in seinem Netzwerk, wobei Multicast DNS sich auch noch seine Konfig selber orakeln darf.
Heute ist Freitag?
Alles klar. Ein Admin betreibt, einfach so und per default in seinem Netzwerk Anycast und Multicast DNS in seinem Netzwerk, wobei Multicast DNS sich auch noch seine Konfig selber orakeln darf.
Heute ist Freitag?
Stelle deine Fragen vernünftig dann bekommst du auch passende Antworten, auch am Freitag 😁🖖
Nein, erzähle doch einfach keinen Quatsch. Überlege mal was du erzählst. Ich halte die Pistole falsch herum und der alle anderen außer der Schütze sind schuld.
Dachte du wolltest behauptet Admin zu sein. Habe ich ich dich wohl verwechselt.
Dachte du wolltest behauptet Admin zu sein. Habe ich ich dich wohl verwechselt.
Zitat von @2423392070:
Nein, erzähle doch einfach keinen Quatsch.
Ist kein Quatsch sondern Fakt.Nein, erzähle doch einfach keinen Quatsch.
Dachte du wolltest behauptet Admin zu sein. Habe ich ich dich wohl verwechselt.
Sorry das ich den Troll in dir nicht gesehen habe ...
Eh Leute, bleibt sachlich!
Was mir gerade noch einfällt:
Wir haben bei uns im Netz auch Android- und Apple-Tablets im Einsatz, welche diverse interne Applikationen nutzen, die dafür über WebBrowser bereitgestellt werden. Wir wissen, dass dort der Aufruf dieser Seiten dann nicht über FQDN aus unseren *.local-Domänen funktioniert. Egal ob mit Proxy oder ohne. Solche Dienste haben wir dafür explizit über FQDN aus anderen internen DNS-Domains ohne ".local" bereitgestellt. Aber das hat nichts mit MS Active Directory zu tun! Das muss man bei diesem Thema klar differenzieren.
Was mir gerade noch einfällt:
Wir haben bei uns im Netz auch Android- und Apple-Tablets im Einsatz, welche diverse interne Applikationen nutzen, die dafür über WebBrowser bereitgestellt werden. Wir wissen, dass dort der Aufruf dieser Seiten dann nicht über FQDN aus unseren *.local-Domänen funktioniert. Egal ob mit Proxy oder ohne. Solche Dienste haben wir dafür explizit über FQDN aus anderen internen DNS-Domains ohne ".local" bereitgestellt. Aber das hat nichts mit MS Active Directory zu tun! Das muss man bei diesem Thema klar differenzieren.
@2423392070:
Nach deinen Ausführungen hier scheint mir, du hast keine Ahnung was mDNS ist oder dass es ein verdammter weltweiter Standard ist, .local immer und ungefragt über mDNS aufzulösen. OHNE DASS MAN ES KONFIGURIEREN MUSS, denn das ist ja Sinn der Sache.
Und Systeme, die sich konform nach RFC6762 verhalten, sind mitnichten "falsch konfiguriert", sie verhalten sich standardkonform.
Deine Argumentation hört sich ein bisschen an wie "Ich benutze jetzt hier fürs Netzwerk das Präfix 224.1.2.0/24 weil ich kann mir frei aussuchen, welche Adressen ich benutze und wenn irgendwelche Geräte dann mein Netzwerk nicht mehr erreichen können, dann liegt das nicht daran, dass ich einen für Multicast reservierten Bereich genommen habe sondern die Geräte sind alle falsch konfiguriert!"
Nach deinen Ausführungen hier scheint mir, du hast keine Ahnung was mDNS ist oder dass es ein verdammter weltweiter Standard ist, .local immer und ungefragt über mDNS aufzulösen. OHNE DASS MAN ES KONFIGURIEREN MUSS, denn das ist ja Sinn der Sache.
Und Systeme, die sich konform nach RFC6762 verhalten, sind mitnichten "falsch konfiguriert", sie verhalten sich standardkonform.
Deine Argumentation hört sich ein bisschen an wie "Ich benutze jetzt hier fürs Netzwerk das Präfix 224.1.2.0/24 weil ich kann mir frei aussuchen, welche Adressen ich benutze und wenn irgendwelche Geräte dann mein Netzwerk nicht mehr erreichen können, dann liegt das nicht daran, dass ich einen für Multicast reservierten Bereich genommen habe sondern die Geräte sind alle falsch konfiguriert!"
3Zitat von @LordGurke:
@2423392070:
Nach deinen Ausführungen hier scheint mir, du hast keine Ahnung was mDNS ist oder dass es ein verdammter weltweiter Standard ist, .local immer und ungefragt über mDNS aufzulösen. OHNE DASS MAN ES KONFIGURIEREN MUSS, denn das ist ja Sinn der Sache.
Und Systeme, die sich konform nach RFC6762 verhalten, sind mitnichten "falsch konfiguriert", sie verhalten sich standardkonform.
Deine Argumentation hört sich ein bisschen an wie "Ich benutze jetzt hier fürs Netzwerk das Präfix 224.1.2.0/24 weil ich kann mir frei aussuchen, welche Adressen ich benutze und wenn irgendwelche Geräte dann mein Netzwerk nicht mehr erreichen können, dann liegt das nicht daran, dass ich einen für Multicast reservierten Bereich genommen habe sondern die Geräte sind alle falsch konfiguriert!"
@2423392070:
Nach deinen Ausführungen hier scheint mir, du hast keine Ahnung was mDNS ist oder dass es ein verdammter weltweiter Standard ist, .local immer und ungefragt über mDNS aufzulösen. OHNE DASS MAN ES KONFIGURIEREN MUSS, denn das ist ja Sinn der Sache.
Und Systeme, die sich konform nach RFC6762 verhalten, sind mitnichten "falsch konfiguriert", sie verhalten sich standardkonform.
Deine Argumentation hört sich ein bisschen an wie "Ich benutze jetzt hier fürs Netzwerk das Präfix 224.1.2.0/24 weil ich kann mir frei aussuchen, welche Adressen ich benutze und wenn irgendwelche Geräte dann mein Netzwerk nicht mehr erreichen können, dann liegt das nicht daran, dass ich einen für Multicast reservierten Bereich genommen habe sondern die Geräte sind alle falsch konfiguriert!"
Diese Vorhaltung muss ich dir auch machen.
Deine Clients senden ihren Uni/Anycast DNS lookup an 224.0.0.251 oder ::FB?
Wenn ich keine NetBIOS oder LLMNR Auflösung mehr habe, dann Fragen deine Clients per Multicast-DNS anstelle per Unicast nach? Warum, wenn das eine falsche Konfig ist und die .local-Auflösung des AD DS die Methode Wahl ist?
Es ist eine Fehlkonfiguration wenn die zur Koexistenz entworfenen Protokolle, die unterschiedliche Zwecke haben, sich auf diese Weise stören, bzw ist eine falsch konfigurierte Software auf dem Client der Störer, weil sie den falschen Weg nutzt.
Und wenn meine Geräte sich dann "frei aussuchen" ob die Multicasten, wenn der Unicast-DNS nicht mehr antwortet und andere Geräte eingehend diese UDP-Verbindungen akzeptieren und vor allem richtig beantworten, dann ist das eine "richtige" Konfiguration, hat aber nichts mit den FQD-Names der Auflösungen zu tun, die nicht über DNS kommen aber vom mDNS aufgelöst werden könnten.
Zitat von @emeriks:
Eh Leute, bleibt sachlich!
Was mir gerade noch einfällt:
Wir haben bei uns im Netz auch Android- und Apple-Tablets im Einsatz, welche diverse interne Applikationen nutzen, die dafür über WebBrowser bereitgestellt werden. Wir wissen, dass dort der Aufruf dieser Seiten dann nicht über FQDN aus unseren *.local-Domänen funktioniert. Egal ob mit Proxy oder ohne. Solche Dienste haben wir dafür explizit über FQDN aus anderen internen DNS-Domains ohne ".local" bereitgestellt. Aber das hat nichts mit MS Active Directory zu tun! Das muss man bei diesem Thema klar differenzieren.
Eh Leute, bleibt sachlich!
Was mir gerade noch einfällt:
Wir haben bei uns im Netz auch Android- und Apple-Tablets im Einsatz, welche diverse interne Applikationen nutzen, die dafür über WebBrowser bereitgestellt werden. Wir wissen, dass dort der Aufruf dieser Seiten dann nicht über FQDN aus unseren *.local-Domänen funktioniert. Egal ob mit Proxy oder ohne. Solche Dienste haben wir dafür explizit über FQDN aus anderen internen DNS-Domains ohne ".local" bereitgestellt. Aber das hat nichts mit MS Active Directory zu tun! Das muss man bei diesem Thema klar differenzieren.
Und nicht nur mit dem MS AD nicht.
Ich habe heute Mittag alle meine Admins in der Runde mal gefragt wer seine Clients ohne Einwirkung auf den mDNS-Cleint in seinem Netzwerk toleriert...
Abgesehen von Amok-Druckern oder blöder Apple-Software ist in jedem gepflegten Netzwerk eine bewusst konfigurierte und durchdacht gepflegt DNS-Struktur vorhanden und mDNS macht was es soll.
Es ist wirklich bedenklich, was es hier zu lesen gibt. Vermutlich ist auch auch NetBIOS und LLMNR am wirken, weile eine RFC sie mal erwähnt hat.
Ich habe aber auch was gelenrt und gebe Dienstag eine Erweiterung unserer Fremdfirmenrichtlinien in Arbeit beim QM. Ich dass ein Admin von hier uns einen Nicht-Domain--Cleint liefert, dass mich Multicastet.
