Domäne mit mehreren Standorten

[Sascha321 12]

Hallo

 

sagen wir mal ich habe 5 Standorte irgendwo auf der Welt, wie würdet ihr das Netzwerk aufbauen? Mir geht es um die frage Subdomäne oder nicht.

[Ivey 10]

Hallo,

im normalfall, macht man das mit subdomains, also, jeder standort bekommt eine subdomain und diese werden unter einem forest zusammengefasst. von der einrichtung her, musst du halt schauen, was du für Internetleitungen hast, dann kannst du die AD-Replikation für die einzelnen Standorte explizit konfigurieren

[Sascha321 12]

Hallo

 

macht eine grosse Domäne keinen sinn mehr? also keine Subdomänen

[Daim 12]

Salut,

 

sagen wir mal ich habe 5 Standorte irgendwo auf der Welt, wie würdet ihr das Netzwerk aufbauen? Mir geht es um die frage Subdomäne oder nicht.

 

wenn es keinen trifftigen Grund für weitere Domänen gibt, würde ich das Ein-Domänenmodell empfehlen.

Das erleichtert die Administration ungemein.

 

Der Nachteil bei mehreren Domänen wäre:

 

- Bei mehreren Domänen ist der adminstrative Aufwand Updates,Virenscanner usw.) höher, da auch jede Domäne zwei DCs haben sollte.

- Dadurch entstehen hohe Hardware- sowie Lizenzkosten.

- Jeder DC sollte/muss vor Ort physikalisch geschützt sein.

- Jede Domäne muss gesichert werden (Backup).

 

Die Vorteile bei mehreren Domänen wären, wenn man z.B. unterschiedliche

DNS-Namensräume haben möchte. Oder unterschiedliche Administratoren sollen "nur" ihre eigene Domäne verwalten und nur dort der Admin sein. Mit mehreren Domänen kann man unterschiedliche Kennwortrichtlinien anwenden (unter Windows Server 2008 gibt es die Password Settings Objects).

 

Der Vorteil einer Domäne wäre z.B. das man nur eine DNS-Zone/Domäne verwalten muss. Mit einer Domäne hat man eine bessere Übersicht und leichtere Administration. Rechte können im AD gezielt an die enbtsprechenden Personen delegiert werden.

 

Aber AD-Standorte würde ich auf alle Fälle für jeden physikalischen Standort erstellen.

 

Ich persönlich tendiere gerne zu dem Ein-Domänen-Modell, aber das kommt immer auf die Gegebenheiten darauf an.

Evtl. solltet ihr euch dazu einen Dienstleister zur Seite holen.

[NilsK 2.971]

Moin,

 

im normalfall, macht man das mit subdomains, also, jeder standort bekommt eine subdomain und diese werden unter einem forest zusammengefasst.

 

nö. Die übliche Empfehlung ist eine Single Domain. Die Standorte bildet man im AD als Sites ab. Subdomänen bringen für eine reine Standortanbindung keinen Vorteil, aber eine Menge Nachteile.

 

faq-o-matic.net Welches Domänenmodell ist das Beste für Active Directory?

 

Gruß, Nils

PS. Deine Shift-Taste scheint defekt zu sein.

[frommi 10]

Hallo

 

sagen wir mal ich habe 5 Standorte irgendwo auf der Welt, wie würdet ihr das Netzwerk aufbauen? Mir geht es um die frage Subdomäne oder nicht.

 

<what Yusuf said>.

 

Bleib bei einer Domäne mit mehreren Standorten, wenn du die Standorte nicht aus sicherheitstechnischen Gründen trennen musst (andere Passpolicies/KRB Richtlinien/Geheimhaltung und getrennte Administration). Die Kosten für den Mehraufwand für verschiedene Domänen in den Standorten rechnet sich gar nicht. Bedenke, dass du eigentlich pro Domäne zwei Domänencontroller aufstellen musst, um dich zumindest geringfügig vor Hardwareausfällen zu schützen. Je nach Architektur und Verfügbarkeit/Geschwindigkeit der Leitungen brauchst du in den Remotestandorten unter Umständen gar keinen DC oder es würde ein 2008-RODC reichen.

 

"Administration" ist kein Grund für die Aufsplittung von Standorten in Domänen - dafür gibts Rechtedelegation.

 

Cheers,

 

F.

[rep 10]

Wie sieht es denn aus wenn man bei der Site (längere Replikationsintervale) an zwei Standorten das PW ändert. Oder werden diese Einträge auch Sofort repliziert.

 

Oder was ist wenn man das machen würde wenn gerade die WAN strecke ausgefallen ist? Gibt es dann Fehler, kann man diese korregieren. Solche Fehler würden bei einer Subdomain doch nicht eintreten, oder?

[Daim 12]

Wie sieht es denn aus wenn man bei der Site (längere Replikationsintervale) an zwei Standorten das PW ändert. Oder werden diese Einträge auch Sofort repliziert.

 

