11
Hilfe zu Active Directory Design
Hallo,
ich plane gerade ein Active-Directory-Design für ein Unternehmen mit mehreren geografischen Standorten (Sites), die jeweils über eine 2Mbit Standleitung mit der Hauptverwaltung verbunden sind, und bin mir mit eine paar Sachen nicht ganz sicher bzw. noch recht neu im Thema AD..
Geplant ist eine Single-Forest-Struktur (so wird es auf vielen Seiten empfohlen) mit einer Domäne und zwei Domänencontrollern (PDC/ADC) in der Hauptverwaltung. Pro Site soll es ebenfalls zwei DCs geben, jedoch weiß ich nicht welche Rolle sie bekommen sollen.
Habe gelesen, dass es bei zwei RODCs pro Site zu inkonsistenten Daten kommen kann, also fallen diese raus. Oder lässt sich das umgehen?
Kann ich mir auch den zweiten DC in den Sites sparen? Sprich: Der lokale DC ist ein RODC und der nächsthöhere DC ist der PDC in der Verwaltung (Einstellung per DHCP).
Wenn die WAN Leitung dann weg ist, könnte man sich dann immer noch lokal anmelden?
Ist der RODC down, würde die Anmeldung doch über's WAN zum PDC laufen, richtig?
Wenn der DC in der Site ein Brideheadserver ist, ist er dann nur für die Replikation zuständig oder kann man sich auch daran anmelden?
Finde zu diesem Thema irgendwie nichts brauchbares.. Wenn ja, kann man vor Ort zwei Bridgeheadserver mit unterschiedlicher aufstellen?
Denkbar wäre auch folgendes Szenario, um die IT Administration aufzuteilen:
Eine Placeholder Domain mit zwei Subdomänen (Europa und Asien). Und dann wieder DCs als Sites in den Standorten.
Leider ist mir aber irgendwie nicht klar, was wann, wie, und wohin repliziert wird
Arbeiten die Subdomains dann autark? Sprich: Es werden keine Benutzer- und Computerobjekte, GPOs etc. reapliziert?
Könnte sich dann ein Mitarbeiter aus Europa an einem Standort in Asien anmelden? Wenn nein, was muss eingestellt werden damit das möglich ist?
Danke!
Gruß,
blind3d
ich plane gerade ein Active-Directory-Design für ein Unternehmen mit mehreren geografischen Standorten (Sites), die jeweils über eine 2Mbit Standleitung mit der Hauptverwaltung verbunden sind, und bin mir mit eine paar Sachen nicht ganz sicher bzw. noch recht neu im Thema AD..
Geplant ist eine Single-Forest-Struktur (so wird es auf vielen Seiten empfohlen) mit einer Domäne und zwei Domänencontrollern (PDC/ADC) in der Hauptverwaltung. Pro Site soll es ebenfalls zwei DCs geben, jedoch weiß ich nicht welche Rolle sie bekommen sollen.
Habe gelesen, dass es bei zwei RODCs pro Site zu inkonsistenten Daten kommen kann, also fallen diese raus. Oder lässt sich das umgehen?
Kann ich mir auch den zweiten DC in den Sites sparen? Sprich: Der lokale DC ist ein RODC und der nächsthöhere DC ist der PDC in der Verwaltung (Einstellung per DHCP).
Wenn die WAN Leitung dann weg ist, könnte man sich dann immer noch lokal anmelden?
Ist der RODC down, würde die Anmeldung doch über's WAN zum PDC laufen, richtig?
Wenn der DC in der Site ein Brideheadserver ist, ist er dann nur für die Replikation zuständig oder kann man sich auch daran anmelden?
Finde zu diesem Thema irgendwie nichts brauchbares.. Wenn ja, kann man vor Ort zwei Bridgeheadserver mit unterschiedlicher aufstellen?Denkbar wäre auch folgendes Szenario, um die IT Administration aufzuteilen:
Eine Placeholder Domain mit zwei Subdomänen (Europa und Asien). Und dann wieder DCs als Sites in den Standorten.
Leider ist mir aber irgendwie nicht klar, was wann, wie, und wohin repliziert wird
Arbeiten die Subdomains dann autark? Sprich: Es werden keine Benutzer- und Computerobjekte, GPOs etc. reapliziert?
Könnte sich dann ein Mitarbeiter aus Europa an einem Standort in Asien anmelden? Wenn nein, was muss eingestellt werden damit das möglich ist?
Danke!
Gruß,
blind3d
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: 206408
Url: https://administrator.de/forum/hilfe-zu-active-directory-design-206408.html
Ausgedruckt am: 23.12.2024 um 04:12 Uhr
11 Kommentare
Neuester Kommentar
Moin,
googlen ist jetzt nicht soooo schwer:
http://technet.microsoft.com/en-us/library/bb727085.aspx
Gruß
googlen ist jetzt nicht soooo schwer:
http://technet.microsoft.com/en-us/library/bb727085.aspx
Gruß
Google bedienen kann ich auch, nur habe ich gerade keine Zeit mir das alles durchzulesen und anzueignen. Deswegen habe ich direkt diese Situation angefragt, weil mir das am Wichtigsten erscheint.
Und Du bist sicher, dass Du den richtigen Job gewählt hast? Na denn alles Gute!
Man hat mich direkt in ein Großprojekt geworfen und alles hätte am Besten gestern fertig sein sollen, da das Projekt schon lange auf Eis liegt. Jetzt muss ich improvisieren. Mir fehlt halt der technische Background in diesem Bereich, also versuche ich jetzt schnell was zu stricken, was trotzdem Hand und Fuß hat. Ou Design, GPOs ok, aber im Alleingang ein AD designen ist finde ich nicht ganz so einfach..
Musst ja nicht gleich patzig werden..
Musst ja nicht gleich patzig werden..
Hi,
wie groß sind den die Außenstellen? Handelt es um 1000 oder 20? Bei geringer Anzahl von AD-Usern in den Außenstellen ist ein RODC schon recht Sinnvoll. Trotzdem empfehle ich dir wenigstens in der Zentrale einen zweiten DC zu haben, falsch der einzig Schreibfähige DC crasht. Wenn du da nicht ausreichend vorsorgst, wird es haarig -> AD neu aufsetzen.
Was haben 2 RODC in einer Site für einen Sinn? Verursacht nur sinnlos traffic. Wenn ein RODC ausfällt, dann ist es eher die Hardware, der Rest wird von deinem DC erledigt.
lokal geht immer, aber wenn du fragen wolltest, ob sie sich an der Domäne trotzdem anmelden können, ja. Das ist der Sinn von RODC
Wenn Verbindung zum "PDC" besteht, ja.
Was die Trennung deiner Standorte angeht, kannst du es über child-domain lösen (subzonen). Wenn du allerdings möchtest, dass Europa auf Ressourcen in Asien Zugriff haben muss oder umgekehrt, dann musst du auch noch Vertrauenstellungen einrichten.
Subzonen kämen für mich nur in Frage wenn jede Site komplett Autark sein soll und nur auf Ressourcen zugreifen dürfen, welche sich nur in ihrer Site befinden und es sich mindestens um 100 AD-User pro Site handelt. Dann würde ich aber auch für jede Site einen eigenen DC bauen. Aber das ist nur meine Meinung.
Wenn es nur wenige User sind die in den Standorten verteilt sind, dann kannst das auch genauso gut über OU's abbilden, was aus meiner Sicht etwas einfacher ist.
Am Ende ist es eine Geschmacksache, da jeder seine eigene Ordnung hat. AD Designen und Verwalten sollten aus meiner Sicht auch nur eine kleine Gruppe von Admins, weil einfach jeder eine Ordnung anders definiert. AD ist glaube ich unter Administratoren das Zickenthema nr.1
Sonst hilft die nur lesen, lesen, lesen und noch mal lesen.
wie groß sind den die Außenstellen? Handelt es um 1000 oder 20? Bei geringer Anzahl von AD-Usern in den Außenstellen ist ein RODC schon recht Sinnvoll. Trotzdem empfehle ich dir wenigstens in der Zentrale einen zweiten DC zu haben, falsch der einzig Schreibfähige DC crasht. Wenn du da nicht ausreichend vorsorgst, wird es haarig -> AD neu aufsetzen.
Habe gelesen, dass es bei zwei RODCs pro Site zu inkonsistenten Daten kommen kann
Was haben 2 RODC in einer Site für einen Sinn? Verursacht nur sinnlos traffic. Wenn ein RODC ausfällt, dann ist es eher die Hardware, der Rest wird von deinem DC erledigt.
Wenn die WAN Leitung dann weg ist, könnte man sich dann immer noch lokal anmelden?
lokal geht immer, aber wenn du fragen wolltest, ob sie sich an der Domäne trotzdem anmelden können, ja. Das ist der Sinn von RODC
Ist der RODC down, würde die Anmeldung doch über's WAN zum PDC laufen, richtig?
Wenn Verbindung zum "PDC" besteht, ja.
Was die Trennung deiner Standorte angeht, kannst du es über child-domain lösen (subzonen). Wenn du allerdings möchtest, dass Europa auf Ressourcen in Asien Zugriff haben muss oder umgekehrt, dann musst du auch noch Vertrauenstellungen einrichten.
Subzonen kämen für mich nur in Frage wenn jede Site komplett Autark sein soll und nur auf Ressourcen zugreifen dürfen, welche sich nur in ihrer Site befinden und es sich mindestens um 100 AD-User pro Site handelt. Dann würde ich aber auch für jede Site einen eigenen DC bauen. Aber das ist nur meine Meinung.
Wenn es nur wenige User sind die in den Standorten verteilt sind, dann kannst das auch genauso gut über OU's abbilden, was aus meiner Sicht etwas einfacher ist.
Am Ende ist es eine Geschmacksache, da jeder seine eigene Ordnung hat. AD Designen und Verwalten sollten aus meiner Sicht auch nur eine kleine Gruppe von Admins, weil einfach jeder eine Ordnung anders definiert. AD ist glaube ich unter Administratoren das Zickenthema nr.1
Sonst hilft die nur lesen, lesen, lesen und noch mal lesen.
Hi,
wir haben das bei uns so gemacht, dass wir am Hauptstandort 2 DC's haben und an zwei weiteren Standortenjeweils einen DC haben. Das ganze ist dann mit OU's getrennt, da am Hauptstandort alle anderen Server stehen (Terminal, Print ...).
Über die OU's lässt sich das einfach übersichtlich gestalten ohne subdomains zu haben. Auch GPO's lassen sich schön auf die OU's anwenden.
#EDIT: Wir haben keinen RODC laufen.
Gruß
wir haben das bei uns so gemacht, dass wir am Hauptstandort 2 DC's haben und an zwei weiteren Standortenjeweils einen DC haben. Das ganze ist dann mit OU's getrennt, da am Hauptstandort alle anderen Server stehen (Terminal, Print ...).
Über die OU's lässt sich das einfach übersichtlich gestalten ohne subdomains zu haben. Auch GPO's lassen sich schön auf die OU's anwenden.
#EDIT: Wir haben keinen RODC laufen.
Gruß
Mahlzeit
Wäre es hier nicht besser, jemanden einzukaufen, der das kann, als es in einem Forum erklärt zu bekommen?
Sorry, aber für mich klingt das nach einer Projektarbeit bei einer Ausbildung.
Da der Technet-Link vom Coreknaben für Windows 2000 Server ist, habe ich dir hier noch einen aktuelleren herausgesucht.
Zitat von @blind3d:
Man hat mich direkt in ein Großprojekt geworfen und alles hätte am Besten gestern fertig sein sollen, da das Projekt
schon lange auf Eis liegt. Jetzt muss ich improvisieren. Mir fehlt halt der technische Background in diesem Bereich,
Wie kann man denn ein Großprojekt stemmen, wenn man von dem, was man machen soll, nur wenig Ahnung hat?Man hat mich direkt in ein Großprojekt geworfen und alles hätte am Besten gestern fertig sein sollen, da das Projekt
schon lange auf Eis liegt. Jetzt muss ich improvisieren. Mir fehlt halt der technische Background in diesem Bereich,
Wäre es hier nicht besser, jemanden einzukaufen, der das kann, als es in einem Forum erklärt zu bekommen?
also versuche ich jetzt schnell was zu stricken, was trotzdem Hand und Fuß hat.
Das ist jetzt aber nicht dein Ernst, oder?Sorry, aber für mich klingt das nach einer Projektarbeit bei einer Ausbildung.
Musst ja nicht gleich patzig werden..
Ich schätze der Coreknabe denkt hier ähnlich.Da der Technet-Link vom Coreknaben für Windows 2000 Server ist, habe ich dir hier noch einen aktuelleren herausgesucht.
Zitat von @blind3d:
Geplant ist eine Single-Forest-Struktur (so wird es auf vielen Seiten empfohlen) mit einer Domäne und zwei
Domänencontrollern (PDC/ADC) in der Hauptverwaltung. Pro Site soll es ebenfalls zwei DCs geben, jedoch weiß ich nicht
welche Rolle sie bekommen sollen.
Geplant ist eine Single-Forest-Struktur (so wird es auf vielen Seiten empfohlen) mit einer Domäne und zwei
Domänencontrollern (PDC/ADC) in der Hauptverwaltung. Pro Site soll es ebenfalls zwei DCs geben, jedoch weiß ich nicht
welche Rolle sie bekommen sollen.
Wie groß sind die Außenstellen? Je nachdem würde ich zu vollständigen DCs mit Subdomains raten oder halt RODCs nehmen!
Habe gelesen, dass es bei zwei RODCs pro Site zu inkonsistenten Daten kommen kann, also fallen diese raus.
2 RODCs? Macht keinen Sinn - Jedenfalls machen für mich RODCs nur da Sinn, wo sie quasi auf dem Präsentierteller stehen und nicht wirklich viele (<50 User) zu versorgen haben.
Wenn die WAN Leitung dann weg ist, könnte man sich dann immer noch lokal anmelden?
Ja würde funktionieren
Ist der RODC down, würde die Anmeldung doch über's WAN zum PDC laufen, richtig?
Ja aber Zeitverzögert
Eine Placeholder Domain mit zwei Subdomänen (Europa und Asien). Und dann wieder DCs als Sites in den Standorten.
Leider ist mir aber irgendwie nicht klar, was wann, wie, und wohin repliziert wird
Arbeiten die Subdomains dann autark? Sprich: Es werden keine Benutzer- und Computerobjekte, GPOs etc. reapliziert?
Könnte sich dann ein Mitarbeiter aus Europa an einem Standort in Asien anmelden? Wenn nein, was muss eingestellt werden damit das möglich ist?
Leider ist mir aber irgendwie nicht klar, was wann, wie, und wohin repliziert wird
Arbeiten die Subdomains dann autark? Sprich: Es werden keine Benutzer- und Computerobjekte, GPOs etc. reapliziert?
Könnte sich dann ein Mitarbeiter aus Europa an einem Standort in Asien anmelden? Wenn nein, was muss eingestellt werden damit das möglich ist?
Die Subdomains replizieren soweit ich weiß nur Elemente in den Globalen Katalog. D.h. wenn du im Schema nicht alles in den Globalen Katalog replizieren lässt hält sich der ganze Spaß in Grenzen. Je nachdem wie du den DNS Konfigurierst wird dieser im kompletten Forest repliziert.
Zur Anmeldung: Wenn du von der untergeordneten in die übergeordnete Domain möchtest, sollte es einfach so funktionieren. Wenn du von Niederlassung1.firma.local zu Niederlassung2.firma.local willst müsstest du Vertrauenstellungen bilden (bin mir aber nicht 100% sicher).
Wichtig ist das du die Standorte und deren Subnetze ordentlich in der "Standorte und Netze"-MMC deklarierst!
Ho Brauner...
Meine Antwort sollte weder patzig noch unfreundlich klingen, das Posting wirkt hier nur wie Realsatire.
@goscho: Danke, so ganz allein bin ich mit meiner Meinung dann also doch nicht. Wenn ich keine Ahnung habe und dann auch noch erwähne, dass ich keine Zeit habe, für technischen Background zu sorgen, was soll denn bitte am Ende dabei rumkommen? Ein komplett vermurkstes AD-Design, für das der Kunde sich später sehr dankbar zeigen wird? Ist ja auch kein Problem, dass alles noch mal neu zu machen. Gesetzt den Fall, es hatte jemand die Zeit, sich Kenntnisse anzueignen, um das vernünftig umzusetzen. Ich fange ja auch nicht an, selbst an meinem Auto rumzuschrauben, wenn mir die nötigen Kenntnisse fehlen. Nur damit der Computer-Auto-Vergleich abgedeckt ist.
Für den veralteten Link entschuldige ich mich in vollem Umfang!
Meine Antwort sollte weder patzig noch unfreundlich klingen, das Posting wirkt hier nur wie Realsatire.
@goscho: Danke, so ganz allein bin ich mit meiner Meinung dann also doch nicht. Wenn ich keine Ahnung habe und dann auch noch erwähne, dass ich keine Zeit habe, für technischen Background zu sorgen, was soll denn bitte am Ende dabei rumkommen? Ein komplett vermurkstes AD-Design, für das der Kunde sich später sehr dankbar zeigen wird? Ist ja auch kein Problem, dass alles noch mal neu zu machen. Gesetzt den Fall, es hatte jemand die Zeit, sich Kenntnisse anzueignen, um das vernünftig umzusetzen. Ich fange ja auch nicht an, selbst an meinem Auto rumzuschrauben, wenn mir die nötigen Kenntnisse fehlen. Nur damit der Computer-Auto-Vergleich abgedeckt ist.
Für den veralteten Link entschuldige ich mich in vollem Umfang!
Das Problem ist, das die GF sich das ganze äußerst einfach vorstellt und sich der enormen Komplexität und den Möglichkeiten von AD nicht bewusst ist. Von dem ganzen Ratten###, der bei der Migration von Novell zu AD noch dran hängt mal ganz abgesehen..
Eigentlich habe ich gesagt, ich kann beim Design etwas unterstützen, da ich immer in einer AD Umgebung gearbeitet habe und auch mitbekommen habe wie man aufgestellt ist. Habe mich dabei aber auf OUs, GPOs beschränkt, da ich bisher nicht an DCs rumgefummelt habe.
Jetzt darf ich die ganze Basis darunter aber auch noch machen und da fehlt halt das Know-How. Bin schon die ganzen Tage am googlen wie ich die Idee, die ich habe, am Besten umsetzen kann.
Und das ist halt das o.g. "Gerüst". Soll für den Admin halt einfach sein und auch parktisch für den User. Von daher tendiere ich zur Single-Forest - Single-Domain Struktur mit DCs als Sites an den Standorten. Insgesamt sprechen wir hier von nur ~1500 Usern. Wenn benötigt, kann ich dann immerhin noch leicht erweitern.
Es gibt hier nämlich schon ein Konzept im Test, das ich nicht entworfen habe und das sieht vor jeden Standort als eigenen Forest zu haben, was ich für etwas übertrieben halte, da der Punkt Sicherheit aufgrund der geringen Zahl an Admins und nicht abzusichernden Business Units erstmal kein Thema ist. Dann ist man ja nur noch am anpassen.
Von daher musste ich mir auf die Schnelle was überlegen, um das zu kippen
Ich muss schließlich hinterher damit arbeiten
Werde auch vorschlagen, dass man sich externe Hilfe holt. Das Projekt würd' ich höchstens mit 10 Jahren Erfahrung anpacken, da das Thema so komplex ist und später die Basis des Netzes bildet. Da sollte man nicht sparen..
@Coreknabe
Die Situation ist halt kritisch wie ich finde. Das bereits bestehende Konzept halte ich ich für übertrieben dimensioniert. Und um da schnell einwirken zu können bevor es in die komplett falsche Richtung läuft, habe ich mir halt was eigenes überlegt auf Basis meines minimalen Know-Hows. Und das Ergebnis finde ich irgendwie besser..
Bevor nun aber das Multi-Forest Konzept live geht, will ich irgendwas vorzeigen können, das für uns mehr Sinn macht.
Begeistert bin ich davon auch nicht. Würde am liebsten erstmal n paar Schulungen besorgen, um sicher sagen zu können: so und nicht anders.. aber habe leider gerade keine andere Wahl :/
Ach ja und danke natürlich an die anderen für die Infos)
Eigentlich habe ich gesagt, ich kann beim Design etwas unterstützen, da ich immer in einer AD Umgebung gearbeitet habe und auch mitbekommen habe wie man aufgestellt ist. Habe mich dabei aber auf OUs, GPOs beschränkt, da ich bisher nicht an DCs rumgefummelt habe.
Jetzt darf ich die ganze Basis darunter aber auch noch machen und da fehlt halt das Know-How. Bin schon die ganzen Tage am googlen wie ich die Idee, die ich habe, am Besten umsetzen kann.
Und das ist halt das o.g. "Gerüst". Soll für den Admin halt einfach sein und auch parktisch für den User. Von daher tendiere ich zur Single-Forest - Single-Domain Struktur mit DCs als Sites an den Standorten. Insgesamt sprechen wir hier von nur ~1500 Usern. Wenn benötigt, kann ich dann immerhin noch leicht erweitern.
Es gibt hier nämlich schon ein Konzept im Test, das ich nicht entworfen habe und das sieht vor jeden Standort als eigenen Forest zu haben, was ich für etwas übertrieben halte, da der Punkt Sicherheit aufgrund der geringen Zahl an Admins und nicht abzusichernden Business Units erstmal kein Thema ist. Dann ist man ja nur noch am anpassen.
Von daher musste ich mir auf die Schnelle was überlegen, um das zu kippen
Ich muss schließlich hinterher damit arbeiten Werde auch vorschlagen, dass man sich externe Hilfe holt. Das Projekt würd' ich höchstens mit 10 Jahren Erfahrung anpacken, da das Thema so komplex ist und später die Basis des Netzes bildet. Da sollte man nicht sparen..
@Coreknabe
Die Situation ist halt kritisch wie ich finde. Das bereits bestehende Konzept halte ich ich für übertrieben dimensioniert. Und um da schnell einwirken zu können bevor es in die komplett falsche Richtung läuft, habe ich mir halt was eigenes überlegt auf Basis meines minimalen Know-Hows. Und das Ergebnis finde ich irgendwie besser..
Bevor nun aber das Multi-Forest Konzept live geht, will ich irgendwas vorzeigen können, das für uns mehr Sinn macht.
Begeistert bin ich davon auch nicht. Würde am liebsten erstmal n paar Schulungen besorgen, um sicher sagen zu können: so und nicht anders.. aber habe leider gerade keine andere Wahl :/
Ach ja und danke natürlich an die anderen für die Infos
)
