6
Empfehlung für Active Directory Planung
Hallo Leute,
ich habe folgende Prüfungsaufgabe: Aufbau eines Active Directory an internationalen Standorten und Empfehlungen für die Planung (Vor- und Nachteile)
Ein US-Unternehmen hat eine bestehende IT-Infrastruktur und expandiert nun international (3 weitere Standorte, evtl. später auch mehrere). Die IT-Infrastruktur besteht aus zwei RW-DCs mit integr. DNS. Die Domäne heisst: uscorp.domain.com.
Es besteht nun die Frage wie die anderen Standorte aufgebaut werden sollen? Als eigenständiges AD oder als Forest? Welche Vor- und Nachteile hätten weitere AD´s bzw. Forests? Sollten Forests gewählt werden, muss man dann alle Systeme welche sich aktuell in der Domäne uscorp.domain.com befinden dann in den neuen Forest joinen der z.b. cn.uscorp.domain.com heisst?
ich habe folgende Prüfungsaufgabe: Aufbau eines Active Directory an internationalen Standorten und Empfehlungen für die Planung (Vor- und Nachteile)
Ein US-Unternehmen hat eine bestehende IT-Infrastruktur und expandiert nun international (3 weitere Standorte, evtl. später auch mehrere). Die IT-Infrastruktur besteht aus zwei RW-DCs mit integr. DNS. Die Domäne heisst: uscorp.domain.com.
Es besteht nun die Frage wie die anderen Standorte aufgebaut werden sollen? Als eigenständiges AD oder als Forest? Welche Vor- und Nachteile hätten weitere AD´s bzw. Forests? Sollten Forests gewählt werden, muss man dann alle Systeme welche sich aktuell in der Domäne uscorp.domain.com befinden dann in den neuen Forest joinen der z.b. cn.uscorp.domain.com heisst?
Auf Facebook teilen
Auf X (Twitter) teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 299256
Url: https://administrator.de/forum/empfehlung-fuer-active-directory-planung-299256.html
Ausgedruckt am: 13.04.2025 um 21:04 Uhr
6 Kommentare
Neuester Kommentar
Hi,
mein Tipp:
Bevor Du Dich mit Design befasst, lerne erstmal die Grundlagen. Deine Fragestellung ist voll von Grundlagenfehlern.
E.
mein Tipp:
Bevor Du Dich mit Design befasst, lerne erstmal die Grundlagen. Deine Fragestellung ist voll von Grundlagenfehlern.
... eigenständiges AD oder als Forest
... weitere AD´s bzw. Forests
... muss man dann alle Systeme welche sich aktuell in der Domäne uscorp.domain.com befinden dann in den neuen Forest joinen der z.b. cn.uscorp.domain.com heisst?
... weitere AD´s bzw. Forests
... muss man dann alle Systeme welche sich aktuell in der Domäne uscorp.domain.com befinden dann in den neuen Forest joinen der z.b. cn.uscorp.domain.com heisst?
E.
Mir fiele als erstes mal der Datenschutz ein 
Eine Domäne kann personenbeziehbare Daten verwalten, ein DC im Ausland hat natürlich Zugriff auf diese Information bzw. spiegelt diese Information...
Eine Domäne kann personenbeziehbare Daten verwalten, ein DC im Ausland hat natürlich Zugriff auf diese Information bzw. spiegelt diese Information...
Hi
Vom Design her stellt sich mir eigentlich nur eine Frage: Sollen die Außenstellen evtl. irgendwann "abstoßbar" sein oder nicht?
Wenn ja: eine Hauptdomain und jeweils pro Standort eine Childdomain oder eine eigenständige Domain und das ganze dann via Trusts verbinden (die kann man sauber "aus dem System entfernen" ohne maßlos viel Aufwand später).
Wenn nein: eine Hauptdomain und die Standorte und deren Objekte via OU separieren, bedeutend weniger Pflegeaufwand und schneller auszurollen, weniger Komplexität, weniger Wartung, einheitlichere Dokumentation und viel weniger Probleme.
Das wäre die "Quick & Dirty" Antwort, wenn du es gescheit machen willst, jeder Standort eine Childdomain, dann kannst einfacher Admins vor Ort einrichten, die dann maximal "Schaden" in Ihrer Domain anrichten können und du kannst als Enterprise-Admin in der Hauptdomäne trotzdem alles in deren Domains steuern. Klar geht das auch über OUs und Delegierung, aber sauberer ist es via Child-Domains.
Noch ein kleiner Tipp von mir: den Domänennamen so lang wie nötig und so kurz wie möglich wählen, wenn man den FQDN immer mit eintippen musst kann das schon recht lästig werden wenn der ewig lang ist
.
Gruß
@clSchak
Vom Design her stellt sich mir eigentlich nur eine Frage: Sollen die Außenstellen evtl. irgendwann "abstoßbar" sein oder nicht?
Wenn ja: eine Hauptdomain und jeweils pro Standort eine Childdomain oder eine eigenständige Domain und das ganze dann via Trusts verbinden (die kann man sauber "aus dem System entfernen" ohne maßlos viel Aufwand später).
Wenn nein: eine Hauptdomain und die Standorte und deren Objekte via OU separieren, bedeutend weniger Pflegeaufwand und schneller auszurollen, weniger Komplexität, weniger Wartung, einheitlichere Dokumentation und viel weniger Probleme
.Das wäre die "Quick & Dirty" Antwort, wenn du es gescheit machen willst, jeder Standort eine Childdomain, dann kannst einfacher Admins vor Ort einrichten, die dann maximal "Schaden" in Ihrer Domain anrichten können und du kannst als Enterprise-Admin in der Hauptdomäne trotzdem alles in deren Domains steuern. Klar geht das auch über OUs und Delegierung, aber sauberer ist es via Child-Domains.
Noch ein kleiner Tipp von mir: den Domänennamen so lang wie nötig und so kurz wie möglich wählen, wenn man den FQDN immer mit eintippen musst kann das schon recht lästig werden wenn der ewig lang ist
.Gruß
@clSchak
Hallo,
also angedacht ist es nicht die Aussenstellen abzustossen. Die Hauptdomain sollte von Enterprise Admins administrierbar sein und die Childdomains eben von Admins vor Ort.
Nun die Frage - unsere "Hauptdomain" heisst z.b. uscorp.domain.com und hier sind jetzt alle Systeme am Standort USA gejoint - hier sitzen auch die Enterprise Admins. Wenn wir dann Childdomains aufbauen müssten die ja dann z.b. cn.uscorp.domain.com oder de.uscorp.domain.com heissen und unsere jetzige Hauptdomain uscorp.domain.com müsste dann in eine eigene Childdomain rein "us.uscorp.domain.com" oder????
Heisst das für uns alle Systeme von der jetzigen Domain uscorp.domain.com in die dann neu angelegte Childdomain us.uscorp.domain.com rejoinen?
also angedacht ist es nicht die Aussenstellen abzustossen. Die Hauptdomain sollte von Enterprise Admins administrierbar sein und die Childdomains eben von Admins vor Ort.
Nun die Frage - unsere "Hauptdomain" heisst z.b. uscorp.domain.com und hier sind jetzt alle Systeme am Standort USA gejoint - hier sitzen auch die Enterprise Admins. Wenn wir dann Childdomains aufbauen müssten die ja dann z.b. cn.uscorp.domain.com oder de.uscorp.domain.com heissen und unsere jetzige Hauptdomain uscorp.domain.com müsste dann in eine eigene Childdomain rein "us.uscorp.domain.com" oder????
Heisst das für uns alle Systeme von der jetzigen Domain uscorp.domain.com in die dann neu angelegte Childdomain us.uscorp.domain.com rejoinen?
Wenn wir dann Childdomains aufbauen müssten die ja dann z.b. cn.uscorp.domain.com oder de.uscorp.domain.com heissen und unsere jetzige Hauptdomain uscorp.domain.com müsste dann in eine eigene Childdomain rein "us.uscorp.domain.com" oder????
Wie schon gesagt, lern die Grundlagen!Auch nur eine alleinstehende Domain >=Win2000 ist Mitglied eines Forest. Denk nach: Wenn jetzt Child Domains einstehen sollen - Wer tritt dann wem bei?
Hauptdomäne uscorp.domain.com bleibt
Childdomains kommen dann hinzu und heissen dann einfach de.uscorp.domain.com, cn.uscorp.domain.com etc. Die Hauptdomäne wird durch Enterprise Admins verwaltet und die Childdomains durch Admins vor Ort.
Welche Vor- und Nachteile hat diese Lösung?
Welche Vor- und Nachteile hat ein Active Directory pro Lokation?
Childdomains kommen dann hinzu und heissen dann einfach de.uscorp.domain.com, cn.uscorp.domain.com etc. Die Hauptdomäne wird durch Enterprise Admins verwaltet und die Childdomains durch Admins vor Ort.
Welche Vor- und Nachteile hat diese Lösung?
Welche Vor- und Nachteile hat ein Active Directory pro Lokation?