Wenn der Benutzer1 am Standort1 sein Kennwort am DC1 ändert, pusht der DC1 das Kennwort über den sicheren Kanal zeitnah an den PDC-Emulator der in der Zentrale steht. Wenn der Benutzer1 nun zum Standort2 fährt und sich vor Ort an dem DC2 authentifizieren will, der noch nicht das neue Kennwort des Benutzers kennt, fragt der DC2 zuerst beim PDC-Emulator nach ob sich das Kennwort von dem Benutzer geändert hat.

 

 

Oder was ist wenn man das machen würde wenn gerade die WAN strecke ausgefallen ist? Gibt es dann Fehler, kann man diese korregieren.

 

Wenn vor Ort kein DC stehen würde und zum Zeitpunkt der Anmeldung die WAN-Leitung down ist, kann sich der Benutzer nicht an der Domäne, sondern nur mit seinen zwischengespeicherten Benutzerinformationen anmelden. Befindet sich ein DC vor Ort und die Leitung ist dwon, kann sich der Benutzer ganz normal anmelden. Was schief gehen würde solange die Leitung down ist, wäre z.B. die AD-Replikation. Eine absehbare Unterbrechung der Leitung stellt ansonsten kein Problem dar.

 

Solche Fehler würden bei einer Subdomain doch nicht eintreten, oder?

 

Doch, auch bei mehreren Subdomänen würde die Replikation fehlschlagen, wenn die Leitung down wäre. Denn schließlich wird die Schema-, Konfigurations- oder Anwendungsverzeichnispartitionen auf alle DCs (egal in welcher Domäne) in der Gesamtstruktur repliziert.

[frommi 10]

Wie sieht es denn aus wenn man bei der Site (längere Replikationsintervale) an zwei Standorten das PW ändert. Oder werden diese Einträge auch Sofort repliziert.

 

Nein, das wird nicht sofort repliziert. Passwortänderungen halten sich an die Replikationsintervalle und werden erst mit der normalen Replikation zwischen den Standorten aktualisiert (Ausnahme ist der PDCEmulator - der kriegt den Passwortwechsel sofort mit). Das ist das Standardverhalten. Du könntest das auch ändern: Stichwort wäre Intersite change notification (NilsK: gibts dazu schon was auf faq-o-matic? ;-). Aber dazu brauchst du eine verlässliche und schnelle Leitung, weil damit die Replikationsintervalle faktisch wegfallen und alles direkt repliziert wird (etwa wie Intra-site).

 

Oder was ist wenn man das machen würde wenn gerade die WAN strecke ausgefallen ist? Gibt es dann Fehler, kann man diese korregieren. Solche Fehler würden bei einer Subdomain doch nicht eintreten, oder?

 

Naja, es gibt Replikationsfehler, die du hoffentlich bemerkst und behebst. Solche Probleme hättest du mit einer Subdomain nicht - wobei eine ausgefallene Strecke zwischen Sub und Root zu anderen Problemen führen kann (je nach dem, ob Benutzer auf Dienste in der Root) zugreifen. DAS Problem könntest du mit einer Subdomain lösen. Ausgefallene WAN-Strecken sollten aber eigentlich nicht vorkommen. Und wenn das passiert, hast du im Regelfall auch andere Probleme ;-)

 

cheers,

 

F.

[rep 10]

Klar, verstanden, ich meinte nur wenn die Strecke down ist, also keien Replikation laufen kann (in der Zeit) aber an beiden Standorten (selbe Domain) das gleiche Object (Benutzer) geändert wird.

 

Dann will er doch in beidr Richtungen Replizieren, und hat an beiden Seiten eine Änderung, wie macht der das? Gewinnt die neuere. Oder muss der PDC Master die Kennwortänderung bestätigen, hat also das letzet Wort. Dann dürfte aber ohne WAN strecke der Benutzer in dem Standrot wo der DC ohne PDC-Master steht keine Änderung machen können solange dieser nicht erreichbar ist.

 

Oder? Also zwei Standorte, eine Domain, zwei DCs, je Standort ein DC.

[Daim 12]

Stichwort wäre Intersite change notification (NilsK: gibts dazu schon was auf faq-o-matic? ;-). Aber dazu brauchst du eine verlässliche und schnelle Leitung, weil damit die Replikationsintervalle faktisch wegfallen und alles direkt repliziert wird (etwa wie Intra-site).

 

Eben. Das Replikationsaufkommen müsste dann genauer untersucht werden.

Nur wenn es wirklich notwendig ist, dass jede Änderung sofort standortübergreifend repliziert werden muss, nur dann sollte man darüber nachdenken die Änderungsbenachrichtigung auch standortübergreifend zu konfigurieren.

 

Yusufs Directory Blog - Die Inter-Site (standortübergreifende) Änderungsbenachrichtigung aktivieren

 

 

Solche Probleme hättest du mit einer Subdomain nicht

 

Doch, hätte er auch. Z.B. mit der DNS-Anwendungsverzeichnispartition "_msdcs.Root-Domäne" die bekanntermaßen ab Windows Server 2003 in der Gesamtstruktur repliziert wird. Ober aber auch die Konfigurationspartition.

[frommi 10]

Heho,

 

Eben. Das Replikationsaufkommen müsste dann genauer untersucht werden.

Nur wenn es wirklich notwendig ist, dass jede Änderung sofort standortübergreifend repliziert werden muss, nur dann sollte man darüber nachdenken die Änderungsbenachrichtigung auch standortübergreifend zu konfigurieren.

 

Yusufs Directory Blog - Die Inter-Site (standortübergreifende) Änderungsbenachrichtigung aktivieren

 

Ohne den Artikel jetzt genauer studiert zu haben (was ich mit Sicherheit in der Mittagspause nachholen werde ;): sooo viel Replikationstraffic im täglichen Einsatz entsteht normalerweise nicht, als dass man das Feature bei anständigen Leitungen (>=DSL) aktivieren könnte. Kritischer und nervender fände ich das Ganze, wenn die Leitung nicht ständig zur Verfügung steht. Dann pinseln dir die DCs den Eventlog voll. Von blind aktivieren des Features war ja auch nicht die Rede. Natürlich machts keinen Sinn das Ding beim Einsatz von 64k-Leitungen zu aktivieren...

 

Doch, hätte er auch. Z.B. mit der DNS-Anwendungsverzeichnispartition "_msdcs.Root-Domäne" die bekanntermaßen ab Windows Server 2003 in der Gesamtstruktur repliziert wird. Ober aber auch die Konfigurationspartition.

 

Mit meinem Satz "Solche Probleme..." bezog ich mich mit dem Wort "solche" auf Probleme, die das Replizieren von Passwortänderungen bedingen. Dass ForestDNS, sowie Config und Schema und weitere NCs beim WAN-Ausfall in Mitleidenschaft gezogen werden können, ist schon klar. Ich bezog den zweiten Absatz ebenfalls auf die Passwortsache, nicht auf die Replikation allgemein.

 

cheers,

 

F.

[Daim 12]

Dann will er doch in beidr Richtungen Replizieren, und hat an beiden Seiten eine Änderung, wie macht der das? Gewinnt die neuere.

 

Einen Replikationskonflikt löst AD folgendermaßen:

 

Yusufs Directory Blog - Active Directory-Replikationskonflikt

 

Oder muss der PDC Master die Kennwortänderung bestätigen, hat also das letzet Wort.

 

Im Fall des Kennworts kann man das so sagen.

 

Dann dürfte aber ohne WAN strecke der Benutzer in dem Standrot wo der DC ohne PDC-Master steht keine Änderung machen können solange dieser nicht erreichbar ist.

 

Doch, natürlich. Das Kennwort kann an jedem DC geändert werden.

Seit es das AD gibt existiert doch eine Multimaster-Replikation.

 

 

–

 

 

sooo viel Replikationstraffic im täglichen Einsatz entsteht normalerweise nicht, als dass man das Feature bei anständigen Leitungen (>=DSL) aktivieren könnte.

 

Das kann man nicht so pauschal beurteilen. In den meisten Umgebungen stimmt das sicherlich. Aber je nachdem wie groß die Firma ist und wie AD-lastig gearbeitet wird, kann das schon Replikationslast erzeugen. Daher gilt es dann in solchen Umgebungen das genauer zu untersuchen.

 

Kritischer und nervender fände ich das Ganze, wenn die Leitung nicht ständig zur Verfügung steht. Dann pinseln dir die DCs den Eventlog voll.

 

Das ist korrekt... und das mit dem Eventlog, schau einfach nicht rein solange die Leitung down ist. :D

 

Von blind aktivieren des Features war ja auch nicht die Rede. Natürlich machts keinen Sinn das Ding beim Einsatz von 64k-Leitungen zu aktivieren...

 

Ich wollte es nur hervorheben, diese Konfiguration nur nach genauerer Untersuchung zu aktivieren.

 

Mit meinem Satz "Solche Probleme..." bezog ich mich...

 

Ahh... oki.

[Sascha321 12]

Hallo

 

vielen Dank für die vielen Infos.

 

Nur eins wundert mich, in den ganzen MCSA Bücheren geht Microsoft immer von Subdomänen aus. Wieso machen Sie das wenn es doch mit einer einzigen viel praktischer ist?

[NorbertFe 2.110]

Nur eins wundert mich, in den ganzen MCSA Bücheren

 

In welchen?

 

geht Microsoft immer von Subdomänen aus. Wieso machen Sie das wenn es doch mit einer einzigen viel praktischer ist?

 

Weil du in einer Schulungsunterlage eben auch diese Faktoren kennenlernen sollst ;)

 

By

Norbert