Optimale Vorgehensweisen beim Entwurf von Active

Optimale Vorgehensweisen beim Entwurf von
Active Directory für die Verwaltung von
Windows-Netzwerken
(Engl. Originaltitel: Best Practice Active Directory Design for Managing Windows Networks)
Microsoft Windows 2000
Microsoft Corporation
Danksagung
Wir danken den folgenden Personen für die Prüfung der Handbücher und für ihr Feedback (sofern nicht anders
angegeben, handelt es sich bei den aufgeführten Personen um Mitarbeiter der Microsoft Corporation):
Micky Balladelli (Avanade Inc.), Dung Hoang Khac (Compaq Global Services), Vic Gupta, Shaun Hayes,
Michael Kostersitz, Doug Lindsey, Alain Lissoir (Compaq Global Services), Tony Mosunmade, Tony Redmond
(Compaq Global Services), Matthijs ten Seldam, Paul Thompson (NetIQ Corporation), Ruud van Velsen, Eddie
Hanif, Frank Plawetzki, Connie Shih, Steve Towle, Christopher Westpoint.
Laborpersonal: Robert Thingwold und David Meyer
Laborpartner: Compaq, Inc. und Cisco Systems
Entwurfshandbuch mit optimalen Vorgehensweisen
Ein strukturierter Ansatz beim Entwurf von Active Directory kann die Bereitstellung von Verzeichnisdiensten
auf Unternehmensebene erheblich vereinfachen. Dieses Handbuch sowie das Begleithandbuch Best Practice
Active Directory Deployment for Managing Windows Networks (englischsprachig) enthalten sowohl
geschäftliche als auch technische Informationen, die Ihnen Zeit und Mühe bei der Implementierung des Active
Directory™-Verzeichnisdienstes ersparen.
Die in diesem Handbuch beschriebenen schrittweisen Methoden basieren auf optimalen Vorgehensweisen von
Kunden, die Active Directory in ihren Organisationen bereits bereitgestellt haben. Behandelt werden alle
Aufgaben und Entscheidungen, die für die Erstellung eines Active Directory-Entwurfs zur Verwaltung von
Windows-Netzwerken erforderlich sind. Das Handbuch richtet sich an IT-Fachleute, die für die Durchführung
von Tests und Pilotversuchen sowie für das Rollout eines Active Directory-Entwurfs verantwortlich sind.
Einführung
Mithilfe des Active Directory-Dienstes von Windows® 2000 können Organisationen die Benutzer- und
Ressourcenverwaltung vereinfachen und gleichzeitig eine skalierbare, sichere und verwaltbare Infrastruktur für
die Bereitstellung wichtiger neuer Technologien erstellen.
Microsoft publiziert eine Reihe situationsbasierter Handbücher mit konkreten, praxisbezogenen und
lösungsorientierten Informationen, die zur Verkürzung der Planungsphase und zum Erfolg der Bereitstellung
beitragen.
Optimale Vorgehensweisen beim Entwurf von Active Directory für die Verwaltung von Windows-Netzwerken
und das Begleithandbuch Best Practice Active Directory Deployment for Managing Windows Networks
(englischsprachig) sind Teil dieser Reihe. Dieses Handbuch beschreibt einen strukturierten Ansatz für den
Entwurf und die Bereitstellung von Active Directory. Ohne einen solchen strukturierten Ansatz kann die
Implementierung von Active Directory in Ihrer Organisation mehr Zeit in Anspruch nehmen als erwartet.
Die Handbücher verbinden die Fachkenntnisse des Microsoft-Produktteams im Hinblick auf Planung und
Bereitstellung mit den praktischen Erfahrungen von Kunden, die Active Directory in ihren Organisationen
entworfen und bereitgestellt haben.
Bereitstellungsszenarien für Active Directory
Im Gegensatz zu Verzeichnissen, die einem bestimmten Zweck dienen, kann Active Directory verschiedene
Funktionen innerhalb einer Organisation erfüllen. Diese Funktionen umfassen z. B. die Verwaltung von
Windows-Netzwerken und die Unterstützung verzeichnisfähiger E-Commerce-Anwendungen. Die Art der
Verwendung von Active Directory hat jedoch erhebliche Auswirkungen auf Entwurfs- und
Bereitstellungsentscheidungen.
Active Directory für die Verwaltung von Windows-Netzwerken
Dieses Handbuch enthält auf optimalen Vorgehensweisen basierende Anleitungen für die Bereitstellung von
Active Directory zur Verwaltung von Netzwerken, die Windows-Clients, Windows-Server sowie Windowskompatible Anwendungen und Geräte enthalten. Dies wird in diesem Handbuch als Verwaltungsrolle des
Netzwerkbetriebssystems (Network Operating System oder NOS) bezeichnet. Im Folgenden werden die Vorteile
der Bereitstellung von Active Directory in einer NOS-Verwaltungsrolle aufgelistet:
•
•
•
•
•
•
•
•
•
•
•
Zentrale Verwaltung umfangreicher Windows-Netzwerke (Active Directory wurde für die
Unterstützung von Millionen von Objekten konzipiert)
Eliminierung von Ressourcendomänen, einschließlich der mit ihnen verbundenen Hardware und
Verwaltung
Richtlinienbasierte Desktopsperre und Softwareverteilung
Möglichkeit zur Delegierung von Verwaltungsfunktionen für Ressourcen
Vereinfachte Speicherung und Verwendung von gemeinsam genutzten Ressourcen
Weitere Informationen über den wirtschaftlichen Nutzen der Bereitstellung von Active Directory
erhalten Sie unter: http://www.microsoft.com/windows2000/ (englischsprachig).
In diesem Handbuch wird die Bereitstellung von Active Directory und DNS-Kerndiensten im Rahmen
der Verwaltung eines Windows-Netzwerkes beschrieben. Weitere auf Active Directory basierende
Dienste können später hinzugefügt werden und wirken sich nicht auf den ursprünglichen Entwurf aus.
Beispielsweise können Gruppenrichtlinien die Verwaltung vereinfachen, indem sie eine
richtlinienbasierte Verwaltung für Benutzer, Gruppen, Arbeitsstationen und Server ermöglichen. Im
Folgenden werden einige Beispiele für Dienste aufgeführt, die Active Directory hinzugefügt werden
können:
Gruppenrichtlinien
Exchange 2000
Integrierte Dienste für eine Infrastruktur öffentlicher Schlüssel (Public Key Infrastructure oder PKI)
Domänenbasiertes DFS
Spezielle Überlegungen zu Bereitstellungen in Zweigstellen
Microsoft hat eine Reihe spezieller Anforderungen identifiziert, die bei der Bereitstellung von Active Directory
in Zweigstellenumgebungen berücksichtigt werden sollten. Zu den Besonderheiten von
Zweigstellenumgebungen gehören:
•
•
•
•
Eine große Anzahl physischer Standorte, die Replikate von Active Directory-Daten benötigen.
Eine relative geringe Anzahl an Benutzern pro Standort.
Eine sternförmige Netzwerktopologie, wobei zahlreiche Zweigstellen auf eine Verbindung zu einem
zentralen Standort angewiesen sind, um mit anderen Teilen der Organisation kommunizieren zu
können.
Langsame Netzwerkverbindungen zwischen den Zweigstellen-Standorten und dem zentralen Standort.
Aufgrund dieser speziellen Anforderungen hat Microsoft zusätzliche Inhalte entwickelt, die sich mit der
Bereitstellung von Active Directory in Zweigstellenumgebungen beschäftigen. Das Handbuch Active Directory –
Planungshandbuch für Zweigstellen ist online verfügbar unter:
http://www.microsoft.com/germany/ms/technetdatenbank/overview.asp?siteid=468904
bzw. Active Directory Branch Office Planning unter
http://www.microsoft.com/windows2000/techinfo/planning/activedirectory/branchoffice/default.asp
(englischsprachig). Diese Inhalte können ggf. zusammen mit dem Handbuch Optimale Vorgehensweisen beim
Entwurf von Active Directory für die Verwaltung von Windows-Netzwerken verwendet werden.
Spezielle Überlegungen zu Exchange 2000-Bereitstellungen
Mithilfe dieses Handbuchs können Sie eine Active Directory-Bereitstellung mit Exchange 2000 entwerfen. Die
Bereitstellung von Exchange 2000 im Rahmen von Active Directory ist jedoch nicht Thema dieses Handbuchs.
Informationen hierzu finden Sie in Microsoft Exchange 2000 Server-Updatereihe unter:
http://www.microsoft.com/germany/ms/technetdatenbank/overview.asp?siteid=390366 bzw.
http://www.microsoft.com/technet/itsolutions/guide/default.asp (englischsprachig).
Informationen zu diesem Handbuch
Dieses Handbuch wurde für IT-Fachpersonal geschrieben, die an der Planung und Bereitstellung von Active
Directory beteiligt sind. Es basiert auf optimalen Vorgehensweisen beim Entwurf von Active Directory und
enthält sowohl geschäftliche als auch technische Anleitungen, um die für die Implementierung von Active
Directory in Ihrer Organisation erforderliche Zeit und Mühe zu minimieren. Dieses Dokument enthält
Tabellenblätter, auf denen Sie jeden Schritt Ihres Entwurfs dokumentieren können.
Optimale Vorgehensweisen
Die optimalen Vorgehensweisen basieren auf Erfahrungen, die das Active Directory-Entwicklungsteam mit
Organisationen gemacht hat, in denen Active Directory bereits erfolgreich implementiert wurde. Dieser Ansatz
trägt aus folgenden Gründen zu einer Verkürzung der Planungsphase bei:
•
•
•
•
Es stehen getestete Active Directory-Standardentwürfe zur Verfügung.
Die vorgestellten Entwurfsentscheidungen haben sich in der Windows NOS-Verwaltungsrolle bewährt.
Aufgabenmeilensteine und die Reihenfolge der Aufgaben werden durch Flussdiagramme und
Tabellenblätter verdeutlicht.
Es werden Szenarien bereitgestellt, um die Entwurfskonzepte zu veranschaulichen.
Umfang dieses Dokuments
Die in diesem Dokument dargestellten Richtlinien eignen sich zwar grundsätzlich für fast alle NOSVerwaltungsbereitstellungen, wurden jedoch speziell in Umgebungen getestet und validiert, für die Folgendes
gilt:
•
•
•
Sie verfügen über weniger als 100.000 Benutzer.
Sie umfassen weniger als 200 physische Standorte.
Für Bereitstellungen, die über diese Begrenzungen hinausgehen, empfiehlt Microsoft, die Dienste einer
Beratungsfirma in Anspruch zu nehmen, die Erfahrung mit der Bereitstellung von Active Directory in
komplexeren Umgebungen hat.
So verwenden Sie dieses Handbuch
Jede Phase des Entwurfsprozesses, einschließlich des Entwurfs einer Gesamtstruktur, enthält ein
Prozessflussdiagramm sowie eine Liste der Aufgaben, die ausgeführt werden müssen. Führen Sie den Active
Directory-Entwurf in der beschriebenen Reihenfolge durch. Beachten Sie, dass bei jedem Schritt neue
Teammitglieder einbezogen werden, die für Entscheidungen verantwortlich sind. Jedes Mitglied sollte seine
Entwurfsentscheidungen auf dem dafür vorgesehenen Tabellenblatt dokumentieren. Darüber hinaus kann es
nützlich sein, Passagen aus diesem Handbuch in das Entwurfsdokument zu kopieren, so dass neue
Projektmitglieder die bereits getroffenen Entwurfsentscheidungen nachvollziehen können.
Führen Sie den nächsten Schritt bzw. die nächste Aufgabe erst durch, nachdem das entsprechende Tabellenblatt
ausgefüllt wurde und alle verantwortlichen Personen den Entwurfsentscheidungen zugestimmt haben. Jedes
Tabellenblatt baut auf den Informationen und Entscheidungen auf, die im vorausgehenden Tabellenblatt
dokumentiert wurden. Wenn Sie dieses Handbuch für die Active Directory-Bereitstellung verwenden möchten,
wird in der Bereitstellungsphase auf diese Tabellenblätter verwiesen.
Bevor Sie mit dem Entwurf fortfahren, sollten Sie sicherstellen, dass Folgendes gewährleistet ist:
•
•
Die geschäftlichen Ziele für diese Active Directory-Bereitstellung sollten verständlich formuliert sein.
Die Unterstützung der Geschäftsleitung für die Implementierung eines durch Active Directory
verwalteten Windows-Netzwerkes entsprechend dem vorliegenden Entwurf sollte gewährleistet sein.
Die Bereitstellung der Active Directory-Infrastruktur kann sowohl technologische als auch geschäftliche
Bereiche betreffen. Der Fortschritt Ihres Entwurfs hängt daher auch von Ihrer Fähigkeit ab,
Entscheidungsträgern auf IT- und geschäftlicher Ebene die Vorteile von Active Directory zu vermitteln.
Zielgruppe dieses Handbuches
Dieses Handbuch richtet sich an IT-Fachleute, die an der Planung und Bereitstellung von Active Directory
beteiligt sind. Hierzu gehören Architekten, Projektmanager, Systemintegratoren und Berater.
Da Active Directory im Allgemeinen als eine unternehmensweite Infrastruktur bereitgestellt wird, sollte das
Entwurfsteam möglichst viele Mitarbeiter der Organisation einbeziehen. In diesem Handbuch wird beschrieben,
welche Mitarbeiter in den verschiedenen Projektphasen berücksichtigt werden sollten. Projektteams müssen
Mitarbeiter, deren Abteilungen betroffen sind, von den Entwurfsentscheidungen überzeugen. Beispielsweise ist
bei der Bereitstellung von Active Directory in den meisten Unternehmen die Integration mit einer bestehenden
DNS-Infrastruktur erforderlich. Die für die Verwaltung dieser Systeme verantwortlichen Mitarbeiter können für
den Erfolg des Projekts ausschlaggebend sein. Gleichzeitig sollten die Teams jedoch so klein wie möglich sein,
um den Entscheidungsprozess zu erleichtern.
Das Wichtigste ist jedoch, dass die Bereitstellung von Active Directory für die Windows-Netzwerkverwaltung
auf Unternehmensebene – und nicht auf Abteilungsebene – erfolgt. Wenn Sie als Abteilungsadministrator Active
Directory bereitstellen möchten, sollten Sie den IT-Administrator Ihres Unternehmens um Unterstützung bitten.
Andernfalls könnte die Integration der Bereitstellung auf Abteilungsebene mit einer späteren Active DirectoryBereitstellung auf Unternehmensebene Schwierigkeiten bereiten.
Projektrollen
An einer typischen Active Directory-Bereitstellung sind zahlreiche Personen beteiligt, aber zwei Rollen sollten
gleich zu Anfang besetzt werden: die des Projektarchitekten und die des Projektmanagers. In großen
Organisationen können sich mehrere Personen diese Rollen teilen. Tabelle 1 fasst die Active DirectoryEntwurfsrollen zusammen.
Tabelle 1: Active Directory-Entwurfsrollen
Entwurfsrolle
Projektarchitekt
Projektmanager
Verantwortungsbereich Beschreibung
Technischer Entwurf
Spezialist oder Berater, der für die technischen
Entscheidungen verantwortlich ist und sicherstellt, dass der
Entwurf den geschäftlichen Zielen der Organisation
entspricht.
Prozessplanung
Als zentrale Kontaktperson treibt er den Entwurfsprozess
voran, sorgt dafür, dass die entsprechenden Personen
beteiligt werden, und fördert den Konsens. Verantwortlich
für die Planung und Zeitplanung zur Unterstützung des
Entwurfs.
Projektarchitekt
Für jede Gesamtstruktur ist ein Active Directory-Architekt erforderlich, der den Active Directory-Entwurf und
den Migrationsprozess überwacht. Der ideale Kandidat für diese Rolle ist ein IT-Architekt oder ITSystemplaner, der bereits über Erfahrung mit der Verzeichnisverwaltung verfügt. Andernfalls wäre es
überlegenswert, einen Berater anzustellen, der Erfahrung mit dem Entwurf und der Bereitstellung von Active
Directory hat. Ein Berater kann Erfahrungen und Impulse in das Entwurfsteam einbringen und bei der Lösung
organisationsübergreifender Probleme behilflich sein.
Im Folgenden werden die Verantwortungsbereiche des Active Directory-Architekten aufgelistet:
•
•
•
•
Besitzer des Active Directory-Entwurfs
Begründen wichtiger Entwurfsentscheidungen
Ermitteln, ob der Entwurf den Geschäftszielen der Organisation entspricht
Ggf. Vorschlagen anderer Lösungen, die den Geschäftsanforderungen eher entsprechen
Der endgültige Active Directory-Entwurf sollte eine Kombination aus Geschäftszielen und technischen
Entscheidungen darstellen. Der Projektarchitekt sollte daher Entwurfsentscheidungen überprüfen, diese mit den
geschäftlichen Zielen vergleichen und sicherstellen, dass zwischen ihnen Übereinstimmung besteht.
Projektmanager
Um die Effektivität des Entwurfsprozesses zu gewährleisten, sollte die Geschäftsleitung eine Person oder
Personengruppe für die Rolle des Projektmanagers auswählen. Der Projektmanager fördert die Kooperation
zwischen Geschäftseinheiten sowie mit Gruppen, die Technologien wie DNS, Netzwerke und Windows NT
verwalten. Im Folgenden werden die Verantwortungsbereiche eines Projektmanagers aufgelistet:
•
•
•
•
•
Durchführen grundlegender Projektplanungsaufgaben wie Erstellen des Zeitplanes und Budgets
Vorantreiben des Active Directory-Entwurfs
Einbeziehen der geeigneten Mitarbeiter während jeder Phase des Entwurfsprozesses
Zentrale Kontaktperson für das Verzeichnisprojekt
Fördern von Konsens zwischen Teams
Active Directory-Entwurf: Schlüsselkonzepte
Während Sie Ihren Entwurf planen, sollten Sie sich klar machen, dass Sie sowohl ein logisches als auch ein
physisches Modell entwerfen.
Logische Modelle
Mit Active Directory können Administratoren die Elemente eines Netzwerkes (z. B. Benutzer, Computer, Geräte
usw.) in einer hierarchischen Struktur organisieren, die auf Containern basiert. Der Active Directory-Container
auf der höchsten Ebene wird als Gesamtstruktur bezeichnet. Innerhalb der Gesamtstruktur befinden sich
Domänen. Die Domänen enthalten wiederum Organisationseinheiten. Dies wird als logisches Modell bezeichnet,
da es unabhängig von physischen Aspekten der Bereitstellung entworfen wird, z. B. der Anzahl der
erforderlichen Replikate in jeder Domäne und der Netzwerktopologie.
Um die Verwaltung einer großen Anzahl an Objekten zu vereinfachen, unterstützt Active Directory außerdem
das Konzept der Verwaltungsdelegierung auf Containerebene. Über die Delegierung können Besitzer die
Autorität für Objekte auf andere Benutzer oder Gruppen übertragen. Die Delegierung ist nützlich, da auf diese
Weise die Verwaltung einer großen Anzahl an Objekten auf mehrere Personen verteilt werden kann, die für die
Verwaltung von bestimmten Gruppen und Objekttypen autorisiert sind.
Abbildung 1 stellt beispielsweise die Verteilung von Benutzern in einer fiktiven nordamerikanischen
Organisation dar. In diesem Beispiel enthält eine einzige Active Directory-Gesamtstruktur sämtliche Benutzer,
Computer, Geräte und andere Entitäten innerhalb der Organisation. Zur Unterstützung der regionsbasierten
Verwaltung hat die Organisation fünf Domänen (Westen, Mittlerer Westen, Nordosten, Südosten und
Lateinamerika) auf der Ebene unterhalb der Gesamtstruktur erstellt. Um weitere Delegierung zu unterstützen, hat
die Organisation die Domäne "Westen" in Organisationseinheiten unterteilt, die durch gestrichelte Linien
dargestellt werden.
Abbildung 1: Delegierung von Verwaltung innerhalb einer Organisation
In diesem Beispiel hat die Organisation bestimmte Aspekte der Verwaltung an den Abteilungsmanager der
Domäne "Westen" delegiert. Der Abteilungsmanager der Domäne "Westen" wiederum hat einige Aspekte der
Verwaltung an die Manager von Unterabteilungen delegiert. Auf ähnliche Weise unterstützt Active Directory
eine hierarchische Struktur, die mehrere Ebenen der Verwaltungsdelegierung ermöglicht, um den
Verzeichnisdienst und alle Objekte der Gesamtstruktur zu unterstützen.
Beim Entwurf des logischen Modells (der in den schrittweisen Verfahren weiter unten in diesem Handbuch
beschrieben wird) legen Sie die Grenzen der Gesamtstruktur, Domänen und Organisationseinheiten fest.
Physische Modelle
Nachdem Sie das logische Modell entworfen haben, ermitteln die physischen Eigenschaften des Netzwerkes,
welche zusätzlichen Aufgaben erforderlich sind. Zu diesen Aufgaben gehört u. U. die Entscheidung, wo die
Replikate von Domänen- und globalen Katalogdaten gespeichert werden sollen. Darüber hinaus müssen Sie die
Netzwerktopologie auf der Subnetzebene für Active Directory beschreiben, damit ein optimierter Pfad für LANübergreifende (Local Area Network) Kommunikationen, z. B. Replikationsverkehr, eingerichtet werden kann.
Replikationsentscheidungen sind von besonderer Bedeutung, weil sie sich sowohl auf den Netzwerkverkehr als
auch auf den Grad der Datensichtbarkeit auswirken. Beispielsweise können Domänencontroller keine
Verzeichnisdaten zwischen Gesamtstrukturen replizieren. Domänencontroller, die als Host für den globalen
Katalog dienen, enthalten eine partielle Beschreibung jedes Objekts in der Gesamtstruktur und stellen diese
Informationen in der Gesamtstruktur zur Verfügung, allerdings nur für Domänencontroller mit globalem
Katalog. Innerhalb jeder Domäne werden alle Datenaktualisierungen für Domänenobjekte automatisch auf alle
Domänencontroller der Domäne repliziert, nicht jedoch auf Domänencontroller in anderen Domänen.
Dieses Handbuch enthält schrittweise Anleitungen für alle Entscheidungen und Verfahren, die das physische
Modell betreffen.
Weiterführende Literatur
Dieses Handbuch enthält bestimmte Hintergrundinformationen zu den Konzepten, der Technologie und der
Terminologie von Active Directory. Wenn Sie mit den in diesem Handbuch dargestellten Active DirectoryKonzepten nicht vertraut sind, sollten Sie zur Einführung die folgenden Dokumente lesen.
•
"Active Directory Overview", online verfügbar unter:
http://www.microsoft.com/windows2000/server/evaluation/features/dirlist.asp (englischsprachig)
•
"Active Directory Architecture", online verfügbar unter:
http://www.microsoft.com/technet/treeview/default.asp?url=/technet/prodtechnol/ad/windows2000/depl
oy/projplan/adarch.asp (englischsprachig)
Die folgenden Dokumente enthalten weitere Hintergrundinformationen:
•
"The Active Directory Glossary", online verfügbar unter:
http://www.microsoft.com/windows2000/techinfo/howitworks/activedirectory/glossary.asp
(englischsprachig)
•
"Active Directory Users, Computers, and Groups", online verfügbar unter:
http://www.microsoft.com/technet/treeview/default.asp?url=/technet/prodtechnol/ad/windows2000/mai
ntain/adusers.asp (englischsprachig)
•
Der Abschnitt "Directory Services" der Technischen Bibliothek zu Windows 2000 (Windows 2000
Technical Library), online verfügbar unter:
http://www.microsoft.com/windows2000/technologies/directory/default.asp (englischsprachig)
•
•
Kapitel 1, "Active Directory", in Distributed Systems Guide in Windows 2000 Server Resource Kit
(englischsprachig)
Kapitel 9, "Designing the Active Directory Structure", in Deployment Planning Guide in
Windows 2000 Server Resource Kit (englischsprachig), online verfügbar unter:
(http://www.microsoft.com/TechNet/prodtechnol/windows2000serv/reskit/deploy/part3/chapt-9.asp
[englischsprachig])
Teil I: Ermitteln der Anzahl der Gesamtstrukturen in Ihrer
Organisation
Der Container auf der höchsten Ebene in Active Directory ist die Gesamtstruktur. Der erste Schritt des
Entwurfsprozesses besteht darin, dass der Active Directory-Architekt und der Projektmanager ermitteln, wie
viele Gesamtstrukturen die Organisation benötigt. Ein Entwurf mit einer einzigen Gesamtstruktur ist zu
bevorzugen, da dieses Modell am einfachsten zu verwalten ist. Eine Bereitstellung mit einer Gesamtstruktur
unterliegt jedoch gewissen Beschränkungen und eignet sich nicht für jede Organisation.
Mitarbeiter, die gegenwärtig die IT-Infrastruktur für eine eigenständige Abteilung innerhalb der Organisation
verwalten, ziehen es möglicherweise vor, die Rolle des Gesamtstrukturbesitzers zu übernehmen und eine eigene
Gesamtstruktur zu entwerfen. Es ist jedoch auch denkbar, dass potenzielle Gesamtstrukturbesitzer sich
entscheiden, eigenständige Abteilungen in einer Gesamtstruktur zusammenzuführen, um die Kosten für den
Entwurf und Betrieb von Active Directory zu reduzieren oder die gemeinsame Nutzung von Ressourcen zu
erleichtern.
In Teil I werden die Vor- und Nachteile beschrieben, die beim Festlegen der Anzahl an Gesamtstrukturen in der
Bereitstellung gegeneinander abgewogen werden müssen.
Funktionen von Gesamtstrukturen in Windows-Netzwerkentwürfen
Eine Gesamtstruktur ist eine einzelne Instanz einer Active Directory-Bereitstellung und ist somit
verwaltungstechnisch unabhängig von anderen Active Directory-Bereitstellungen innerhalb der Organisation.
Die Gesamtstruktur repräsentiert also die höchste Ebene im Hinblick auf Besitz und Kontrolle und stellt eine
vollständige Active Directory-Sicherheits- und -Verwaltungsgrenze dar. Innerhalb dieser Grenze befinden sich
eine Reihe gemeinsamer Elemente. Dazu zählen u. a. die Folgenden:
•
Schema
Das Active Directory-Schema enthält Informationen zu jeder Objektklasse sowie zu allen Attributen
jeder Objektklasse, die in der Gesamtstruktur gespeichert werden können. Beispielsweise stellt jedes
Benutzerkonto eine Instanziierung der Klasse Users dar, die in dem Schema definiert wurde. Die
Schemabeschreibung wird in einem Teil der Verzeichnisdatenbank gespeichert, der auf jeden
Domänencontroller in der Gesamtstruktur repliziert wird.
•
Konfigurationsdaten
Eine Active Directory-Bereitstellung wird durch eine Reihe von Konfigurationsobjekten beschrieben,
die Daten zur Definition von Infrastruktur- und Topologieelementen wie Domänen, Standorten und
Standortverknüpfungen enthalten. Die Konfigurationsdaten werden ebenfalls in einem Teil der
Verzeichnisdatenbank gespeichert, der auf jeden Domänencontroller in der Gesamtstruktur repliziert
wird.
•
Durchsuchbarer globaler Katalog mit Verzeichnisobjekten
Administratoren können bestimmen, dass Domänencontroller neben Replikaten von Domänendaten
auch eine Teilkopie jedes Objekts in der Gesamtstruktur speichern. Die Daten werden in einem Teil der
Verzeichnisdatenbank aufbewahrt, der als globaler Katalog bezeichnet wird. Das globale
Katalogkonzept ermöglicht eine schnelle und effiziente Suche nach Objekten in der Gesamtstruktur.
Jeder Domänencontroller mit globalem Katalog in der Gesamtstruktur enthält eine identische Kopie des
globalen Katalogs, unabhängig davon, in welcher Domäne er sich befindet.
•
Vertrauensstellungen zwischen allen Domänen in der Gesamtstruktur
Active Directory erstellt automatisch transitive, bidirektionale Vertrauensstellungen zwischen allen
Domänen in einer Gesamtstruktur. Jeder Mitgliedcomputer kann alle Benutzer oder Gruppen anderer
Domänen in der Gesamtstruktur erkennen und diesen Zugriff gewähren.
Gesamtstrukturen können Millionen von Objekten enthalten, so dass in den meisten Fällen eine einzige
Gesamtstruktur ausreicht, um die Anforderungen einer Organisation zu erfüllen. Abhängig von dem
Verwaltungsmodell Ihrer Organisation kann es jedoch erforderlich sein, mehrere Gesamtstrukturen
bereitzustellen. Während der ersten Phase des Active Directory-Entwurfs ermittelt der Active DirectoryArchitekt die Anzahl an Gesamtstrukturen, die zum Erreichen der geschäftlichen Ziele der Organisation
erforderlich sind, und weist jeder Gesamtstruktur einen Besitzer zu.
Aspekte beim Ermitteln der Anzahl an Gesamtstrukturen
Der Active Directory-Architekt und der Projektmanager sind für die Erstellung eines Gesamtstrukturplanes für
die Organisation verantwortlich. Der Plan sollte eine Liste der zu entwerfenden Gesamtstrukturen für die
Organisation sowie die folgenden Informationen enthalten:
•
•
Den Namen jedes Gesamtstrukturbesitzers
Den Umfang jeder Gesamtstruktur
Vergleich zwischen Dienst- und Datenbesitz
Damit Sie die in diesem Handbuch beschriebenen Besitzerrollen verstehen können, sollten Sie sich über die
Unterschiede zwischen Dienst- und Datenbesitz im Klaren sein. Vor der Einführung von Active Directory
definierte das Windows NT-Verwaltungsmodell eine Domäne als eine Gruppe von Objekten, die durch einen
Administrator verwaltet werden. Dieses Handbuch stellt ein Konzept vor, bei dem die IT-Verwaltung aufgeteilt
wird. In Windows 2000 wird zwischen zwei Arten von Administratoren unterschieden: Datenadministratoren
(oder Objektadministratoren) und Dienstadministratoren (oder Verzeichnisadministratoren).
Der Hauptvorteil dieser geteilten Verwaltung besteht darin, dass die einzelnen Unternehmenseinheiten keine
Mitarbeiter zur Unterstützung des Verzeichnisdienstes abstellen und ausbilden müssen. Stattdessen können sich
die Unternehmenseinheiten auf ihr Kerngeschäft konzentrieren und müssen lediglich die Daten in dem
Verzeichnis verwalten.
Um die Daten im Verzeichnis verwalten zu können, müssen Datenadministratoren ähnliche Funktionen
ausführen und über ähnliche Rechte und Berechtigungen verfügen wie derzeit Windows NT-Administratoren. In
Windows 2000 unterstützen Datenadministratoren die Benutzer und Gruppen in einer Gesamtstruktur, indem sie
z. B. die folgenden Funktionen ausführen:
•
•
Hinzufügen und Entfernen von Computern, Benutzern, Gruppen und Organisationseinheiten
Erstellen von Gruppenrichtlinieneinstellungen
Es gibt keine direkte Übereinstimmung zwischen Dienstadministratoren und den administrativen Rollen im
Windows NT-Domänenmodell. Dienstadministratoren stellen den Verzeichnisdienst bereit, verwalten Domänen,
sind Besitzer der Domänencontroller und verwalten die Konfiguration des Verzeichnisses. Für Windows 2000
Active Directory unterstützen Dienstadministratoren die Infrastruktur der Gesamtstruktur, indem sie z. B. die
folgenden Funktionen ausführen:
•
•
•
•
•
•
Erstellen oder Entfernen von Domänen
Ändern des Schemas
Installieren und Entfernen von Domänencontrollern
Verwalten der Konfiguration des Domänencontrollers
Überwachen des Zustands des Domänencontrollers
Verwalten der Standorttopologie
Aufgrund der Trennung zwischen Daten- und Dienstverwaltung kann ein Administrator die Kontrolle über
sämtliche Benutzer und Computer in einer Abteilung behalten, während er die Dienstverwaltung an eine andere
Gruppe delegiert. Größere Organisationen können auf diese Weise die Vorteile eines einzelnen zentralen
Verzeichnisses nutzen, ohne ihre aktuellen Geschäftspraktiken ändern zu müssen.
Im weiteren Verlauf dieses Handbuches wird durchgehend zwischen Dienstbesitzern und Datenbesitzern
unterschieden.
Analysieren der Rolle des Gesamtstrukturbesitzers
Der Gesamtstrukturbesitzer ist in letzter Instanz für die Bereitstellung der Verzeichnisdienste im WindowsNetzwerk verantwortlich. Im Folgenden werden die Verantwortungsbereiche des Gesamtstrukturbesitzers
aufgelistet:
•
•
Besitz der Schema- und Konfigurationscontainer
Besitz von Daten, die in der Stammdomäne der Gesamtstruktur enthalten sind
In Tabelle 2 werden diese und andere dem Gesamtstrukturbesitzer zugewiesene Rollen sowie die damit
verbundenen Verantwortungsbereiche aufgelistet. Der Gesamtstrukturbesitzer kontrolliert die Gesamtstruktur
mithilfe von drei Sicherheitsgruppen:
•
•
•
Domänen-Admins (der Stammdomäne der Gesamtstruktur)
Organisations-Admins
Schema-Admins
Tabelle 2: Rollen und Verantwortungsbereiche des Gesamtstrukturbesitzers
Rolle
Dienstbesitzer von Domänencontrollern in der
Stammdomäne der Gesamtstruktur
Administrativer Besitzer von Daten in der
Stammdomäne der Gesamtstruktur
Administrative Gesamtverantwortung für alle
Domänendaten
Administrativer Besitzer des Schemas
Administrativer (und Richtlinien-) Besitzer der
Konfiguration
Verantwortungsbereich
Kontrolliert die Domänencontrollerkonfiguration in der
Gesamtstruktur und verwaltet so Replikationsaspekte.
Kontrolliert die Mitgliedschaft der Sicherheitsgruppen
Domänen-Admins, Organisations-Admins und
Schema-Admins in der Stammdomäne der
Gesamtstruktur.
Über die Gruppe Organisations-Admins kann der
Gesamtstrukturbesitzer an jeder Stelle im Verzeichnis
Fehler korrigieren. Sie können den administrativen
Zugriff auf Domänen, die keine Stammdomänen sind,
für Mitglieder der Gruppe Organisations-Admins zwar
sperren, aber dies wird nicht empfohlen.
Über Schema-Admins:
• Legt die Richtlinien für Schemaerweiterungen fest
• Legt den Prozess für Schemaerweiterungen fest
• Steuert die Erweiterung des Schemas
Über Organisations-Admins:
• Ist Gatekeeper für neue Domänen in der
Gesamtstruktur
• Ist administrativer Besitzer der Standorttopologie
Anmerkung Beim Gesamtstrukturbesitzer sollte es sich um eine äußerst vertrauenswürdige Person handeln.
Daher besteht kein Grund, den Zugriff des Gesamtstrukturbesitzers auf Daten in Domänen, die keine
Stammdomänen sind, zu sperren. Falls die Daten in einer Domäne durch böswillige oder versehentliche
Aktionen beschädigt werden, benötigt der Gesamtstrukturbesitzer Zugriff auf die Domäne, um das Problem
beheben zu können.
Beziehungen zwischen Dienstbesitzerrollen
Aufgrund der Verwaltung des Verzeichnisses und der Delegierung der Datenverwaltung innerhalb der
Gesamtstruktur entstehen in einem auf optimalen Vorgehensweisen basierenden Modell neue administrative
Rollen. Abbildung 2 stellt die Beziehungen zwischen den Verantwortungsbereichen der empfohlenen ITVerwaltungsrollen dar. Diese Beziehungen spiegeln die Delegierung der Verantwortung für den
Verzeichnisdienst wider und beziehen sich nicht notwendigerweise auf die Berichtstruktur einer Organisation.
Beispielsweise übernimmt der DNS-Besitzer die Bereitstellung und Konfiguration der DNS-Dienste, die durch
den Gesamtstrukturbesitzer und u. U. die jeweiligen Domänenbesitzer in der Gesamtstruktur vorgegeben
wurden.
Der Gesamtstrukturbesitzer delegiert die Verwaltung einzelner Domänen an eine Gruppe von Domänenbesitzer,
die Verwaltung der Standorttopologie an einen Standorttopologiebesitzer und die Verwaltung des DNS-Dienstes
an einen DNS-Besitzer. Die Domänenbesitzer wiederum delegieren die Verwaltung der Organisationseinheiten
(OEs) an eine Gruppe von OE-Besitzern und die Verwaltung des DNS-Dienstes an den DNS-Besitzer.
Abbildung 2: Hierarchie der administrativen Rollen für den Verzeichnisdienst in einer Gesamtstruktur
mit vier Domänen
Tabelle 3 unterteilt die administrativen Rollen in Active Directory in Dienst- und Datenbesitzerrollen.
Tabelle 3: Dienst- und Datenbesitzerrollen in Active Directory
Dienstbesitzer
Gesamtstrukturbesitzer
Domänenbesitzer
DNS-Besitzer
Standorttopologiebesitzer
Datenbesitzer
Gesamtstrukturbesitzer (für Stammdomäne)
OE-Besitzer
In einer umfangreichen Gesamtstruktur kann jede Besitzerrolle von mehreren Administratoren ausgeführt
werden, die jeweils über die erforderliche administrative Autorität für die Durchführung bestimmter Aufgaben
verfügen. In kleineren Organisationen kann eine Person mehrere Rollen übernehmen.
Anmerkung Nur der Gesamtstrukturbesitzer kann Domänenbesitzer bestimmen. Domänenbesitzer haben
administrative Kontrolle über Domänencontroller in der Gesamtstruktur und müssen äußerst vertrauenswürdig
sein.
Optimale Vorgehensweisen für Gesamtstrukturmodelle
Der optimale Gesamtstrukturentwurf hängt von den IT-Geschäftspraktiken Ihrer Organisation ab. Die folgenden
Gesamtstrukturmodelle werden für Organisationen empfohlen:
•
•
•
Modell mit einer einzigen globalen Gesamtstruktur
Abonnementmodell
Mehrere, den Unternehmenseinheiten entsprechende Gesamtstrukturen
Modell mit einer Gesamtstruktur
Wählt eine Organisation das Modell mit einer Gesamtstruktur, werden alle Verzeichnisobjekte der Organisation
in einer einzigen Gesamtstruktur gespeichert und verwaltet. Sofern eine einzige Gesamtstruktur praktikabel ist,
stellt dies die ideale Lösung dar, da sie mit dem geringsten Verwaltungsaufwand verbunden ist. In Abbildung 3
wird ein Entwurf mit einer Gesamtstruktur für eine Organisation mit drei Abteilungen dargestellt. In diesem
Active Directory-Entwurf sind alle drei Abteilungen Teil einer einzigen Gesamtstruktur.
Abbildung 3: Ein Entwurf mit einer Gesamtstruktur für eine Organisation mit drei Abteilungen
Gesamtstrukturentwurf mit Abonnements
Ein Gesamtstrukturentwurf mit Abonnements enthält einige eigenständige Gesamtstrukturen auf
Abteilungsebene, aber die meisten Abteilungen sind in einer größeren Gesamtstruktur konsolidiert, die von einer
zentralen IT-Organisation betrieben wird. Abonnementgesamtstrukturen haben den Vorteil, dass die
Bereitstellung in Abteilungen, die sich für Active Directory entscheiden, beschleunigt werden kann, während
Unternehmenseinheiten, für die Sicherheits- und Freigabeaspekte im Vordergrund stehen, eigene
Gesamtstrukturen entwerfen und verwalten können.
In Abbildung 4 wird ein Gesamtstrukturentwurf mit Abonnements für eine Organisation mit drei
Unternehmenseinheiten dargestellt. In diesem Beispiel werden zwei Unternehmenseinheiten in einer
Gesamtstruktur zusammengefasst, während für die dritte Abteilung eine zweite Gesamtstruktur erstellt wird.
Abbildung 4: Ein gemischtes Gesamtstrukturmodell für eine Organisation mit drei Abteilungen
Entwurf mit mehreren Gesamtstrukturen
In einem Modell mit mehreren Gesamtstrukturen stellen die meisten Unternehmenseinheiten innerhalb einer
Organisation eine eigene Active Directory-Gesamtstruktur bereit. Ein Modell mit mehreren Gesamtstrukturen
eignet sich für Organisationen, deren Unternehmenseinheiten administrative Autonomie behalten möchten (oder
müssen). Dieses Modell verursacht den meisten Verwaltungsaufwand.
In Abbildung 5 wird ein Entwurf mit mehreren Gesamtstrukturen für eine Organisation mit drei Abteilungen
dargestellt. Jede Unternehmenseinheit hat bis zum gegenwärtigen Zeitpunkt eine eigene IT-Infrastruktur
verwaltet. Aus diesem Grund wurde entschieden, dass für jede Unternehmenseinheit eine unabhängige Active
Directory-Gesamtstruktur entworfen und bereitgestellt werden soll.
Abbildung 5: Ein Modell mit mehreren Gesamtstrukturen, so dass drei Active DirectoryGesamtstrukturen entstehen
Entwurfsprozess für die Gesamtstruktur
Abbildung 6 stellt den Entwurfsprozess für eine Gesamtstruktur dar. Während des GesamtstrukturEntwurfsprozesses ermitteln der Projektmanager und der Active Directory-Architekt, wie viele Gesamtstrukturen
für die Organisation entworfen werden sollen. Eine einzige Gesamtstruktur ist ideal, da sie den geringsten
Verwaltungsaufwand verursacht. Aufgrund bestimmter Einschränkungen ist eine einzige Gesamtstruktur jedoch
u. U. nicht möglich, und so besteht das Ziel darin, die Anzahl der Gesamtstrukturen möglichst gering zu halten.
Um die Anzahl der erforderlichen Gesamtstrukturen zu ermitteln, führen Sie die folgenden Schritte durch:
1.
2.
Identifizieren Sie alle potenziellen Verzeichnisdienstanbieter.
Weisen Sie einer Gesamtstruktur Abteilungen auf der Grundlage technischer und organisatorischer
Faktoren zu.
Abbildung 6: Flussdiagramm der Aufgaben, die zum Ermitteln der Anzahl an Gesamtstrukturen in Ihrer
Organisation erforderlich sind
Identifizieren potenzieller Verzeichnisdienstanbieter
Ermitteln Sie die IT-Administratoren auf der höchsten Ebene Ihrer Organisation, die die Autorität besitzen,
Verzeichnisdienste für ein Windows-Netzwerk bereitzustellen. Möglicherweise stellen Sie dabei fest, dass
mehrere Entitäten in Ihrer Organisation in der Lage sind, Verzeichnisdienste bereitzustellen.
Ihre Organisation verfügt u. U. über ein zentrales IT-Modell mit einem Leiter der EDV-Abteilung (Chief
Information Officer oder CIO), der die IT-Verwaltung bei Bedarf an Abteilungsadministratoren delegiert. Diese
Situation lässt vermuten, dass nur ein potenzieller Verzeichnisdienstanbieter und somit nur ein Kandidat für die
Gesamtstruktur zur Verfügung steht.
Es ist jedoch auch möglich, dass Ihre Organisation über ein dezentralisiertes IT-Modell verfügt, bei dem ITAdministratoren auf Abteilungsebene die Netzwerkverwaltung und -delegierung innerhalb eigenständiger
Organisationen durchführen. Gleichrangige CIOs sind häufig in Organisationen mit verteilter Autorität zu
finden. In diesem Fall stehen wahrscheinlich mehrere potenzielle Verzeichnisdienstanbieter und damit mehrere
Kandidaten für die Gesamtstruktur zur Verfügung.
Möglicherweise hat Ihre Organisation Active Directory bereits für einen anderen Zweck zur Verfügung gestellt.
Betrachten Sie alle Gesamtstrukturbesitzer als potenzielle Verzeichnisdienstanbieter. Das vorhandene
Verzeichnis unterstützt vielleicht Messaging, Windows-Netzwerkdienste für eine begrenzte Anzahl an
Unternehmenseinheiten oder eine andere Funktion. Ob das vorhandene Active Directory als Grundlage für
erweiterte Verzeichnisdienste dienen kann, hängt von seinem Zweck und der Art der Bereitstellung ab.
Zuweisen von Gesamtstrukturen
Ermitteln Sie die minimale Anzahl an Gesamtstrukturen, die für Ihre Organisation erforderlich ist, um die
geschäftlichen Anforderungen zu erfüllen. Um die korrekte Anzahl an Gesamtstrukturen für Ihre Organisation zu
bestimmten, führen Sie folgende Schritte durch:
1.
2.
3.
Falls Sie nur einen potenziellen Verzeichnisdienstanbieter ermittelt haben, kann diese Person, die die
Rolle des Gesamtstrukturbesitzers übernehmen wird, mit "Teil II: Erstellen eines
Gesamtstrukturentwurfs" fortfahren.
Falls mehrere potenzielle Verzeichnisdienstanbieter zur Verfügung stehen, sollten Sie überlegen, ob ein
Kandidat die Rolle des Gesamtstrukturbesitzers übernehmen kann, während die anderen Kandidaten an
der Gesamtstruktur teilnehmen. Der folgende Abschnitt, "Teilnahme an einer einzigen Gesamtstruktur
oder einer Gesamtstruktur mit Abonnements" unterstützt Sie bei diesen Entscheidungen.
Wenn sich nicht alle potenziellen Verzeichnisdienstanbieter auf eine einzige Gesamtstruktur einigen
können, ermitteln Sie, ob eine Gesamtstruktur mit Abonnements die Anforderungen der meisten
potenziellen Verzeichnisdienstanbieter erfüllt.
Anmerkung Legen Sie einen Termin fest, an dem Sie als potenzieller Verzeichnisdienstanbieter sich
entscheiden, ob Sie einer Gesamtstruktur beitreten wollen. Wenn die Erstellung einer einzigen
Gesamtstruktur bedeutet, dass Sie Ihre Geschäftspraktiken ändern müssen, und dies mehr Zeit in
Anspruch nehmen würde als erwartet, sollten Sie besser eine eigene Gesamtstruktur erstellen.
4.
Falls Ihr Versuch, eine Gesamtstruktur mit Abonnements zu implementieren, fehlschlägt, sollte jeder
potenzielle Verzeichnisdienstanbieter eine neue, eigene Gesamtstruktur erstellen.
Die Auswirkungen einer solchen Entscheidung werden im Abschnitt "Erstellen einer eigenen
Gesamtstruktur" dargestellt.
Möglicherweise mangelt es einem potenziellen Verzeichnisdienstanbieter an Interesse, finanziellen Mitteln oder
Autorität, um die Bereitstellung durchzuführen. In diesem Fall kann der potenzielle Verzeichnisdienstanbieter
die Bereitstellung von Active Directory auf einen späteren Zeitpunkt verschieben, so dass die übrigen
potenziellen Verzeichnisdienstanbieter mit ihren Entwürfen fortfahren können.
Teilnahme an einer einzigen Gesamtstruktur oder einer Gesamtstruktur mit
Abonnements
Möglicherweise ist in Ihrer Organisation bereits eine Gesamtstruktur vorhanden, oder eine Gruppe innerhalb
Ihrer Organisation hat sich bereit erklärt, die Verwaltung des Verzeichnisses für die anderen Abteilungen zu
übernehmen. Potenzielle Verzeichnisdienstanbieter sollten an einer Gesamtstruktur teilnehmen.
Der Besitz bzw. die Teilnahme an einer Gesamtstruktur ist für den Kandidaten mit unterschiedlichen
Verantwortungsbereichen verbunden. Der Gesamtstrukturteilnehmer als Datenbesitzer ist für die Verwaltung der
Daten verantwortlich, während der Gesamtstrukturbesitzer als Dienstbesitzer für die Verwaltung des
Verzeichnisdienstes verantwortlich ist. Der Datenbesitzer stellt z. B. sicher, dass das Kennwort eines Benutzers
korrekt festgelegt ist, während der Dienstbesitzer dafür sorgt, dass das Kennwort auf alle Domänencontroller
repliziert wird. In Tabelle 4 werden die mit dem Besitz bzw. der Teilnahme an einer Gesamtstruktur
verbundenen Verantwortungsbereiche einander gegenübergestellt.
Tabelle 4: Ein Vergleich zwischen dem Besitz und der Teilnahme an einer Gesamtstruktur
Besitz einer Gesamtstruktur
• Steuern der Dienstbereitstellung
• Gewährleisten der Dienstqualität
• Delegieren der Datenverwaltung an einzelne
Datenbesitzer
Teilnahme an einer Gesamtstruktur
• Auslagern der Dienstbereitstellung
• Verwalten der eigenen Daten
Indem Sie die von einer anderen Gruppe bereitgestellten Verzeichnisdienste abonnieren, können Sie Ihre
Verwaltungskosten reduzieren:
•
•
•
Sie müssen keinen eigenen Entwurfsprozess initiieren.
Sie vermeiden die Duplizierung von Verzeichnisverwaltungsaufgaben wie die Folgenden:
o Expertenteams für die Planung von Verzeichnisbereitstellung und -betrieb
o Hardwareverwaltung der Domänencontroller
o Verwaltung der Verzeichnisstruktur
Benutzer, Ressourcen und Dienste sind nicht in verschiedenen Gesamtstrukturen voneinander isoliert.
Eine gemeinsame Gesamtstruktur ist für viele Situationen geeignet und vereinfacht die Active DirectoryVerwaltung erheblich. Die gemeinsame Verwendung einer einzigen, konsistenten Konfiguration in allen
Domänen einer Gesamtstruktur hat u. a. die folgenden Vorteile:
•
•
•
•
Schemaänderungen, die alle Domänen betreffen, müssen nur einmal angewendet werden.
Konfigurationsänderungen, die alle Domänen betreffen, müssen nur einmal angewendet werden.
Für alle Benutzer steht ein einziger globaler Katalog zu Verfügung.
Es bestehen automatisch Vertrauensstellungen zwischen allen Domänen.
Ob die gemeinsame Verwendung einer Gesamtstruktur realisierbar und sinnvoll ist, hängt von Ihren aktuellen
Geschäftspraktiken ab.
Einige potenzielle Verzeichnisdienstanbieter ziehen es möglicherweise vor, nicht an einer gemeinsamen
Gesamtstruktur teilzunehmen, da bestimmte Sicherheitsanforderungn bzw. Netzwerk- und
Verwaltungsbeschränkungen in der gemeinsamen Gesamtstruktur nicht berücksichtigt werden. Tabelle 5 fasst
die grundlegenden Merkmale einer gemeinsamen Gesamtstruktur zusammen.
Tabelle 5: Merkmale einer gemeinsamen Gesamtstruktur
Faktor
Notwendig
Sicherheit
Verwaltung
Namensauflösung
Empfohlen
Netzwerkfunktionalität
Organisationsübergreifende Zusammenarbeit
IT-Organisation
Merkmale der gemeinsamen Gesamtstruktur
• Sie können dem Gesamtstrukturbesitzer und allen
Domänenbesitzern in der Gesamtstruktur vertrauen.
• Alle Domänencontroller befinden sich an sicheren
Standorten, oder Sie akzeptieren die mit unsicheren
Standorten verbundenen Risiken.
• Sie können den allgemeinen Schema- und
Konfigurationsrichtlinien folgen, die vom
Gesamtstrukturbesitzer festgelegt werden.
• Der DNS-Dienst kann Namen innerhalb der
Gesamtstruktur auflösen.
• Domänencontroller sind nicht durch Firewalls
voneinander getrennt.
• Domänencontroller sind nicht durch
Netzwerkadressübersetzungs-Geräte (Network Address
Translation oder NAT) getrennt.
• Domänenvertrauensstellungen zwischen
Organisationen sind gegenwärtig vorhanden.
• Eine Vielzahl von Ressourcen wird zurzeit von
Abteilungen gemeinsam verwendet.
• Gemeinsame IT-Infrastrukturgruppe.
• Wird die Verwaltung des Verzeichnisdienstes
ausgelagert, wird sie von einem einzigen Anbieter
übernommen.
Wichtig Jeder Domänencontroller in der Gesamtstruktur enthält eine beschreibbare Kopie der Schema- und
Konfigurationscontainer. Falls eine Person auf einem Domänencontroller Software installieren oder sich
physischen Zugang verschaffen kann, kann diese Person die Sicherheitsfunktionen von Windows 2000 umgehen
und Änderungen an diesen Containern vornehmen. Dies stellt ein Sicherheitsrisiko für die Gesamtstruktur dar.
Die Richtlinien für optimale Vorgehensweisen geben folgende Empfehlungen:
•
•
Alle Administratoren, z. B. Domänenadministratoren, die Software auf einem Domänencontroller
installieren, sollten äußerst vertrauenswürdige Personen sein.
Domänencontroller sollten an sicheren Standorten aufgestellt werden.
Sind die erforderlichen Merkmale nicht vorhanden, sollte die Gesamtstruktur nicht gemeinsam verwendet
werden. Ein potenzieller Gesamtstrukturteilnehmer kann von den empfohlenen Merkmalen abweichen und
dennoch eine Gesamtstruktur zur Verfügung stellen. Fehlen einer potenziellen Gesamtstruktur jedoch zu viele
dieser Merkmale, kann die Gesamtstrukturteilnahme technische Schwierigkeiten verursachen und weniger
Vorteile bieten. Das Abweichen von den in Tabelle 5 aufgelisteten Merkmalen wird nicht empfohlen. Falls Ihr
Entwurf abweicht, sollten Sie bei dem Entwurf und der Bereitstellung die Unterstützung eines Experten
hinzuziehen.
Wenn Sie einer Gesamtstruktur beitreten möchten, sollten Sie sicherstellen, dass der Besitz eindeutig geregelt ist.
Die Aufteilung des Gesamtstrukturbesitzes auf mehrere IT-Gruppen bzw. die Aufteilung der Verwaltung auf
mehrere externe Firmen kann organisatorische Probleme mit sich bringen, die Sie besser vermeiden sollten.
Erstellen einer eigenen Gesamtstruktur
Obwohl die gemeinsame Verwendung einer Gesamtstruktur eine Reihe von Vorteilen bietet, hängen diese vom
Umfang der Zusammenarbeit zwischen den Abteilungen ab. In folgenden Situationen ist eine einzige
Gesamtstruktur für Ihre Organisation nicht geeignet:
•
Autonomie ist erforderlich.
Sie benötigen vollständige Kontrolle über die Dienstbereitstellung oder können die Bedingungen eines
anderen Gesamtstrukturbesitzers nicht akzeptieren.
•
Sie arbeiten grundsätzlich nicht mit anderen Abteilungen zusammen.
Falls eine Zusammenarbeit besteht, sollten Sie die Art dieser Zusammenarbeit genauer definieren.
Zusammenarbeit kann z. B. den Austausch von E-Mails oder eine engere Kooperation bedeuten, die
u. a. den Zugriff auf das Intranet des Kooperationspartners, den Zugriff auf Freigaben und die
gemeinsame Nutzung von Anwendungen umfassen kann. Wenn Abteilungen eng zusammenarbeiten,
sollten diese sich in derselben Gesamtstruktur befinden.
Ist Zusammenarbeit dagegen nicht die Regel, sondern die Ausnahme, können Sie individuelle
Vertrauensstellungen mit Domänen in anderen Gesamtstrukturen konfigurieren. So können Sie z. B. die
Zusammenarbeit zwischen Abteilungen mithilfe von Firewalls einschränken.
•
Vorherige Infrastruktur-Bereitstellungen sind aufgrund unterschiedlicher Verwaltungsformen oder
Zielsetzungen innerhalb Ihrer Organisation fehlgeschlagen.
Wenn Sie eine Gesamtstruktur entwerfen, sollten Sie daran denken, dass Verwaltungsautonomie ihren Preis hat.
Autonomie und Verwaltungseffizienz sollten daher sorgfältig gegeneinander abgewogen werden.
Anmerkung Ausgliederungen (Divestitures) stellen einen Unsicherheitsfaktor bei der Planung einer
Gesamtstruktur dar. Sollen Sie eine Abteilung, die ausgegliedert werden soll, in die Gesamtstruktur
miteinbeziehen oder eine eigene Gesamtstruktur für die Abteilung erstellen? Die Erstellung einer separaten
Gesamtstruktur empfiehlt sich nur, wenn Sie sicher sind, dass die Abteilung tatsächlich ausgegliedert wird.
Andernfalls sollte die Abteilung in die Gesamtstruktur miteinbezogen werden. Ist die Ausgliederung erfolgreich,
erfordert die Migration der Abteilung in eine neue Gesamtstruktur ebenso viel Mühe wie die Integration der
Abteilung in die Gesamtstruktur, falls die Ausgliederung fehlschlägt.
Implikationen der Zusammenarbeit zwischen Gesamtstrukturen
Da jede Gesamtstruktur separat verwaltet wird, erhöht das Hinzufügen einer weiteren Gesamtstruktur zu Ihrem
Entwurf den Verwaltungsaufwand für Ihre Organisation. Bei der Entscheidung für oder gegen die Erstellung
einer eigenen Gesamtstruktur sollten Sie die in Tabelle 6 aufgelisteten Auswirkungen und die möglichen
Vorteile gegeneinander abwägen. Wenn Ihre Abteilung nur selten mit anderen Unternehmenseinheiten
zusammenarbeitet, spielen diese Faktoren bei Ihrer Entscheidung u. U. nur eine untergeordnete Rolle.
Tabelle 6: Auswirkungen der Zusammenarbeit zwischen Gesamtstrukturen
Veränderte Funktionalität
Keine automatischen transitiven Vertrauensstellungen
Auswirkung
Auf Ressourcen in einer anderen Gesamtstruktur kann
nur zugegriffen werden, wenn zwischen den
betreffenden Domänen explizite Vertrauensstellungen
eingerichtet wurden.
Keine Kerberos-Authentifizierung
Bei der Authentifizierung zwischen Gesamtstrukturen
ist keine Delegierung der Authentifizierung und keine
gegenseitige Authentifizierung möglich.
Kein zentraler globaler Katalog mit Objekten
Um eine einzige Ansicht mehrerer Gesamtstrukturen zu
erstellen, müssen Sie eine Software zur
Verzeichnissynchronisierung, z. B. MMS (Microsoft
Metadirectory Services), verwenden. Die Anwesenheit
mehrerer globaler Kataloge kann Auswirkungen auf
Anwendungen wie Exchange 2000 haben.
Keine Anmeldung mit UPN (User Principal Name) wie Befinden sich das Computerkonto und das
bei E-Mails
Benutzerkonto in verschiedenen Gesamtstrukturen,
müssen zur Benutzeridentifizierung alte Namen
verwendet werden.
Delegieren der nächsten Schritte an die Gesamtstrukturbesitzer
An dieser Stelle im Entwurfsprozess sollte eine Liste mit Gesamtstrukturen und Gesamtstrukturbesitzern
vorliegen. Jeder Gesamtstrukturbesitzer kann nunmehr unabhängig mit der nächsten Phase des
Entwurfsprozesses und "Teil II: Erstellen eines Gesamtstrukturentwurfs" fortfahren. Jeder
Gesamtstrukturbesitzer sollte einen Projektmanager und einen Active Directory-Architekten benennen, die den
Entwurf der Gesamtstruktur überwachen.
Abbildung 7 stellt die Aufgaben dar, die beim Erstellen eines Gesamtstrukturentwurfs durchgeführt werden
müssen. Alle vorgesehenen Gesamtstrukturbesitzer der Organisation erstellen einen separaten Active DirectoryEntwurf.
Abbildung 7: Flussdiagramm der Aufgaben, die jeder Gesamtstrukturbesitzer beim Entwurf der
Gesamtstruktur ausführen muss
Teil II: Erstellen eines Gesamtstrukturentwurfs
Erstellen eines Domänenentwurfs
An dieser Stelle im Active Directory-Entwurfsprozess wurden Gesamtstrukturbesitzer identifiziert, die nunmehr
mit dem Entwurf fortfahren können. Der nächste Schritt des Entwurfsprozesses besteht im Entwurf der
Stammdomäne für die Gesamtstruktur und der Identifizierung aller untergeordneter Domänen dieser
Stammdomäne.
Funktionen von Domänen in Windows-Netzwerkentwürfen
Eine Domäne ist eine einzelne Partition der Active Directory-Gesamtstruktur. Organisationen partitionieren die
Active Directory-Gesamtstruktur in mehrere Domänen, um zu verhindern, dass Daten auf Standorte repliziert
werden, an denen sie nicht erforderlich sind. Auf diese Weise kann ein Verzeichnis über ein Netzwerk mit
eingeschränkter Bandbreite global skaliert werden.
Für Active Directory stellt die Domäne die Verwaltungsgrenze für Objekte, Benutzer, Gruppen und Computer
dar. Darüber hinaus unterstützt die Domäne eine Reihe von Kernfunktionen im Hinblick auf die Verwaltung. Im
Rahmen eines Netzwerkbetriebssystems erfüllt eine Domäne u. a. folgende wichtige Funktionen:
•
Authentifizierung
Jede Domäne enthält Sicherheitsprincipalobjekte, z. B. Benutzer, Gruppen und Computer, denen
Zugriff auf Ressourcen im Netzwerk gewährt oder verweigert werden kann. Ein Benutzer kann nur von
dem Domänencontroller in der Domäne authentifiziert werden, auf dem sich das Konto des Benutzers
befindet.
•
Richtlinienbasierte Verwaltung
Das Problem, wie die Verwaltung von Hunderttausenden von Objekten in einer Domäne standardisiert
werden kann, wurde in Active Directory durch richtlinienbasierte Verwaltung gelöst. Beispielsweise
können Sie Gruppenrichtlinien verwenden, um Benutzer- und Computerkonfigurationen zu
standardisieren. Gruppenrichtlinien können im Rahmen einer Windows 2000-Migration oder zu einem
beliebigen Zeitpunkt nach der Bereitstellung von Active Directory erstellt und angewendet werden.
•
Sicherheitsrichtlinien für Benutzerkonten
•
Bestimmte Sicherheitsrichtlinien, die für einzelne Domänenbenutzerkonten gelten, können nur auf
Domänenbasis festgelegt werden. Hierzu gehören die Folgenden:
o Kennwortrichtlinien
o Kontosperrungsrichtlinien
o Kerboros-Ticketrichtlinien
Dient als Verzeichnis für die Veröffentlichung freigegebener Ressourcen.
In Active Directory können Dienste Verbindungsinformationen zu freigegebenen Ressourcen
veröffentlichen. Beispielsweise können Druckerressourcen in einer Domäne veröffentlicht werden, um
Benutzern die Suche zu erleichtern.
Gegenüberstellung von Windows NT- und Active Directory-Domänen
Eine typische Organisation, in der Windows NT ausgeführt wird, verfügt über mehrere Domänen. Diese
Domänen sind erforderlich, um unterschiedliche Geschäftspraktiken, regionale Abteilungen und
Beschränkungen von Windows NT zu berücksichtigen. Drei Produktbeschränkungen von Windows NT haben
eine große Anzahl an Domänen zur Folge:
•
•
•
Größenbeschränkung der Kontendatenbank
Durchführung von Datenbankaktualisierungen nur auf dem primären Domänencontroller (Primary
Domain Controller oder PDC)
Keine Möglichkeit zur Delegierung der Verwaltung in einer Domäne
Um diese Beschränkungen zu umgehen, umfasst die Bereitstellung von Windows NT in größeren
Organisationen im Allgemeinen mehrere MUDs (Master User Domains) für Konten sowie eine große Anzahl an
Ressourcendomänen. Administratoren in diesen Domänen erstellen Vertrauensstellungen, um Benutzer und
Ressourcen innerhalb der Organisation zu verknüpfen. In Abbildung 8 wird der Aufbau des Windows NT-MUDModells in einer typischen Organisation dargestellt.
.
Abbildung 8: Windows NT-MUD-Modell mit typischen Vertrauensstellungen
Für Windows 2000 Active Directory gelten diese Beschränkungen nicht. Daher können viele in Windows NT
erstellte Domänen in einigen wenigen Active Directory-Domänen konsolidiert werden.
Elemente eines Domänenentwurfs
Der Gesamtstrukturbesitzer ist für die Erstellung eines Domänenentwurfs für die Organisation verantwortlich.
Der Entwurf sollte die folgenden Informationen enthalten:
•
•
•
Name der Stammdomäne der Gesamtstruktur
Liste aller Domänen, einschließlich:
o Name der Domäne
o Umfang der Domäne
o Anzahl der Benutzer in der Domäne
Liste vorhandener Windows NT-Domänen, die für eine Aktualisierung oder Zusammenführung
vorgesehen sind
Rolle des Domänenbesitzers
Der Domänenbesitzer ist für die Verwaltung des Verzeichnisdienstes auf Domänenebene verantwortlich. Er
steuert die Domäne über die Sicherheitsgruppe Domänen-Admins und andere integrierte Sicherheitsgruppen. In
Tabelle 7 werden die Verantwortungsbereiche und zugewiesenen Aufgaben des Domänenbesitzers
zusammengefasst.
Tabelle 7: Rollen und Verantwortungsbereiche des Domänenbesitzers
Verantwortungsbereich
Verwalten von Operationen des Domänencontrollers
Konfigurieren domänenweiter Einstellungen
Delegieren von Verwaltungsaufgaben auf Datenebene
Verwalten externer Vertrauensstellungen
Zugewiesene Aufgaben
• Einrichten und Entfernen von Domänencontrollern
• Überwachen des Zustands von Domänencontrollern
• Verwalten der auf den Domänencontrollern
ausgeführten Dienste
• Sicherung und Wiederherstellung
• Erstellen von Richtlinien für Domänen und
Domänenbenutzerkonten, z. B. Kerberos und die
Kontosperre
• Erstellen von Organisationseinheiten (OEs) und
Delegieren von Verwaltungsaufgaben
• Beheben von Problemen in der OE-Struktur, für die
OE-Besitzer nicht über ausreichende Zugriffsrechte
verfügen
• Erstellen von Vertrauensstellungen mit Domänen
außerhalb der Gesamtstruktur
Vorsicht! Da Domänenbesitzer eine äußerst vertrauenswürdige Position innehaben, sollten diese Personen
sorgfältig ausgewählt werden. Umgekehrt sollten Domänenbesitzer die Mitgliedschaft in allen vordefinierten
und bekannten administrativen Benutzerrollen und Gruppen streng überwachen.
Optimale Vorgehensweise für den Domänenentwurf
Die optimalen Vorgehensweisen für den Domänenentwurf sind von der Anzahl der Benutzer in der
Gesamtstruktur und der Bandbreite, die im Netzwerk für die Domänencontrollerreplikation zur Verfügung steht,
abhängig. Ein auf optimalen Vorgehensweisen basierender Domänenentwurf enthält die folgenden Elemente:
•
•
•
Eine dedizierte Stammdomäne, die vom Besitzer der Gesamtstruktur verwaltet wird.
Eine einzige Domäne bzw. mehrere regionsbasierte Domänen, die der Stammdomäne untergeordnet
sind und von Domänenbesitzern verwaltet werden, die der Gesamtstrukturbesitzer benannt hat.
Alle Domänen befinden sich im einheitlichen Modus.
Anmerkung Wird eine Domäne "direkt" von Windows NT auf Windows 2000 aktualisiert, wird auf einigen
Domänencontrollern noch Windows NT ausgeführt. Um den Einsatz von Windows 2000- und Windows NTDomänencontrollern in demselben Windows-Netzwerk zu ermöglichen, kann Active Directory im gemischten
Modus ausgeführt werden. Im gemischten Modus sind bestimmte Funktionen von Active Directory deaktiviert,
um die Interoperabilität mit Windows NT-Sicherungsdomänencontrollern (Backup Domain Controllers oder
BDCs) zu gewährleisten. Nachdem alle BDCs aus der Domäne entfernt wurden, kann die Domäne in den
einheitlichen Modus wechseln, so dass die folgenden Windows 2000-Funktionen aktiviert werden:
•
•
•
•
Universelle Gruppen
Gruppenschachtelung
Lokale Gruppen der Domäne
SID-Verlauf
Von diesen Funktionen sind die lokalen Gruppen der Domäne und der SID-Verlauf erforderlich, um Benutzerund Computermigrationen von Windows NT-Domänen zu unterstützen.
Um den größtmöglichen Nutzen aus Active Directory zu ziehen, sollten Sie die Anzahl der Domänen in der
endgültigen Gesamtstruktur möglichst gering halten. Für die meisten Organisationen enthält der ideale Entwurf
eine Gesamtstruktur mit einer Stammdomäne und einer globalen Domäne.
Die Komponenten eines auf optimalen Vorgehensweisen basierenden Domänenentwurfs werden im folgenden
Abschnitt beschrieben.
Dedizierte Stammdomäne für die Gesamtstruktur
Der ersten Domäne, die in einer Gesamtstruktur erstellt wird, wird automatisch die Rolle der Stammdomäne
zugewiesen. Alle anderen Domänen bauen auf der Stammdomäne der Gesamtstruktur auf und definieren die
Verzeichnishierarchie. Die Stammdomäne der Gesamtstruktur enthält zwei spezielle administrative Gruppen,
deren Aufgabe in der Unterstützung der Active Directory-Infrastruktur besteht: Organisations-Admins und
Schema-Admins.
Der auf optimalen Vorgehensweisen basierende Ansatz für den Domänenentwurf sieht vor, dass die
Stammdomäne der Gesamtstruktur ausschließlich zur Verwaltung der Infrastruktur der Gesamtstruktur
verwendet wird. In Tabelle 8 wird erklärt, warum eine dedizierte Stammdomäne für die Gesamtstruktur
empfehlenswert ist.
Tabelle 8: Gründe für die Berücksichtigung einer dedizierten Stammdomäne in Ihrem
Gesamtstrukturentwurf
Grund
Weniger Administratoren, die gesamtstrukturweite
Änderungen vornehmen können
Vereinfachte Replikation zur Sicherung der
Gesamtstruktur
Wird nicht überflüssig
Einfache Übertragung von Besitz
Erklärung
Durch Beschränkung der Mitgliedschaft der
administrativen Gruppe in der Stammdomäne der
Gesamtstruktur wird die Wahrscheinlichkeit eines
Verwaltungsfehlers, der sich auf die Gesamtstruktur
insgesamt auswirkt, reduziert.
Eine kleine Stammdomäne kann problemlos überall im
Netzwerk repliziert werden und bietet so Schutz vor
regional begrenzten Zwischenfällen.
Sie brauchen die Stammdomäne nicht zu entfernen,
selbst wenn sich Ihre Organisation ändert. Eine
dedizierte Stammdomäne wird nie überflüssig, da sie
ausschließlich als Gesamtstrukturstamm dient.
Bei der Übertragung des Besitzes der Stammdomäne
auf den Gesamtstrukturbesitz müssen Produktionsdaten
oder Ressourcen nicht migriert werden.
Die Funktion der Stammdomäne der Gesamtstruktur besteht im Definieren und Verwalten der Infrastruktur. Die
Verwaltung der Verzeichnisinfrastruktur erfordert neue administrative Rollen und Verantwortungsbereiche. Die
dedizierte Stammdomäne sollte für die Verwaltung der Gesamtstruktur reserviert werden. Die Stammdomäne der
Gesamtstruktur sollte keine Benutzer oder Ressourcen enthalten, die nicht an der Verwaltung der Gesamtstruktur
beteiligt sind.
Einzige globale untergeordnete Domäne
Ist der Stammdomäne der Gesamtstruktur eine einzige globale Domäne untergeordnet, enthält diese alle
Benutzer-, Computer- und Gruppenkonten mit Ausnahme der Konten von Verzeichnisadministratoren, die sich
in der Stammdomäne der Gesamtstruktur befinden. Abbildung 9 zeigt eine Gesamtstruktur mit einer einzigen
globalen untergeordneten Domäne.
Abbildung 9: Gesamtstruktur mit einer Stammdomäne und einer einzigen globalen untergeordneten
Domäne
Regionsbasierte Domänen
Alle zu einer Domäne gehörenden Objektdaten werden vollständig auf sämtliche Domänencontroller innerhalb
der Domäne repliziert. Aus diesem Grund müssen für Gesamtstrukturen mit einer großen Anzahl weit
voneinander entfernter Benutzer und langsamen WAN-Verbindungen (Wide Area Network) u. U. mehrere
regionsbasierte untergeordnete Domänen eingerichtet werden. Wenn Ihre Organisation einen Entwurf mit einer
einzigen globalen untergeordneten Domäne nicht unterstützen kann, stellen regionsbasierte Domänen die beste
Lösung dar, da sie folgende Vorteile bieten:
•
•
•
Problemlose Zuordnung zu WAN-Konnektivität im Netzwerk
Problemlose Zuordnung zu globalen IT-Verwaltungsgruppen in einer typischen Organisation
Basieren auf einer stabilen Struktur
Anmerkung In einigen Organisationen haben sich Abteilungen als autonome Einheiten entwickelt, die eine
eigene IT-Infrastruktur bereitstellen und ihre Dienste nicht mit anderen Abteilungen koordinieren.
Ein Gesamtstrukturbesitzer, der in letzter Instanz für die Bereitstellung von Diensten in der Gesamtstruktur
verantwortlich ist, ist im Allgemeinen nicht bereit, die Verantwortung für Verzeichnisdienste an einen ITAdministrator aus einer eigenständigen Abteilung zu delegieren. Darüber hinaus ist es aufgrund von
Sicherheitsüberlegungen erforderlich, dass zwischen allen Domänenbesitzern in einer gemeinsamen
Gesamtstruktur ein Vertrauensverhältnis besteht. Dagegen erwartet der IT-Administrator einer eigenständigen
Abteilung wahrscheinlich ein gewisses Maß an Autonomie für eine unabhängige Domäne. Diese Autonomie
kann jedoch nur durch Erstellung einer separaten Gesamtstruktur erreicht werden. Aus diesen Gründen ist die
Erstellung von Domänen anhand organisatorischer Kriterien nicht empfehlenswert.
Abbildung 10 zeigt eine Gesamtstruktur mit regionsbasierten untergeordneten Domänen.
Abbildung 10: Gesamtstruktur mit einem dedizierten Gesamtstrukturstamm und drei untergeordneten
Domänen
Entwurfsprozess für Domänen
Während der Domänenentwurfsphase bewerten Sie die bestehende IT-Umgebung und den aktuellen
Verwaltungsentwurf, um zu ermitteln, wie die vorhandenen Windows NT-Domänen in möglichst wenigen
Active Directory-Domänen zusammengefasst werden können. Die folgenden Informationen müssen angegeben
werden:
1.
2.
3.
4.
Die Anzahl der Active Directory-Domänen in dem Entwurf
Der Umfang jeder neuen Active Directory-Domäne
Ein Name für jede Domäne
Ob eine Active Directory-Domäne neu erstellt oder von Windows NT aktualisiert wurde
Der Domänenentwurfsprozess, welcher Sie beim Erstellen eines auf optimalen Vorgehensweisen basierenden
Domänenmodells unterstützen soll, umfasst die folgenden Schritte:
1.
2.
3.
4.
5.
Entwerfen der dedizierten Stammdomäne der Gesamtstruktur
Auswählen eines einzigen globalen oder eines regionalen Domänenmodells
Unterteilen der globalen Organisation in regionale Domänen, falls eine einzige globale Domäne nicht
praktikabel ist
Angeben, ob eine vorhandene Windows NT-Domäne aktualisiert oder eine neue Domäne erstellt
werden soll (für jede Domäne)
Zuordnen aller übrigen Domänen zu einer der regionalen Domänen zwecks Konsolidierung
Abbildung 11 stellt die Aufgaben dar, die bei der Erstellung eines Domänenentwurfs durchgeführt werden
müssen.
Abbildung 11: Während des Domänenentwurfsprozesses durchgeführte Aufgaben
Entwerfen der Stammdomäne der Gesamtstruktur
Beim Entwerfen der Stammdomäne der Gesamtstruktur müssen Sie dieser einen Domänennamen zuweisen.
Active Directory-Domänen weisen zwei Arten von Namen auf:
•
•
DNS-Namen (Domain Name System), die von Windows 2000-Clients verwendet werden
NetBIOS-Namen, die von Clients mit früheren Windows-Versionen verwendet werden
Der Name der Stammdomäne der Gesamtstruktur ist gleichzeitig der Name der Gesamtstruktur. So benennen Sie
die Stammdomäne der Gesamtstruktur:
1.
Identifizieren Sie den DNS-Besitzer in Ihrer Organisation und ermitteln Sie, welche DNS-Namen in
dem Netzwerk, das Active Directory enthalten soll, zur Verfügung stehen.
Beachten Sie, dass die in diesem Netzwerk verfügbaren Namen u. U. nicht mit den Namen
übereinstimmen, die Ihre Organisation im Internet verwendet. Beispielsweise kann der Name Ihrer
Organisation im Internet contosopharma.com lauten, während im internen Unternehmensnetzwerk
contoso.com verwendet wird. Wählen Sie in diesem Fall den Namen contoso.com.
Falls Sie nicht über einen registrierten Domänennamen verfügen, sollten Sie bei einer DNSRegistrierungsstelle im Internet einen Namen registrieren.
Anmerkung Optimale Vorgehensweise ist die Verwendung von DNS-Namen, die bei einer InternetRegistrierungsstelle im Active Directory-Namespace registriert wurden. Nur für registrierte Namen
kann gewährleistet werden, dass sie global eindeutig sind. Falls eine andere Organisation später
denselben DNS-Domänennamen registriert, Ihre Organisation mit einem anderen Unternehmen
fusioniert, ein Unternehmen übernimmt oder von einem Unternehmen übernommen wird, das dieselben
DNS-Namen verwendet, ist keine Interaktion zwischen den beiden Infrastrukturen möglich.
Fügen Sie dem registrierten DNS-Namen ein Präfix hinzu, das gegenwärtig nicht verwendet wird, um
einen neuen untergeordneten Namen zu erstellen. Lautet der Name des DNS-Stammes contoso.com,
können Sie der Stammdomäne in der Gesamtstruktur z. B. den Active Directory-Namen
concorp.contoso.com zuweisen, sofern der Namespace concorp.contoso.com im Netzwerk noch nicht
verwendet wird. Dieser neue Zweig des Namespaces wird für Active Directory und Windows 2000
bereitgestellt und kann problemlos mit der bestehenden DNS-Implementierung integriert werden. Die
bei der Auswahl eines Präfixes zu beachtenden Regeln werden in Tabelle 9 aufgelistet.
Tabelle 9: Regeln bei der Erstellung eines Präfixes für einen Active Directory-Namen
Präfixregel
Keine Namen, die veralten
Nur Internet-Standardzeichen
Maximal 15 Zeichen
2.
Erklärung
Domänen können nicht umbenannt werden,
weshalb Sie z. B. keine Namen von Produktlinien
oder Betriebssystemen verwenden sollten, die
überflüssig werden können. Geeignet sind z. B.
geographische Namen.
A-Z, a-z, 0-9 und (-), aber keine rein numerischen
Namen
Wenn Sie ein Präfix mit einer Länge von maximal
15 Zeichen wählen, stimmt der von kompatiblen
Clients verwendete NetBIOS-Name mit dem Präfix
überein.
Veranlassen Sie den DNS-Besitzer, den Besitz des Namens an Sie zu delegieren.
In den Abschnitten zum DNS-Entwurf in diesem Dokument werden DNS-Namen und die Planung der
DNS-Bereitstellung näher erläutert.
Auswählen eines einzigen globalen oder eines regionalen Domänenmodells
Ermitteln Sie, ob Ihr Entwurf ein Modell mit einer einzigen globalen Domäne oder ein Modell mit mehreren
regionsbasierten Domänen enthalten soll. Aus den folgenden Gründen ist ein einziges globales Domänenmodell
vorzuziehen:
•
•
•
Benutzer müssen nicht zwischen Domänen verschoben werden.
Doppelte Gruppenrichtlinieneinstellungen, die mehrere Domänen umfassen, sind nicht erforderlich.
Jeder Domänencontroller kann alle Benutzer authentifizieren.
In einigen größeren Organisationen ist die langsamste Netzwerkverbindung zu einem Domänencontroller
möglicherweise nicht in der Lage, den Replikationsverkehr einer einzigen globalen Domäne zu bewältigen.
Wählen Sie in diesem Fall das regionale Domänenmodell. Tabelle 10 enthält die maximalen Benutzerzahlen für
eine einzige globale Domäne. Bedenken Sie auch das zukünftige Wachstum Ihrer Organisation, wenn Sie diesen
Richtlinien folgen.
Tabelle 10: Größenrichtlinien bei der Replikation für eine einzige globale Domäne
Langsamste Verbindung zu einem
Domänencontroller (Kbit/s)
9,6
14,4
19,2
28,8
38,4
56,0 (oder höher)
Maximale Benutzerzahl für eine einzige globale
Domäne
20.000
30.000
40.000
50.000
75.000
100.000
Anmerkung Diese Schätzwerte gelten für Gesamtstrukturen mit bis zu 100.000 Benutzern. Umfangreichere
Gesamtstrukturen sind möglich, werden in diesen auf optimalen Vorgehensweisen basierenden Richtlinien
jedoch nicht behandelt. Die Werte stellen konservative Schätzungen dar. Sie basieren auf folgenden Annahmen:
•
•
•
•
•
•
•
•
10 % der minimalen Bandbreite stehen für die Replikation zur Verfügung.
Alle Domänencontroller sind globale Kataloge.
Die Rate neu hinzukommender Benutzer ist 20 % pro Jahr.
Die Rate wegfallender Benutzer ist 15 % pro Jahr.
Änderungen der Gruppenmitgliedschaft sind ein dominanter Faktor bei der Replikationsnutzlast.
Das Verhältnis von Benutzern und Computern ist 1:1.
Es wird in den Verzeichnisdienst integriertes DNS verwendet.
Es werden DNS-Aufräumvorgänge durchgeführt.
Diese Liste enthält lediglich Annäherungswerte. Bevor Sie Ihren Domänenplan implementieren, sollten Sie
Labortests durchführen, um sicherzustellen, dass das Netzwerk den Replikationsverkehr bewältigen kann.
Zusätzliche Informationen über Domänengrößen finden Sie in Building Enterprise Active Directory Services:
Notes From the Field (englischsprachig) von Microsoft Consulting Services, 2000, Redmond: Microsoft Press.
Falls Sie mehrere Windows NT-Domänen bereitgestellt haben, sollten Sie eine Migration dieser Domänen in die
neue globale Active Directory-Domäne durchführen. Wenn Sie die Windows NT-MUDs jedoch in maximal
zehn regionsbasierten Domänen konsolidiert haben, empfiehlt es sich u. U., diese Domänen direkt zu
aktualisieren, anstatt die Benutzer in eine einzige globale Domäne zu migrieren. Das Verschieben von Konten
zwischen Domänen kann sich auf Endbenutzer auswirken. Bevor Sie eine Entscheidung treffen, sollten Sie die
langfristigen administrativen Vorteile einer einzigen globalen Domäne und die Kosten einer Migration dieser
Benutzer gegeneinander abwägen. Dieser Aspekt wird im nächsten Abschnitt, "Aufteilen der globalen
Organisation in regionale Domänen" beschrieben.
Aufteilen der globalen Organisation in regionale Domänen
Falls Größenbeschränkungen erfordern, dass Sie regionale Domänen für die Gesamtstruktur erstellen, führen Sie
die folgenden Schritte aus:
1.
Unterteilen Sie die Organisation in Regionen, und berücksichtigen Sie dabei regionale Merkmale, die
etwas über die Organisation aussagen, z. B. die Folgenden:
o Kontinent
o Netzwerkverbindung
o Verwaltungsregion
Für jede Region wird eine Active Directory-Domäne erstellt. Ihr Ziel besteht darin, die Anzahl der zu
erstellenden Domänen zu minimieren. Empfohlen werden maximal zehn Domänen. Falls Sie überlegen,
Ihrem Gesamtstrukturentwurf weitere Domänen hinzuzufügen, sollten Sie bedenken, dass bei einer
Erhöhung der Domänenzahl die Optimierung der Replikationsbandbreite mit höherem
Verwaltungsaufwand erkauft wird. In Tabelle 11 wird dieser Aufwand detaillierter beschrieben.
Tabelle 11: Mit dem Hinzufügen zusätzlicher Domänen zu einer Gesamtstruktur verbundener
Verwaltungsaufwand
Aufwand
Verwaltung mehrerer Gruppen von DomänenAdmins
Implikationen
Da Domänenadministratoren über Vollzugriff für
eine Domäne verfügen, muss die Mitgliedschaft in
der Gruppe der Domänenadministratoren für eine
Domäne sorgfältig überwacht werden. Jede
zusätzliche Domäne in einer Gesamtstruktur
erfordert diesen Verwaltungsaufwand.
Zusätzliche Domänencontrollerhardware
Ein Domänencontroller kann nur in einer Domäne
als Host eingesetzt werden. Für jede neue Domäne,
die Sie erstellen, sind mindestens zwei Computer
erforderlich, um die Anforderungen im Hinblick
auf Zuverlässigkeit und Verfügbarkeit zu erfüllen.
Da alle Domänencontroller Änderungen sowohl
übernehmen als auch veranlassen können, müssen
sie physisch überwacht werden.
Vertrauensstellungen
Damit ein Benutzer in einer Domäne auf eine
Ressource in einer anderen Domäne zugreifen
kann, muss mit Domänencontrollern in beiden
Domänen Kontakt aufgenommen werden. Diese
Kommunikation stellt eine weitere mögliche
Fehlerquelle dar. Je weniger Domänen vorhanden
sind, desto weniger müssen Benutzer sich auf
Kommunikationen mit mehreren
Domänencontrollern verlassen, um den Dienst
aufrechtzuerhalten.
Verwaltung der Gruppenrichtlinien und der
Werden Gruppenrichtlinien und die
Zugriffssteuerung, die für mehrere Domänen gelten Zugriffssteuerung in einer Domäne angewendet,
werden diese nicht automatisch von anderen
Domänen übernommen. Wenn
Gruppenrichtlinieneinstellungen oder die
Delegierung der Verwaltung durch
Zugriffssteuerung in mehreren Domänen gelten
sollen, müssen diese für jede Domäne einzeln
eingerichtet werden.
Höhere Wahrscheinlichkeit, dass Objekte zwischen Da die Umstrukturierung innerhalb einer Domäne
Domänen verschoben werden müssen
äußerst einfach ist, sollte Ihr Domänenentwurf eine
möglichst geringe Anzahl an großen stabilen
Domänen enthalten. Wenn Sie dem Entwurf
weitere Domänen hinzufügen, steigt die
Wahrscheinlichkeit, dass ein Objekt, z. B. ein
Benutzer oder eine Objektgruppe, von einer
Domäne in eine andere verschoben werden muss.
Das Verschieben eines Benutzers innerhalb einer
Domäne ist einfach. Das Verschieben eines
Benutzers zwischen Domänen kann sich dagegen
auf Benutzer auswirken.
2.
Ermitteln Sie anhand von Tabelle 12, ob jede Region den Größenrichtlinien entspricht, und führen Sie
dann die folgenden Schritte durch:
1. Ermitteln Sie die langsamste Verbindung zu Domänencontrollern, einschließlich
Verbindungen, die diese Region mit anderen Regionen verbinden.
2. Suchen Sie nach der Zeile in der Tabelle, die der langsamsten Verbindung entspricht
(abgerundet).
3. Übersteigt die Anzahl der Benutzer in der Region die Richtlinien, unterteilen Sie die Region in
kleinere Regionen.
Bedenken Sie auch das zukünftige Wachstum Ihrer Organisation, wenn Sie diesen Richtlinien folgen.
Tabelle 12: Größenrichtlinien bei der Replizierung für regionale Domänen
Minimale Bandbreite (Kbit/s)
9,6
14,4
19,2
28,8
38,4
56,0 (oder höher)
Maximale Benutzerzahl für die
Gesamtstruktur
25.000
50.000
50.000
75.000
100.000
100.000
Maximale Benutzerzahl für eine
regionale Domäne
15.000
15.000
25.000
40.000
45.000
100.000
Anmerkung Diese Schätzwerte gelten für Gesamtstrukturen mit bis zu 100.000 Benutzern.
Umfangreichere Gesamtstrukturen sind möglich, werden in diesen auf optimalen Vorgehensweisen
basierenden Richtlinien jedoch nicht behandelt. Die Werte stellen konservative Schätzungen dar. Sie
basieren auf folgenden Annahmen:
o
o
o
o
o
o
o
o
10 % der minimalen Bandbreite stehen für die Replikation zur Verfügung.
Alle Domänencontroller sind globale Kataloge.
Die Rate neu hinzukommender Benutzer ist 20 % pro Jahr.
Die Rate wegfallender Benutzer ist 15 % pro Jahr.
Änderungen der Gruppenmitgliedschaft sind ein dominanter Faktor bei der
Replikationsnutzlast.
Das Verhältnis von Benutzern und Computern ist 1:1.
Es wird in den Verzeichnisdienst integriertes DNS verwendet.
Es werden DNS-Aufräumvorgänge durchgeführt.
Diese Tabelle enthält lediglich Annäherungswerte. Bevor Sie Ihren Domänenplan
implementieren, sollten Sie Labortests durchführen, um sicherzustellen, dass das Netzwerk den
Replikationsverkehr bewältigen kann. Zusätzliche Informationen über Domänengrößen finden
Sie in Building Enterprise Active Directory Services: Notes From the Field (englischsprachig)
von Microsoft Consulting Services, 2000, Redmond: Microsoft Press.
3.
Enthält eine Domäne über 50.000 Benutzer, sollten Sie einen dedizierten PDC angeben.
Der dedizierte PDC sollte so konfiguriert werden, dass er nur PDC-Operationen durchführt. In Best
Practices Active Directory Deployment for Managing Windows Networks (englischsprachig) wird die
Konfiguration eines dedizierten PDC genauer beschrieben.
Abbildung 12 zeigt einen regionalen Domänenentwurf. In diesem Beispiel enthält die Gesamtstruktur insgesamt
60.000 Benutzer. Bei einer minimalen Bandbreite von 32 Kbit/s werden in diesen Richtlinien maximal 50.000
Benutzer pro Domäne empfohlen. Die Organisation plant, einen Entwurf mit drei Domänen zu implementieren,
die den regionalen Abteilungen entsprechen. Bei diesem Entwurf würden Domänen mit 40.000, 15.000 und
5.000 Benutzern entstehen, die alle den Richtlinien für die Domänenreplikation entsprechen.
Abbildung 12: Die regionale Zuordnung von Benutzern und Computern einer Organisation
Angeben einer neuen oder aktualisierten Domäne für jede Region
Jede Region, die Sie einrichten, stellt eine Active Directory-Domäne dar. Diese Domänen können durch
Erstellen einer neuen leeren Domäne entstehen, in die Benutzer und Computer migriert werden, oder durch
Aktualisieren einer bestehenden Windows NT-Domäne. Im Falle eines Windows NT-Updates sind
wahrscheinlich mehrere MUDs (Master User Domains) bereits vorhanden.
Führen Sie die folgenden Schritte durch, um eine neue oder aktualisierte Domäne für jede Region anzugeben:
1.
Bei der Migration von Windows NT sollten Sie jede MUD in der Region bewerten, um zu ermitteln, ob
einige dieser MUDs als Updatekandidaten für die regionale Domäne infrage kommen.
Weitere Informationen zu diesem Thema finden Sie im folgenden Abschnitt, "Bewerten bereits
vorhandener MUDs (Master User Domains) in einer Region".
2.
Falls Sie nicht von Windows NT, sondern von einem anderen Betriebssystem aktualisieren oder kein
Windows NT-MUD als Updatekandidat infrage kommt, erstellen Sie eine neue Domäne für die Region.
Weitere Informationen zu diesem Thema finden Sie im Abschnitt "Entwerfen neuer regionaler
Domänen" weiter unten in diesem Teil des Handbuches.
Bewerten bereits vorhandener MUDs (Master User Domains) in einer Region
Wichtig Dieser Abschnitt wurde für Organisationen geschrieben, die Migrationen von Windows NT
durchführen. Wird in Ihrer Organisation ein anderes Betriebssystem verwendet, können Sie diesen Abschnitt
überspringen.
Wenn Ihre Organisation eine Migration von Windows NT durchführt, befinden sich Benutzer und Ressourcen
derzeit in Windows NT-Domänen. In dieser Entwurfsphase entscheidet der Gesamtstrukturbesitzer, wie diese
Windows NT-Domänen am besten migriert und in dem endgültigen Active Directory-Entwurf konsolidiert
werden können.
Erstellen Sie als Erstes eine Liste der MUDs in dieser Region, die der Gesamtstruktur beitreten sollen. Füllen Sie
für jede dieser MUDs ein MUD-Tabellenblatt aus. Für jede MUD müssen Sie folgende Entscheidungen treffen:
•
•
Sie können ein direktes Update durchführen, bei dem alle Domänencontroller der MUD auf
Windows 2000 Active Directory aktualisiert werden.
Oder Sie können die MUD entfernen und die Benutzerkonten in eine neue oder aktualisierte Domäne
migrieren.
Mithilfe von Tabelle 13 können Sie ermitteln, ob eine MUD aktualisiert oder ihr Inhalt migriert werden soll.
Tabelle 13: Vor- und Nachteile des direken Updates einer MUD
Vorteile der Erstellung einer neuen Domäne und
Migration
• Die aktuelle Domäne entspricht dem regionalen Modell. • Die Domäne ist regionenübergreifend und ihr
• Nimmt weniger Zeit in Anspruch als das Migrieren von Inhalt muss auf andere regionale Domänen verteilt
werden.
Benutzern in eine neue Domäne.
• Der Wechsel der Domäne in den einheitlichen
Modus (Upgrade aller Domänencontroller) würde zu
lange dauern.
Vorteile des direkten Updates
Wichtig Bedenken Sie, dass eine als regionale Domäne aktualisierte Windows NT-Domäne nur dann als
Zieldomäne für die Domänenkonsolidierung eingesetzt werden kann, wenn sie sich im einheitlichen Modus
befindet. Wenn sich zahlreiche BDCs an Remotestandorten befinden oder Hardwareupgrades erforderlich sind,
kann der Wechsel in den einheitlichen Modus von Active Directory mehr Zeit in Anspruch nehmen als erwartet.
In diesem Fall empfiehlt es sich möglicherweise, eine andere Windows NT-Domäne zu aktualisieren oder eine
neue Domäne als Konsolidierungsziel zu erstellen.
Im Idealfall sollte eine MUD aus jeder Region auf Windows 2000 aktualisiert werden. Es ist möglich, dass eine
Region keinen oder aber mehrere Updatekandidaten enthält. Falls kein geeigneter Updatekandidat zur Verfügung
steht, können Sie eine neue Domäne erstellen. Dies wird im nächsten Abschnitt eingehender behandelt.
Wenn Sie mehrere MUD-Updatekandidaten ermittelt haben, haben Sie folgende Möglichkeiten:
•
•
Update der größten MUD und Konsolidierung der übrigen MUDs in diese Domäne
Definieren zusätzlicher Regionen und direktes Update jeder MUD
Falls Sie sich entscheiden, weitere Regionen zu definieren, sollten Sie bedenken, dass beim Hinzufügen
von Domänen zur Gesamtstruktur zusätzlicher Verwaltungsaufwand entsteht.
Für jede Domäne, für die der Gesamtstrukturbesitzer im Rahmen des Active Directory-Entwurfs ein direktes
Update durchführen will, müssen Sie die folgenden Schritte durchführen:
1.
Weisen Sie der Domäne einen DNS-Namen zu.
Wählen Sie als Domänennamen <Domänenpräfix>.<Gesamtstrukturname>. Standardmäßig verwendet
Windows 2000 den aktuellen NetBIOS-Namen als Domänenpräfix. Sie können das Domänenpräfix
während des Updates ändern, aber es wird empfohlen, den Standardnamen beizubehalten. Auf diese
Weise wird sichergestellt, dass in Windows 2000 oder in früheren Tools derselbe Name angezeigt wird.
2.
3.
Weisen Sie einem Mitarbeiter die Rolle des Domänenbesitzers in der neuen Domäne zu.
Stellen Sie sicher, dass der aktuelle Domänenbesitzer mit dem Plan einverstanden ist.
Entwerfen neuer regionaler Domänen
In den folgenden Situationen muss der Gesamtstrukturbesitzer im Rahmen des Domänenentwurfs neue Domänen
erstellen:
•
•
In der Organisation sind derzeit keine Windows NT-Domänen vorhanden.
Keine der vorhandenen Domänen eignet sich für ein Update.
Nachdem neue regionale Domänen eingerichtet wurden, können Sie Konten und Ressourcen auf diese Domänen
verteilen.
Für jede neue Domäne, die der Gesamtstrukturbesitzer dem Windows 2000-Entwurf hinzufügt, müssen Sie die
folgenden Schritte durchführen:
1.
Weisen Sie der Domäne einen DNS-Namen zu.
Verwenden Sie als Domänennamen <Neuer Name>.<Gesamtstrukturname>. Die Regeln für die
Erstellung eines Namenspräfixes sind in Tabelle 9 dargestellt.
2.
Weisen Sie einem Mitarbeiter die Rolle des Domänenbesitzers der neuen Domäne zu.
Beispiel für das Angeben neuer oder aktualisierter Domänen
In Abbildung 13 sieht der Domänenentwurf das direkte Update einer MUD aus den Regionen Nordamerika und
Südamerika auf eine regionale Windows 2000-Domäne vor. In Europa enthalten beide MUDs zahlreiche
Domänencontroller an Remotestandorten. Der Gesamtstrukturbesitzer hat ermittelt, dass ein direktes Update in
beiden Fällen zu lange dauern würde, um den einheitlichen Modus herzustellen. Daher wurde im
Domänenentwurf eine neue Domäne angegeben. Die drei übrigen MUDs werden in der regionalen Domäne in
diesen Bereichen konsolidiert.
Abbildung 13: Erstellen von Active Directory-Domänen durch Update von Windows NT-MUDS (Dreieck
mit Kreis) oder durch Einrichten einer neuen Domäne (nur Dreieck)
Konsolidieren der übrigen Windows NT-Kontendomänen
Alle übrigen MUDs sollten mit den entsprechenden regionalen Domänen konsolidiert werden. Beachten Sie bei
der Konsolidierung einer MUD mit einer anderen Domäne Folgendes:
•
Sie können Organisationseinheiten (OEs) konfigurieren, um die Struktur und die Verwaltung der
ursprünglichen Domäne beizubehalten.
Der OE-Entwurf wird weiter unten in diesem Handbuch beschrieben.
•
Der Konsolidierungsprozess hat eine einmalige Auswirkung auf die Benutzer, die migriert werden.
Der Prozess der Benutzermigration wird im Begleithandbuch Best Practice Active Directory
Deployment for Managing Windows Networks (englischsprachig) ausführlich beschrieben.
Anmerkung Wenn der Inhalt einer Windows NT-Domäne auf mehrere regionale Domänen aufgeteilt werden
soll, empfiehlt es sich, den Inhalt in andere Zieldomänen zu migrieren und kein direktes Update dieser Domäne
durchzuführen.
Ordnen Sie alle übrigen MUDs regionalen Domänen zu. Abbildung 14 stellt dar, wie alle übrigen Windows NTMUDs in die regionalen Active Directory-Domänen für concorp.contoso.com konsolidiert werden.
Abbildung 14: Konsolidieren von Windows NT-MUDs in Active Directory-Domänen
Konsolidieren von Windows NT-Ressourcendomänen
Es wird empfohlen, die Konsolidierung aller Windows NT-Ressourcendomänen in die Active Directory-Domäne
der entsprechenden Region zu planen.
Die Entscheidung, in welche Domäne der Inhalt der Ressourcendomäne verschoben werden soll, ist meist
einfach. Da Benutzer ihre Daten in unmittelbarer Nähe bevorzugen, sind die meisten Ressourcendomänen
geographisch organisiert und Benutzern an verschiedenen Standorten zugeordnet. Das bedeutet, dass die meisten
Ressourcendomänen problemlos in die Active Directory-Domäne konsolidiert werden können, die die
Benutzerkonten dieses Standortes enthält. Ist der Inhalt der Windows NT-Ressourcendomäne
regionsübergreifend, müssen Sie angeben, in welche Zieldomänen die Ressourcen migriert werden sollen.
Beachten Sie, dass Sie bei der Konsolidierung dieser MUD in eine Windows 2000-Zieldomäne
Organisationseinheiten konfigurieren können, um die ursprüngliche Domänenstruktur und -verwaltung
beizubehalten.
In anderen Fällen kann die Domäne als Windows NT-Ressourcendomäne erhalten bleiben, bis sie zu einem
späteren Zeitpunkt konsolidiert wird oder schließlich überflüssig wird und entfernt werden kann. Dies kann der
Fall sein, wenn Anwendungen auf Domänencontrollern in der Domäne ausgeführt werden, deren Ausführung
unter Windows 2000 nicht möglich ist.
Anmerkung Falls Sie über eine dedizierte Ressourcendomäne für die Bereitstellung von Exchange 5.5
verfügen, sollten Sie in dieser Domäne Windows NT zunächst beibehalten. Informationen zur Planung einer
Exchange-Migration finden Sie in Microsoft Exchange 2000 Server Upgrade Series, online verfügbar unter
http://www.microsoft.com/technet/treeview/default.asp?url=/technet/itsolutions/guide/default.asp
(englischsprachig).
Abbildung 15 zeigt, wie ein Gesamtstrukturbesitzer vorhandene Ressourcendomänen in Active DirectoryDomänen derselben Region konsolidieren kann.
Abbildung 15: Konsolidieren von Windows NT-Ressourcendomänen in Windows 2000-Domänen
In diesem Szenario sind alle Ressourcendomänen regional organisiert. Dies erleichtert die Entscheidung, wo in
der regionalen Domänenhierarchie jede Ressourcendomäne konsolidiert werden soll.
Abbildung 16 zeigt die endgültige Active Directory-Gesamtstruktur für concorp.contoso.com. Der endgültige
Entwurf besteht aus einer Gesamtstruktur mit einer Stammdomäne und drei regionalen Domänen.
Abbildung 16: Endgültiger Active Directory-Domänenentwurf für "concorp.contoso.com"
Weitere Schritte
Während des Domänenentwurfsprozesses gibt jeder Gesamtstrukturbesitzer den Namen für die Stammdomäne
der Gesamtstruktur sowie die logische Struktur für Active Directory an. Da Active Directory für die
Namensauflösung DNS verwendet, besteht der nächste Schritt des Gesamtstrukturbesitzers darin, einen DNSBesitzer für Active Directory zu benennen und den DNS-Entwurf zu bestimmen.
Wurde in der Organisation bereits ein DNS-Dienst implementiert, arbeiten der Gesamtstrukturbesitzer und der
DNS-Besitzer für Active Directory mit dem aktuellen DNS-Besitzer zusammen, um den DNS-Namen der
Stammdomäne der Gesamtstruktur an Active Directory zu delegieren. Wurde noch kein DNS-Dienst
implementiert, müssen der Gesamtstrukturbesitzer und der DNS-Besitzer für Active Directory die
Implementierung planen.
Im nächsten Abschnitt wird dieser Prozess im Detail erläutert.
Erstellen eines DNS-Entwurfs für Active Directory
Für den Gesamtstrukturbesitzer und die Windows NT-Administratoren stellt DNS möglicherweise ein neues
Konzept dar. DNS übersetzt Namen in IP-Adressen. Netzwerkgeräte verwenden IP-Adressen, um nach Hosts zu
suchen und Verbindungen zu diesen herzustellen. Benutzer können sich IP-Adressen jedoch nur schwer merken
und ziehen daher Anzeigenamen wie ftp.contoso.com vor. DNS ermöglicht Benutzern die Eingabe
hierarchischer Anzeigenamen, wenn sie Verbindungen zu Computern und anderen Ressourcen im IP-Netzwerk
herstellen.
Unter Windows 2000 stellt DNS einen besser skalierbaren, langfristigen Ersatz für die NetBIOSNamensauflösung dar, die in Windows NT-basierten Netzwerken von WINS (Windows Internet Name Service)
durchgeführt wird. Zur Unterstützung von Clients mit Windows-Versionen vor Windows 2000 muss WINS
jedoch weiterhin ausgeführt werden, da diese Clients DNS nicht zur Domänensuche verwenden können.
In diesem Entwurfsdokument wird erklärt, wie Sie auf der Grundlage von Entscheidungen, die Sie in den
Abschnitten zur Domänenplanung weiter oben in diesem Dokument gemacht haben, einen Entwurf erstellen
können. In diesem Handbuch werden die optimalen Vorgehensweisen beim Entwurf eines DNS-Dienstes für
Active Directory beschrieben, wobei für das Netzwerk Folgendes zutrifft:
•
•
Kein bestehender DNS-Dienst
Bestehender DNS-Dienst
Funktionen von DNS in Windows-Netzwerkentwürfen
Um die Verwendung von DNS durch Windows 2000 und Active Directory verstehen zu können, müssen Sie
wissen, was DNS ist und wie es funktioniert.
DNS ist eine verteilte Datenbank, die alle Informationen enthält, die ein Client benötigt, um nach einem
beliebigen Namen zu suchen. Die Datenbank hat eine hierarchische Struktur, die als umgekehrter Baum
dargestellt wird. Dieser Baum wird auch als Namespace bezeichnet. Das Internet ist eine spezielle Art von
Namespace. Jeder Client im Internetnamespace kann nach jedem beliebigen Namen im Internetnamespace
suchen. Einige Unternehmen verfügen darüber hinaus über einen privaten oder internen Namespace.
DNS wurde so entwickelt, dass jeder DNS-Server Abfragen zu jedem beliebigen Namen in seinem Namespace
beantworten kann. Bei der Beantwortung der Abfragen hat ein DNS-Server drei Möglichkeiten:
•
•
Befindet sich die Antwort in seinem Cache, kann er die Abfrage aus dem Cache beantworten.
Befindet sich die Antwort in einer Zone, deren Host der DNS-Server ist, kann er die Abfrage aus der
Zone beantworten.
Eine Zone ist ein Teil der DNS-Struktur, der alle Datensätze enthält, die zur Beantwortung von
Abfragen für Namen innerhalb einer Zone benötigt werden. Fungiert ein DNS-Server als Host einer
Zone, ist er für diese Zone autorisierend und kann Abfragen zu jedem Namen in der Zone beantworten.
Beispielsweise kann ein Server, der Host der Zone contoso.com ist, Namensabfragen in dieser Zone
beantworten.
•
Kann der Server die Abfrage nicht aus dem Cache oder der Zone beantworten, leitet er sie an andere Server
weiter.
Damit ein DNS-Stammserver Namensabfragen erfolgreich beantworten kann, muss er über einen direkten oder
indirekten Pfad zu jedem Server und jeder Zone im Namespace verfügen. In Abbildung 17 wird dargestellt, wie
der DNS-Stammserver ermittelt, mit welchen Servern im Namespace er Kontakt aufnehmen soll.
Abbildung 17: Beispiel für Delegierung
Der DNS-Stammserver ist Host der Stammzone, die durch einen Punkt ( . ) dargestellt wird. Die Stammzone
enthält eine Delegierung zu einer Zone auf der nächsten Ebene der Hierarchie, der COM-Zone. Eine
Delegierung ist ein Datensatz in der übergeordneten Zone, der den für die delegierte Zone autorisierenden
Namenserver enthält. In diesem Beispiel ist der autorisierende Namenserver Server.com. Die Delegierung in der
Stammzone teilt dem DNS-Stammserver mit, dass er Server.com kontaktieren muss, um die COM-Zone zu
finden. Ebenso teilt die Delegierung in der COM-Zone Server.com mit, dass er mit Server.contoso.com
Kontakt aufnehmen muss, um die Zone contoso.com zu finden.
Anmerkung Eine Delegierung verwendet zwei Arten von Datensätzen. Der Namenserver-Ressourceneintrag
(NS) enthält den Namen eines autorisierenden Servers. Der Host-Ressourceneintrag (A) enthält die IP-Adresse
eines autorisierenden Servers.
Auf diese Weise kann der DNS-Stammserver jeden beliebigen Namen im Namespace finden. Die Stammzone
enthält Delegierungen, die direkt oder indirekt zu allen anderen Zonen führen. Jeder Server, der Abfragen an den
DNS-Stammserver sendet, kann die Informationen in den Delegierungen verwenden, um nach einem beliebigen
Namen im Namespace zu suchen. DNS-Server enthalten Hinweise auf den Stammserver, eine Liste mit Namen
und IP-Adressen, die Informationen bezüglich der Abfrage von DNS-Stammservern enthalten.
In einigen Konfigurationen enthalten bestimmte Server keine Hinweise auf den Stammserver. Stattdessen leiten
diese alle Abfragen, die sie nicht beantworten können, an einen anderen Server weiter.
Rekursive Namensauflösung
Clients senden sämtliche Abfragen zur Namensauflösung an DNS-Server. In einem Prozess namens rekursive
Namensauflösung verwenden Clients eine rekursive Abfrage, um Server anzuweisen, Namen aufzulösen und
eine definitive Antwort zurückzugeben, unabhängig davon, ob der Name existiert oder nicht. Kann ein Server
die Abfrage nicht autorisierend beantworten, sendet er sie an einen anderen DNS-Server. Der DNS-Server
ermittelt mithilfe einer der folgenden beiden Methoden, an welchen Server die Abfrage gesendet werden soll:
Verwendung der Hinweise auf den Stammserver oder Weiterleitung. Diese Methoden werden nachfolgend
beschrieben.
Auflösen von Namen mithilfe der Hinweise auf den Stammserver
Abbildung 18 zeigt, wie DNS einen Namen mithilfe der Hinweise auf den Stammserver auflöst.
Abbildung 18: Beispiel für eine rekursive Namensauflösung mit Hinweisen auf den Stammserver
In diesem Beispiel sendet der abfragende Client eine rekursive Abfrage für den Namen ftp.contoso.com an
einen DNS-Server (1). Da der DNS-Dienst für den Namen nicht autorisierend ist und die Antwort nicht in
seinem Cache hat, überprüft der DNS-Server die Hinweise auf den Stammserver, um die IP-Adresse des DNSStammservers zu ermitteln, und verwendet dann eine iterative Abfrage, um den DNS-Stammserver zur
Auflösung des Namens ftp.contoso.com aufzufordern (2). Mit einer iterativen Abfrage fordert der Server nicht
notwendigerweise eine definitive Antwort an. Stattdessen akzeptiert er den Hinweis auf einen anderen Server,
der eine bessere Antwort geben kann. Da der Name ftp.contoso.com mit dem COM-Bezeichner endet, gibt der
DNS-Stammserver eine Delegierung zur COM-Zone zurück (3). Anschließend führt der DNS-Server weitere
iterative Abfragen durch (4,5), bis er den Server Server.contoso.com erreicht (6), der die Antwort in seinen
Zonendateien findet und eine definitive Antwort zurückgibt (7). Der Server leitet dieses Ergebnis dann an den
Client weiter (8).
Auflösen von Namen durch Weiterleitung
Bei der Weiterleitung können Sie die Namensauflösung über bestimmte Server weiterleiten, anstatt die Hinweise
auf den Stammserver zu verwenden. Dies ist eine administrative Entscheidung und für die Unterstützung von
Active Directory nicht erforderlich. Falls Sie über einen DNS-Dienst verfügen, wurde diese Entscheidung bereits
getroffen. In Abbildung 19 wird ein Beispiel für eine weitergeleitete Abfrage dargestellt.
Abbildung 19: Beispiel für Weiterleitung
Dieses Beispiel entspricht dem vorherigen, mit Ausnahme des Umstands, dass der Client einen Server abfragt,
der für die Weiterleitung von Abfragen konfiguriert wurde. Sendet der Client eine Abfrage für den Namen
client.contoso.com (1), leitet der Server diese Abfrage an einen anderen Server weiter, der als
Weiterleitungsserver bezeichnet wird (2). Die übrigen Schritte entsprechen denen in der vorherigen Abbildung.
Forward- und Reverse-Lookups
Fragt ein Client einen Server nach einer IP-Adresse, die einem bestimmten Namen entspricht, dann fordert er
den Server auf, ein Forward-Lookup durchzuführen. Die Antwort befindet sich in einer Forward-Lookupzone.
Fragt ein Client einen Server dagegen nach einem Namen, der einer bestimmten IP-Adresse entspricht, dann
führt der Server ein Reverse-Lookup durch. Die Antwort befindet sich in einer Reverse-Lookupzone. IP-Adressen
von Computern werden in Datensätzen gespeichert, die als Zeigereinträge (PTR) bezeichnet werden.
Die Reverse-Lookupfunktion ist für den einwandfreien Betrieb von Active Directory nicht erforderlich. Wenn
Sie über einen DNS-Namespace mit einer bestehenden Reverse-Lookupzone verfügen, kann der aktuelle DNSAdministrator diese Zonen weiterhin verwalten. Ist dagegen kein DNS-Namespace vorhanden, brauchen Sie
keine Reverse-Lookupzone zu erstellen, um Active Directory bereitstellen zu können.
Suchen nach Active Directory-Domänencontrollern
Clients kommunizieren mit Domänencontrollern im Hinblick auf Operationen wie das Verarbeiten von
Anmeldeanforderungen und das Durchsuchen des Verzeichnisses auf veröffentlichte Ressourcen, z. B. Drucker.
In Abbildung 20 wird dargestellt, wie Clients DNS bei der Suche nach Active Directory-Domänencontrollern
einsetzen. In diesem Beispiel ist der Domänencontroller in DNS registriert (1). Der Client fragt einen DNSServer nach den Namen der Domänencontroller in der Domäne (2). Der DNS-Server führt eine rekursive
Namensauflösung durch, um die Namen der Domänencontroller zu ermitteln, und gibt die Namen und IPAdressen dann an den Client zurück. Der Client verwendet die IP-Adresse, um mit dem Domänencontroller
Kontakt aufzunehmen (3).
Abbildung 20: Suche von Clients nach Domänencontrollern
Clients benötigen die IP-Adresse eines DNS-Servers, um nach einem Domänencontroller suchen zu können.
Domänencontroller registrieren eine Reihe von Datensätzen in DNS, um Clients und andere Computer bei der
Suche zu unterstützen. Diese Datensätze werden als Lokatoreinträge bezeichnet.
In Windows 2000 Active Directory integriertes DNS
Der DNS-Server von Windows 2000 kann Zonen in Active Directory speichern. Die Integration in Active
Directory hat folgende Vorteile:
•
•
Es stehen mehrere Master für die DNS-Replikation zur Verfügung, d. h.:
o Jeder DNS-Server kann Aktualisierungen für diese Zone akzeptieren.
o Es ist keine separate DNS-Replikationstopologie erforderlich.
Sichere dynamische Aktualisierungen werden unterstützt.
Über sichere dynamische Aktualisierungen kann ein Administrator genau steuern, welche Computer
welche Namen aktualisieren. Sie verhindern außerdem, dass nicht autorisierte Computer vorhandene
Namen in DNS überschreiben.
•
Das Aufräumen überholter Datensätze wird unterstützt.
Weitere Informationen zu DNS finden Sie in den Dokumenten, die in Tabelle 14 aufgelistet werden.
Tabelle 14: Weitere Informationen zu DNS
Dokument
Kapitel 5, "Introduction to DNS", in
Windows 2000 TCP/IP Core
Networking Guide in
Windows 2000 Server Resource Kit
(englischsprachig)
Kapitel 6, "Windows 2000 DNS", in
Windows 2000 TCP/IP Core
Networking Guide in
Windows 2000 Server Resource Kit
(englischsprachig)
DNS and BIND (englischsprachig),
3. Auflage, von Paul Albitz und
Cricket Liu, 1998, Sebastopol, CA:
O'Reilly & Associates
RFC 1034 und 1035.
Windows 2000 Server-Hilfe
Allgemeine DNS-Informationen
•
Windows 2000-DNS-Informationen
•
•
•
•
•
Weitere Informationen zu RFC 1034 und 1035 erhalten Sie über die Request for Comment-Verknüpfung auf der
Seite "Windows Resource Kits – Web Resources" unter
http://www.microsoft.com/windows2000/techinfo/reskit/WebResources/default.asp (englischsprachig).
Benennen von Computern
Windows 2000 verwendet erstmalig das Konzept eines primären DNS-Suffixes für Computernamen. Wenn ein
Windows 2000-Computer einer Domäne beitritt, wird der Computer automatisch mit einem Namen registriert,
der aus dem Hostnamen des Computers und dem DNS-Namen der Domäne, der der Computer beigetreten ist,
besteht (<Computername>.<Primäres_Suffix>). Dieser vollqualifizierte DNS-Name für den Computer wird als
primärer Name bezeichnet.
Es ist möglich, dass ein Computer bereits über einen DNS-Namen verfügt, der statisch in einen DNS-Server
eingegeben oder von einem integrierten DNS/DHCP-Dienst registriert wurde. Der primäre Name des Computers
unterscheidet sich von diesen bereits registrierten Namen.
Elemente des DNS-Entwurfs
Der Gesamtstrukturbesitzer und der DNS-Besitzer sind für die Erstellung eines DNS-Entwurfs für die
Organisation verantwortlich. Der Plan muss Folgendes enthalten:
•
•
Konfiguration des DNS-Servers, einschließlich:
o DNS-Serverposition
o Zonenposition und -typ
o Methode der rekursiven Namensauflösung
Konfiguration des DNS-Clients, einschließlich:
o Namensschema des Computers
o Auflösungskonfiguration
Rolle des DNS-Besitzers
Jede Domäne sollte einen DNS-Besitzer enthalten, der dem Domänenbesitzer Bericht erstattet. Der DNSBesitzer ist für die Erstellung des DNS-Entwurfs für Windows 2000 verantwortlich.
Wenn Ihre Organisation eine Migration von Windows NT durchführt, ist derzeit ein Mitarbeiter für die
Unterstützung der WINS-Namensauflösung verantwortlich. Der DNS-Besitzer stellt Unterstützung für DNS auf
ähnliche Weise bereit, wie derzeit die WINS-Unterstützung bereitgestellt wird.
Der DNS-Besitzer ist für kontinuierlichen Kontakt mit den DHCP- und DNS-Gruppen der Organisation
verantwortlich. Diese Gruppen sollten am Active Directory DNS-Entwurfsprozess beteiligt werden, so dass jede
Gruppe über die Pläne Ihres Teams informiert ist und Feedback dazu geben kann.
Optimale Vorgehensweise für einen DNS-Entwurf ohne bestehenden DNSDienst
Die optimale Vorgehensweise für DNS hängt davon ab, ob DNS bereits im Netzwerk implementiert wurde.
Wurde kein DNS-Dienst implementiert, sollten der Gesamtstrukturbesitzer und der DNS-Besitzer für Active
Directory die Implementierung entsprechend den optimalen Vorgehensweisen planen.
Das Begleithandbuch Best Practice Active Directory Deployment for Managing Windows Networks
(englischsprachig) enthält detaillierte Anweisungen zur Bereitstellung von DNS. Die hier zur Verfügung
gestellten Informationen dienen lediglich als Anhaltspunkt.
Serverkonfiguration
Erstellen Sie DNS-Domänen, die den bereits eingerichteten Active Directory-Domänen entsprechen.
Abbildung 21 zeigt einen möglichen DNS-Entwurf für eine Organisation, in der DNS noch nicht implementiert
wurde.
Abbildung 21: Neue DNS-Struktur
In diesem Entwurf ist der DNS-Server, der für den Namen der Stammdomäne der Gesamtstruktur autorisierend
ist, eine private Stammzone. Alle anderen Server listen die DNS-Stammserver in ihren Hinweisen auf den
Stammserver auf.
Tabelle 15 gibt einen Überblick über die optimalen Vorgehensweisen bei der DNS-Konfiguration für ein
Netzwerk ohne bestehenden DNS-Dienst.
Tabelle 15: Optimale Vorgehensweisen beim DNS-Entwurf für eine Organisation ohne DNS-Dienst
Entwurfselement
Konfiguration
DNS-Serverposition
Auf jedem Domänencontroller sollte DNS ausgeführt werden.
Rekursive Namensauflösung Alle Server mit Ausnahme des Domänencontrollers des Gesamtstrukturstammes
sollten Hinweise auf den Stammserver enthalten.
Zonenposition
Die Stammdomäne der Gesamtstruktur enthält Zonen für:
• DNS-Stamm
• Stammdomäne der Gesamtstruktur
• _msdcs.<Gesamtstruktur-Stammdomäne>
Jede untergeordnete Domäne enthält Zonen für:
• Eigene untergeordnete Domänen
• _msdcs.<Gesamtstruktur-Stammdomäne>
Anmerkung Active Directory verwendet einen speziellen Satz mit Lokatoreinträgen, die gesamtstrukturweiten
Lokatoreinträge, damit Replikationspartner einander leichter finden können und um Clients die Suche nach
globalen Katalogservern zu erleichtern. Active Directory speichert alle gesamtstrukturweiten Lokatoreinträge in
der Zone _msdcs.<Gesamtstrukturname>. Da die Informationen in der Zone allgemein verfügbar sein müssen,
wird diese Zone auf alle DNS-Server in der Gesamtstruktur repliziert.
Zonenkonfiguration für DNS-Server im Gesamtstrukturstamm
Entwerfen Sie anhand von Tabelle 16 die Zonenkonfiguration für die DNS-Stammzone.
Tabelle 16: DNS-Stammzone
Entwurfselement
Zonentyp
Dynamische Aktualisierungen
Aufräumvorgänge
Delegierungen von der Stammzone auf andere Zonen
Entwurf
Active Directory-integriert
Deaktiviert
Deaktiviert
Für jede Stammzone der Gesamtstruktur wird eine
Delegierung erstellt. Die Delegierung enthält einen NSEintrag für jeden Domänencontroller des
Gesamtstrukturstammes.
Entwerfen Sie anhand von Tabelle 17 die Zonenkonfiguration für die Stammzone der Gesamtstruktur.
Tabelle 17: DNS-Stammzone der Gesamtstruktur
Entwurfselement
Zonentyp
Dynamische Aktualisierungen
Aufräumvorgänge
Delegierungen von der Stammzone der Gesamtstruktur
auf andere Zonen
Entwurf
Active Directory-integriert
Nur sichere dynamische Aktualisierungen
Aktiviert, mit Standardeinstellungen
• Für die Zone _msdcs.<GesamtstrukturStammdomäne> wird eine Delegierung erstellt. Die
Delegierung enthält einen NS-Eintrag für jeden
Domänencontroller des Gesamtstrukturstammes.
• Es wird eine Delegierung für die entsprechenden
regionalen Domänen erstellt. Jede Delegierung enthält
einen NS-Eintrag für alle regionalen Domänencontroller
in der entsprechenden regionalen Domäne.
Entwerfen Sie anhand von Tabelle 18 die Zonenkonfiguration für die Zone _msdcs.<GesamtstrukturStammdomäne>.
Tabelle 18: Konfiguration der Zone "_msdcs.<Gesamtstruktur-Stammdomäne>"
Entwurfselement
Zonentyp
Dynamische Aktualisierungen
Aufräumvorgänge
Entwurf
Active Directory-integriert
Nur sichere dynamische Aktualisierungen
Aktiviert
Zonenkonfiguration für DNS-Server in einer regionalen Domäne
Die Zone für die regionale Domäne wird wie in Tabelle 19 und 20 angegeben konfiguriert.
Tabelle 19: Zone für die untergeordnete Domäne
Entwurfselement
Zonentyp
Dynamische Aktualisierungen
Aufräumvorgänge
Entwurf
Active Directory-integriert
Nur sichere dynamische Aktualisierungen
Aktiviert
Tabelle 20: Konfiguration für die sekundäre Kopie der Zone "_msdcs.<GesamtstrukturStammdomäne>"
Entwurfselement
Zonentyp
Dynamische Aktualisierungen
Aufräumvorgänge
Andere Konfigurationseinstellungen
Entwurf
Sekundär
Nicht zutreffend
Nicht zutreffend
Die Zonenübertragungsquelle ist ein DNS-Server auf
einem nahe gelegenen Domänencontroller im
Gesamtstrukturstamm.
Clientkonfiguration
Bei der Konfiguration des DNS-Clients muss der DNS-Besitzer für Active Directory angeben, welches
Namensschema für den Computer verwendet werden soll und wie der Client nach DNS-Servern suchen soll.
Tabelle 21 fasst diese Spezifikationen zusammen.
Tabelle 21: Clientkonfiguration für DNS, wenn kein DNS-Dienst zur Verfügung steht
Entwurfselement
Computername
Konfiguration der Clientauflösung
Konfiguration
Verwenden Sie den Standardnamen. Wenn ein
Computer unter Windows 2000 einer Domäne beitritt,
wird dem Computer ein primärer DNS-Name
zugewiesen, der sich aus dem Hostnamen des
Computers und dem Namen der Domäne
zusammensetzt.
Konfigurieren Sie Clients mit den Adressen von
mindestens zwei DNS-Servern, die auf Active
Directory-Domänencontrollern ausgeführt werden.
In Abbildung 22 wird das Modell für die Clientkonfiguration dargestellt. Dieses Modell setzt voraus, dass Sie
einen DHCP-Server ausführen, nicht jedoch einen DNS-Server oder eine integrierte DNS/DHCP-Lösung.
Abbildung 22: Benennen von Computern ohne DNS, aber mit bestehendem DHCP-Dienst
In diesem Beispiel weist ein DHCP-Server dem Computer Server.noam.corp.contoso.com eine IP-Adresse zu.
Der Computer registriert seinen DNS-Namen in der neuen DNS-Infrastruktur. Fragt ein Client DNS nach dem
Namen des Computers, sucht der DNS-Server nach dem Namen und löst die Abfrage auf.
Bei diesem Modell müssen an dem bereits vorhandenen DHCP-Dienst keine Änderungen vorgenommen werden.
Optimale Vorgehensweise für einen DNS-Entwurf mit bestehendem DNSDienst
Die optimale Vorgehensweise für DNS hängt davon ab, ob DNS bereits im Netzwerk implementiert wurde.
Wurde ein DNS-Dienst implementiert, sollten der Gesamtstrukturbesitzer und der DNS-Besitzer für Active
Directory mit dem aktuellen DNS-Besitzer zusammenarbeiten, um den DNS-Namen der Stammdomäne der
Gesamtstruktur an Active Directory zu delegieren und einen Active Directory-integrierten DNS-Dienst wie
angegeben zu konfigurieren.
Das Begleithandbuch Best Practice Active Directory Deployment for Managing Windows Networks
(englischsprachig) enthält detaillierte Anweisungen zur Bereitstellung von DNS. Die hier zur Verfügung
gestellten Informationen dienen lediglich als Anhaltspunkt.
Serverkonfiguration
Erstellen Sie DNS-Domänen, die den bereits eingerichteten Active Directory-Domänen entsprechen. Tabelle 22
gibt einen Überblick über die optimalen Vorgehensweisen bei der DNS-Konfiguration für ein Netzwerk mit
bestehendem DNS-Dienst.
Tabelle 22: Optimale Vorgehensweisen beim DNS-Entwurf für eine Organisation mit DNS-Dienst
Entwurfselement
DNS-Serverposition
Rekursive Namensauflösung
Zonenposition
Konfiguration
Auf jedem Domänencontroller sollte DNS ausgeführt
werden.
Ermitteln Sie, ob der vorhandene DNS-Dienst die
Weiterleitung oder die Hinweise auf den Stammserver
verwendet. Konfigurieren Sie DNS auf den
Domänencontrollern entsprechend.
Der Gesamtstrukturstamm enthält Zonen für:
• Stammdomäne der Gesamtstruktur
• _msdcs.<Gesamtstruktur-Stammdomäne>
Jede regionale Domäne enthält eine Zone für:
• Eigene untergeordnete Domänen
• _msdcs.<Gesamtstruktur-Stammdomäne>
Anmerkung Active Directory verwendet einen speziellen Satz mit Lokatoreinträgen, die gesamtstrukturweiten
Lokatoreinträge, damit Replikationspartner einander leichter finden können und um Clients die Suche nach
globalen Katalogservern zu erleichtern. Active Directory speichert alle gesamtstrukturweiten Lokatoreinträge in
der Zone _msdcs.<Gesamtstrukturname>. Da die Informationen in der Zone allgemein verfügbar sein müssen,
wird diese Zone auf alle DNS-Server in der Gesamtstruktur repliziert.
Dieser Entwurf hat den Vorteil, dass die bestehende DNS-Struktur erhalten bleibt. Sie brauchen keine
Migrationen für Server oder Zonen durchzuführen. Sie fügen lediglich einer bestehenden DNS-Hierarchie
Domänen hinzu, wie es von den DNS-Entwicklern beim Verfassen der RFCs vorgesehen war.
Anmerkung Es sind zwar auch andere DNS-Serverimplementierungen möglich, die Unterstützung für Active
Directory bieten, aber die Verwendung von Windows 2000 Active Directory-integriertem DNS wird empfohlen,
da sie sichere dynamische Aktualisierungen unterstützt.
Die Serverkonfiguration hängt davon ab, ob der DNS-Dienst die Hinweise auf den Stammserver oder die
Weiterleitung für die rekursive Namensauflösung verwendet.
Hinweise auf den Stammserver
Abbildung 23 zeigt das Serverkonfigurationsmodell für ein Netzwerk, das die Hinweise auf den Stammserver
verwendet. Ein DNS-Server an einem beliebigen Standort ist Host einer Stammzone. Bei dieser Zone kann es
sich um den Internetstamm oder einen privaten Stamm handeln. Für die Konfiguration ist diese Unterscheidung
jedoch irrelevant.
Abbildung 23: Integration mit bestehendem Dienst unter Verwendung der Hinweise auf den Stammserver
In diesem Beispiel verfügen die DNS-Server über Hinweise auf den Stammserver, die den Standort des DNSStammserver angeben. Erhält ein DNS-Server eine Abfrage, die er nicht aus dem Cache oder den Zonendateien
beantworten kann, fragt der DNS-Server den DNS-Stammserver.
Weiterleitung
Abbildung 24 zeigt das Serverkonfigurationsmodell für ein Netzwerk, das die Weiterleitung verwendet.
Abbildung 24: Integration mit bestehendem Dienst unter Verwendung der Weiterleitung
In dieser Konfiguration leiten untergeordnete DNS-Server Abfragen an den am nächsten gelegenen DNS-Server
des Gesamtstrukturstammes weiter, der die Abfragen wiederum an denselben Weiterleitungsserver weitergibt,
der gegenwärtig von den vorhandenen DNS-Servern verwendet wird.
Zonenkonfiguration für DNS-Server im Gesamtstrukturstamm
Entwerfen Sie anhand von Tabelle 23 die Zonenkonfiguration für die Stammzone der DNS-Gesamtstruktur.
Tabelle 23: DNS-Stammzone der Gesamtstruktur
Entwerfen Sie anhand von Tabelle 24 die Zonenkonfiguration für die DNS-Zone "_msdcs.<GesamtstrukturStammdomäne>".
Entwurfselement
Zonentyp
Dynamische Aktualisierungen
Aufräumvorgänge
Delegierungen von der Stammzone auf andere Zonen
Andere Konfigurationseinstellungen
Entwurf
Active Directory-integriert
Nur sichere dynamische Aktualisierungen
Aktiviert
• Für die Zone _msdcs.<GesamtstrukturStammdomäne> wird eine Delegierung erstellt. Die
Delegierung enthält NS-Einträge für alle
Domänencontroller des Gesamtstrukturstammes.
• Delegierungen werden für die entsprechenden
regionalen Domänen erstellt. Jede Delegierung enthält
einen NS-Eintrag für alle regionalen Domänencontroller
in der entsprechenden regionalen Domäne.
Die übergeordnete Zone wird aktualisiert, so dass sie
eine Delegierung für diese Zone enthält.
Tabelle 24: DNS-Zone "_msdcs.<Gesamtstruktur-Stammdomäne>"
Entwurfselement
Zonentyp
Dynamische Aktualisierungen
Aufräumvorgänge
Entwurf
Active Directory-integriert
Nur sichere dynamische Aktualisierungen
Aktiviert
Zonenkonfiguration für DNS-Server in regionalen Domänen
Die Zone für jede regionale Domäne wird wie in Tabelle 25 und 26 angegeben konfiguriert.
Tabelle 25: Zone für die regionale Domäne
Entwurfselement
Zonentyp
Dynamische Aktualisierungen
Aufräumvorgänge
Entwurf
Active Directory-integriert
Nur sichere dynamische Aktualisierungen
Aktiviert
Tabelle 26: Konfiguration für die sekundäre Kopie der Zone "_msdcs.<GesamtstrukturStammdomäne>"
Entwurfselement
Zonentyp
Dynamische Aktualisierungen
Aufräumvorgänge
Andere Konfigurationseinstellungen
Clientkonfiguration
Entwurf
Sekundär
Nicht zutreffend
Nicht zutreffend
Die Zonenübertragungsquelle ist ein DNS-Server auf
einem nahe gelegenen Domänencontroller im
Gesamtstrukturstamm.
Bei der Konfiguration des DNS-Clients muss der DNS-Besitzer für Active Directory angeben, welches
Namensschema für den Computer verwendet werden und wie der Client nach DNS-Servern suchen soll.
Tabelle 27 fasst diese Spezifikationen zusammen.
Tabelle 27: Clientkonfiguration für DNS, wenn ein DNS-Dienst zur Verfügung steht
Entwurfselement
Computername
Konfiguration der Clientauflösung
Konfiguration
Verwenden Sie den Standardnamen. Wenn ein
Computer unter Windows 2000 einer Domäne beitritt,
wird dem Computer ein primärer DNS-Name
zugewiesen, der sich aus dem Hostnamen des
Computers und dem Namen der Domäne
zusammensetzt.
Ändern Sie die Auflösungskonfiguration für
vorhandene Clients nicht. Windows 2000-Clients
müssen nicht direkt auf einen Windows 2000-DNSServer verweisen und können einen beliebigen DNSServer im Netzwerk verwenden.
Wurde für die Clients bereits ein Name in DNS registriert, verfügen die Clients nunmehr über zwei Namen: den
bereits vorhandenen Namen und den neuen primären Namen. Clients können weiterhin über beide Namen
gefunden werden. Die primären Namen werden automatisch erstellt, über dynamische Aktualisierungen
aktualisiert und durch Aufräumvorgänge automatisch bereinigt.
Ein Computer verfügt u. U. bereits über einen DNS-Namen, wenn die Organisation eine der folgenden
Komponenten implementiert hat:
•
•
Einen DNS-Dienst
Eine integrierte DHCP/DNS-Lösung
Anmerkung Die Verwendung von Standardnamen für Windows 2000-Clients wirkt sich nicht auf
Authentifizierungsmechanismen aus, die im vorhandenen Netzwerk eingesetzt werden.
Falls Sie bei der Herstellung einer Verbindung zu einem Server mit Windows 2000 die KerberosAuthentifizierung nutzen möchten, müssen Sie sicherstellen, dass der Client den primären Namen verwendet,
wenn er die Verbindung zum Server herstellt.
Bei jedem dieser Entwürfe bleibt eine bestehende DNS-, DHCP- oder integrierte DNS/DHCP-Lösung erhalten.
Sind der DNS- und der Active Directory-Name unterschiedlich, können Sie ein beliebiges DNS-Suffix anstelle
des Active Directory-Domänennamens verwenden. Eine solche Konfiguration ist jedoch mit zusätzlichem
Verwaltungsaufwand verbunden und stellt daher keine optimale Vorgehensweise dar.
Anmerkung Falls Sie bereits eine Reverse-Lookupzone konfiguriert haben, sollten Sie die ReverseLookupzone und alle PTR-Einträge beibehalten. Alle bereits vorhandenen Clients können unter ihren aktuellen
Namen registriert werden.
Clients mit Namen, die auf einem vorhandenen DNS-Server statisch registriert wurden
In diesem Modell verfügt das Netzwerk bereits über einen DNS-Server, für den der Administrator Namen
manuell eingibt. In Abbildung 25 wird ein Beispiel für diese Konfiguration dargestellt.
Abbildung 25: Benennen von Computern mit vorhandenem DNS-Dienst
In diesem Beispiel ist der vorhandene DNS-Server Host einer Zone, die den Namen Server.seattle.contoso.com
enthält. Nach dem Beitritt zu der Domäne registriert der Server außerdem einen neuen Namen,
Server.noam.concorp.contoso.com, bei einem DNS-Server, der auf einem Domänencontroller ausgeführt wird.
Clients können den Server unter beiden DNS-Namen finden. Wenn ein Client eine Abfrage an einen DNSServer sendet, führt der DNS-Server eine Namensauflösung durch, um die IP-Adresse für den Namen zu
ermitteln. Abhängig von der DNS-Konfiguration leitet der DNS-Server die Abfrage weiter oder führt eine
rekursive Namensauflösung durch. In beiden Fällen fragt er den entsprechenden Server nach dem Namen und
leitet die entsprechende Antwort an den Client weiter.
Dieses Modell wirkt sich nicht auf DNS-Namensysteme aus, die bereits vorhanden sind. Ist der DNS-Server vor
der Bereitstellung Host einer Zone, die Namen für Ihre Computer enthält, kann er das auch nach der
Bereitstellung sein.
Clients mit Namen, die durch eine integrierte DHCP/DNS-Lösung registriert wurden
In diesem Modell verwendet das bestehende Netzwerk eine integrierte DHCP/DNS-Lösung, z. B. Lucent QIP. In
Abbildung 26 wird ein Beispiel für diese Konfiguration dargestellt.
Abbildung 26: Benennen von Computern mit integrierter DHCP/DNS-Lösung
In diesem Beispiel nutzt der Server, Server.seattle.contoso.com, den DHCP-Server zur Registrierung seines
Namens beim DNS-Server und zur Bereitstellung einer IP-Adresse. Nach dem Beitritt zu einer Domäne
registriert der Server außerdem einen neuen Namen, Server.noam.corp.contoso.com, bei einem DNS-Server,
der auf einem Domänencontroller ausgeführt wird.
Clients können den Server unter beiden DNS-Namen finden. Wenn ein Client eine Abfrage an einen DNSServer sendet, führt der DNS-Server eine Namensauflösung durch, um die IP-Adresse für den Namen zu
ermitteln. Abhängig von der DNS-Konfiguration leitet der DNS-Server die Abfrage weiter oder führt eine
rekursive Namensauflösung durch. In beiden Fällen fragt er den entsprechenden Server nach dem Namen und
leitet die entsprechende Antwort an den Client weiter.
Dieses Modell wirkt sich nicht auf eine integrierte DHCP/DNS-Lösung aus, die bereits vorhanden ist. Registriert
der DHCP-Server vor der Bereitstellung DNS-Namen für Ihre Computer, kann er das auch nach der
Bereitstellung tun.
Entwurfsprozess für DNS
Am Ende des DNS-Planungsprozesses sollten Sie über einen DNS-Entwurf verfügen, der auf optimaler
Vorgehensweise basiert. Der DNS-Entwurfsprozess umfasst die folgenden Schritte:
1.
2.
3.
4.
5.
Planen der DNS-Serverposition
Planen der rekursiven Namensauflösung
Konfigurieren der DNS-Zonen
Planen der Computernamen
Konfigurieren der Clientauflösung
Abbildung 27 stellt den DNS-Entwurfsprozess dar.
Abbildung 27: Flussdiagramm der Aufgaben, die beim DNS-Entwurf für Active Directory durchgeführt
werden müssen
Die Entscheidungen bei der DNS-Planung sind einfach und routinemäßig. Wenn Sie bereits über eine DNSStruktur verfügen, sind viele Entscheidungen durch diese Struktur vorgegeben. Füllen Sie das entsprechende
DNS-Tabellenblatt aus, während Sie die einzelnen Komponenten entwerfen. Nachdem Sie den Prozess
abgeschlossen haben, lassen Sie den Entwurf von externen DNS- und DHCP-Gruppen überprüfen.
Weitere Schritte
Im Rahmen des Domänenentwurfs wurde der Domänenbesitz vom Gesamtstrukturbesitzer zugewiesen. Für jede
Domäne wurde während des Domänenentwurfsprozesses ein Domänenbesitzer festgelegt. Jeder
Domänenbesitzer kann nunmehr unabhängig mit der nächsten Phase des Entwurfsprozesses fortfahren, die im
folgenden Abschnitt beschrieben wird.
Erstellen eines Entwurfs der Organisationseinheiten
Nach Abschluss der Domänenplanung kann eine OE-Struktur entworfen werden. Ein auf optimalen
Vorgehensweisen basierendes OE-Modell sieht vor, dass Abteilungen innerhalb der Domäne ihre internen
Operationen verwalten, während das IT-Personal der Domäne die Verwaltung der allgemeinen Infrastruktur
übernimmt. Mit anderen Worten, die Abteilungen verwalten die Objekte im Verzeichnis, während das ITPersonal der Domäne die Konfiguration des Verzeichnisses selbst verwaltet.
Die optimalen Vorgehensweisen bei der Erstellung eines OE-Entwurfs sehen die Einführung der Rolle des "OEBesitzers" vor. Der OE-Besitzer in Active Directory ist mit den meisten Windows NT-Domänenadministratoren
vergleichbar. Das bedeutet, dass Domänenadministratoren, die Benutzer und Ressourcen in einer Windows NTDomäne verwalten, die Verwaltung dieser Ressourcen auch in einer Active Directory-Domäne übernehmen, dort
jedoch Besitzer von Organisationseinheiten sind.
Es ist damit zu rechnen, dass regelmäßig Änderungen an der OE-Struktur vorgenommen werden müssen, um
diese der Verwaltungsstruktur anzupassen und die richtlinienbasierte Verwaltung zu unterstützen.
Organisationseinheiten wurden so konzipiert, dass sie leicht verändert werden können.
Funktionen von Organisationseinheiten in Windows-Netzwerkentwürfen
Organisationseinheiten sind Container innerhalb von Domänen, die andere Organisationseinheiten, Benutzer,
Gruppen, Computer und andere Objekte enthalten. Diese OEs und untergeordnete OEs bilden eine hierarchische
Struktur innerhalb einer Domäne und werden hauptsächlich zur Bildung von Objektgruppen verwendet, die die
Verwaltung erleichtern.
Anmerkung Es gibt keine praktischen Beschränkungen hinsichtlich der OE-Ebenen, die verschachtelt werden
können. Wenn Sie Unterebenen der Organisationseinheiten entwerfen, sollten Sie jedoch die zusätzliche
Granularität bei der Steuerung und die höhere Komplexität bei der Verwaltung der Struktur gegeneinander
abwägen. Es wird empfohlen, OE-Strukturen mit maximal zehn Ebenen zu erstellen.
Wenn Sie eine OE-Struktur entwerfen, sollten Sie daran denken, dass die OE-Hierarchie nicht der
Abteilungshierarchie Ihrer Organisation entsprechen muss. Jede Organisationseinheit, die Sie erstellen, sollte
einen bestimmten Zweck erfüllen (z. B. Delegierung oder Anwendung von Richtlinien) und für Ihr System von
Nutzen sein; andernfalls investieren Sie mehr Zeit in die Verwaltung der Struktur, ohne einen wirklichen Vorteil
zu haben.
Das erste Ziel beim Entwerfen einer OE-Struktur ist die Verwaltungsdelegierung. Nachdem Sie die Struktur
erstellt haben, können Sie diese weiter differenzieren, indem Sie Unterebenen mit Organisationseinheiten
hinzufügen, die bestimmten Zwecken dienen, z. B. der Anwendung der Gruppenrichtlinien oder der
Verschiebung von Objekten in separate Organisationseinheiten, um deren Sichtbarkeit zu reduzieren.
Delegierung der Verwaltung
Die Delegierung der Verwaltung ermöglicht Ihnen die Bestimmung von Benutzergruppen, die Zugriff auf
Benutzer, Computer und andere Objekte in einer Organisationseinheit haben. Fügen Sie hierzu den Benutzer, der
über Zugriff verfügen soll, einer Gruppe hinzu, verschieben Sie den Objektsatz, auf den der Benutzer Zugriff
haben soll, in eine Organisationseinheit, und delegieren Sie die Verwaltung der Organisationseinheit an die
entsprechende Gruppe. In Windows 2000 können Sie die zu delegierenden Verwaltungsaufgaben differenzieren;
beispielsweise können Sie mehrere Gruppen erstellen: eine, die Vollzugriff auf alle Objekte in einer
Organisationseinheit besitzt, eine zweite, die Benutzerkonten in der Organisationseinheit erstellen, löschen und
verwalten kann, und eine dritte, die lediglich das Kennwort für Benutzerkonten zurücksetzen kann. Sie können
festlegen, dass diese Berechtigungen vererbbar sind, so dass sie nicht nur für einen Container, sondern auch für
Subcontainer gelten.
Organisationseinheiten ersetzen Windows NT-Domänen als Ziel für die Verwaltungsdelegierung, was folgende
Vorteile bietet:
•
•
Die Anzahl der Administratoren mit umfassenden Zugriffsberechtigungen wird minimiert.
Einzelne Gruppen in Ihrer Organisation sind für die Verwaltung auf lokaler Ebene verantwortlich.
Gruppenrichtlinien
Obwohl der erste Entwurf der OE-Struktur nur der Verwaltungsdelegierung dient, fügen einige Organisationen
später weitere Ebenen mit Organisationseinheiten hinzu, die für Gruppenrichtlinien bestimmt sind.
Gruppenrichtlinien können Sicherheitsgruppen verwenden, um ihre Gültigkeit einzuschränken, d. h. eine
Gruppenrichtlinieneinstellung kann auf eine Untergruppe von Objekten in einer OE angewendet werden, ohne
dass die Erstellung einer untergeordneten OE erforderlich ist. Beispielsweise können Sie eine
Gruppenrichtlinieneinstellung erstellen, die nur für Manager gilt, selbst wenn Ihre Organisationseinheit alle
Benutzer enthält. Hierzu wenden Sie die Gruppenrichtlinieneinstellung auf die Organisationseinheit an, erstellen
dann eine Gruppe mit Managern und ändern die Berechtigungen für die Richtlinie so, dass sie nur für diese
Gruppe gelten. Um die Verwaltung dagegen an eine Untergruppe einer Organisationseinheit zu delegieren,
müssen Sie eine untergeordnete OE erstellen. Da Sie die Gültigkeit der Gruppenrichtlinien mithilfe von
Sicherheitsgruppen präzise festlegen können, hat die Delegierung der Verwaltung im OE-Entwurfsprozess
Priorität.
Anmerkung Sie können Gruppenrichtlinieneinstellungen nicht auf die Standardcontainer Users und
Computers anwenden. Dies sind keine Organisationseinheiten, und sie können auch keine
Organisationseinheiten enthalten, so dass sie für Gruppenrichtlinien nicht verwendet werden können.
Es wird empfohlen, die Standardwerte zu übernehmen, die in den Standarddomänenrichtlinien und den StandardDomänencontrollerrichtlinien festgelegt sind, mit Ausnahme der im Folgenden aufgelisteten Knoten. Diese
Knoten enthalten Einstellungen, die Sie an Ihre Sicherheitsanforderungen anpassen sollten.
•
•
Standarddomänenrichtlinien
o Kennwortrichtlinien
o Kontosperrungsrichtlinien
o Kerberos-Richtlinien
Standard-Domänencontrollerrichtlinien
o Zuweisung von Benutzerrechten
Andere Gruppenrichtlinieneinstellungen (die sich nicht auf die Sicherheit beziehen) sollten im Rahmen dieser
Standard-Gruppenrichtlinieneinstellungen nicht festgelegt werden; erstellen Sie stattdessen neue
Gruppenrichtlinienobjekte (Group Policy Objects oder GPOs). Um weitere Informationen zur Planung und
Implementierung von Gruppenrichtlinien zu erhalten, lesen Sie die folgenden Artikel:
•
Zur Planung von Gruppenrichtlinien siehe Change and Configuration Management Deployment Guide
zu Windows 2000, verfügbar unter:
http://www.microsoft.com/windows2000/techinfo/reskit/deploy/CCM/default.asp (englischsprachig)
•
GPO-Vorlagen für sechs verschiedene Verwaltungsszenarien finden Sie in "Implementing Common
Desktop Management Scenarios", verfügbar unter:
http://www.microsoft.com/windows2000/techinfo/howitworks/management/grouppolicy.asp
(englischsprachig)
•
Zu Gruppenrichtlinien:
http://www.microsoft.com/windows2000/techinfo/howitworks/management/grouppolwp.asp
(englischsprachig)
•
Zur Benutzerverwaltung:
http://www.microsoft.com/windows2000/techinfo/administration/management/settings.asp
(englischsprachig)
Elemente eines OE-Planes
Der Domänenbesitzer ist für die Erstellung des OE-Entwurfs für die Domäne verantwortlich. Der Entwurf muss
Folgendes enthalten:
•
•
Ein Diagramm der OE-Hierarchie
Eine Liste der Organisationseinheiten. Für jede Organisationseinheit müssen folgende Informationen
vorhanden sein:
o Informationen über ihren Zweck
o Eine Liste der Benutzer oder Gruppen, die auf diese Organisationseinheit oder die in ihr
enthaltenen Objekte Zugriff haben
o Die Art des Zugriffs, die auf die Objekte in der Organisationseinheit gewährt wurde
Zeichnen Sie Ihre Antworten in den Tabellenblättern für den OE-Entwurf auf, die weiter unten in diesem
Handbuch bereitgestellt werden.
Rolle des Besitzers von Organisationseinheiten
Der Domänenbesitzer legt für jede OE einen OE-Besitzer fest. Jeder OE-Besitzer ist ein Datenmanager mit
Kontrolle über eine Teilstruktur der Objekte in Active Directory. OE-Besitzer besitzen oder steuern keine
Operationen des Dienstes; dieser Dienst untersteht der Kontrolle des Domänenbesitzers. Auf diese Weise können
Sie den Besitz und die Verwaltung des Dienstes von denen der Objekte innerhalb des Dienstes trennen und die
Anzahl der Dienstadministratoren mit umfassenden Zugriffsberechtigungen reduzieren.
Anmerkung Obwohl die Kontrolle über eine Teilstruktur der Objekte auf den OE-Besitzer übertragen wird,
behält der Domänenbesitzer die vollständige Kontrolle über alle Teilstrukturen. Diese Einstellung sollte nicht
geändert werden, damit der Domänenbesitzer z. B. eine fehlerhafte Zugriffssteuerungsliste (Access Control List
oder ACL) korrigieren oder verloren gegangene Teilstrukturen bei Ausfall eines Administrators wiederherstellen
kann.
Über ihren Verwaltungsbereich können OE-Besitzer festlegen, wie die Verwaltung delegiert wird und wie
Richtlinien auf Objekte angewendet werden. Darüber hinaus können sie neue Teilstrukturen erstellen und die
Verwaltung von Organisationseinheiten delegieren.
Optimale Vorgehensweisen für das OE-Modell
Die optimalen Vorgehensweisen für das OE-Modell sehen vor, dass jede Domäne einen Standardsatz mit
Organisationseinheiten enthält, unabhängig davon, ob die Domäne aktualisiert oder neu erstellt wurde. Jede
dieser Organisationseinheiten delegiert Verwaltungsfunktionen an einen Datenbesitzer.
In Abbildung 28 werden die Elemente des Modells dargestellt. Bedenken Sie, dass dieses Modell nicht mit der
von Ihnen entworfenen OE-Hierarchie übereinstimmen muss, da es zwei mögliche Orte für Ressourcen-OEs
zeigt: unter dem Domänenstamm und unter einer Konten-OE. Ihr Entwurf kann beide oder nur eine dieser
Positionen enthalten. Weitere Informationen finden Sie im Abschnitt "Ressourcen-OEs" weiter unten in diesem
Abschnitt.
Abbildung 28: Überblick über ein auf optimalen Vorgehensweisen basierendes OE-Modell
Standardcontainer und Organisationseinheiten
Mehrere Active Directory-Standardcontainer stehen zur Verfügung, z. B.:
•
•
Container Users und Computers
Domänencontroller-OE
Diese Container sollten der Kontrolle des Domänenbesitzers unterliegen.
Users und Computers (Container)
Wenn Sie ein direktes Update durchführen, werden vorhandene Benutzer und Computer automatisch in die
Container Users und Computers verschoben. Diese Container werden jedoch nicht verwendet. Stattdessen
verschieben Sie Benutzer und Computer in Organisationseinheiten, die den einzelnen Besitzern auf Datenebene
unterstellt sind.
Anmerkung Wenn Sie Ihre Windows NT-Domäne mit älteren Tools, z. B. dem Benutzer-Manager, oder mit
Drittanbietertools verwalten, werden neue Benutzer und Gruppen im Container Users der Active DirectoryDomäne erstellt. Bis Sie Ihre Tools aktualisieren, müssen Sie diese Benutzer manuell in die korrekten
Organisationseinheiten verschieben.
Tritt ein Computer, für den kein Konto existiert, einer Active Directory-Domäne bei, wird im Container
Computers ein Konto für den Computer erstellt. Um dies zu verhindern, erstellen Sie das Computerkonto im
Voraus in der entsprechenden Organisationseinheit.
Bekannte und vordefinierte Konten
Standardmäßig werden in einer neuen Domäne mehrere bekannte und vordefinierte Benutzer und Gruppen
erstellt. Diese Objekte sollten in den Standardcontainern verbleiben und der Kontrolle des Domänenbesitzers
unterstehen. In Tabelle 28 werden diese Benutzer und Gruppen aufgelistet.
Tabelle 28: Liste bekannter Benutzer und Gruppen sowie vordefinierter Konten
Bekannte Benutzer/Gruppen
Vordefinierte Konten
Administrator
Administrator
Gast
Gast
KRBTGT
Internetgastkonto
Domänen-Admins
IIS-Prozesskonto starten
Domänen-Benutzer
Domänen-Gäste
Domänencomputer
Zertifikatherausgeber
Schema-Admins (nur Stammdomäne)
Organisations-Admins (nur Stammdomäne)
Domänencontroller-OE
Auf Objekte, die in den Domänen- oder Domänencontroller-OEs erstellt wurden, werden standardmäßig
Gruppenrichtlinieneinstellungen angewendet. Es wird empfohlen, den Inhalt dieser Container und die
Gruppenrichtlinieneinstellungen nicht zu verändern. Der Domänenbesitzer kann bei Bedarf neue
Gruppenrichtlinieneinstellungen erstellen.
Konten-OEs
Konten-OEs verwalten Identitäten, d. h. sie definieren eine Reihe von Benutzern und Gruppen, denen potenziell
Zugriff auf Ressourcen gewährt werden kann. Sie entsprechen Windows NT-MUDs (Master User Domains).
Das Modell für eine Konten-OE wird in Abbildung 29 dargestellt.
Abbildung 29: Modell für Konten-OE
In Tabelle 29 werden die unter der Konten-OE-Struktur erstellten OEs aufgelistet und beschrieben.
Tabelle 29: Durch die Migration von Benutzern und Computern von Windows NT-MUDs entstandene
OEs
OE
Benutzer
Dienstkonten
Computers
Gruppen
Administratoren
Zweck
Benutzerkonten für Personal, das nicht an der Verwaltung beteiligt ist.
Einige Dienste, die Zugriff auf Netzwerkressourcen benötigen, werden unter
Benutzerkonten ausgeführt. Diese OE wird erstellt, um Dienstbenutzerkonten von anderen
in der Users-OE enthaltenen Benutzerkonten zu trennen und zu unterscheiden. Indem Sie
verschiedene Typen von Benutzerkonten in separaten OEs platzieren, können Sie diese
unterschiedlichen Verwaltungsanforderungen entsprechend verwalten.
Computerkonten mit Ausnahme von Domänencontrollern.
Alle Arten von Gruppen mit Ausnahme von Verwaltungsgruppen, die separat verwaltet
werden.
Benutzer- und Gruppenkonten für Verwaltungspersonal, so dass diese getrennt von
regulären Benutzern verwaltet werden können. Für diese OE sollte die Überwachung
aktiviert werden, so dass Sie Änderungen an Verwaltungsbenutzern und -gruppen
verfolgen können.
Verwaltung der Konten-OE
Abbildung 30 definiert den Verwaltungsgruppenentwurf für eine Konten-OE. Bei allen diesen Gruppen handelt
es sich um lokale Gruppen. Legen Sie einen Besitzer für die Konten-OE fest. In diesem Beispiel lautet der Name
der Gruppe <kto_oe>_OU_admins. Diese Gruppe besitzt Vollzugriff auf die OE und wird einen Standardsatz
von untergeordneten OEs sowie die zu deren Verwaltung erforderlichen Gruppen erstellen.
Gruppen, die die untergeordneten OEs verwalten, wird nur für die von ihnen verwaltete Objektklasse Vollzugriff
gewährt. Beispielsweise hat die Gruppe <kto_oe>_group_admins nur auf Gruppenobjekte Vollzugriff.
Beachten Sie, dass keine eigene Verwaltungsgruppe zur Verwaltung der Administratoren-OE zur Verfügung
steht; auf diese wird der Besitz der übergeordneten OE vererbt, so dass sie von <kto_oe>_OU_admins verwaltet
wird.
Abbildung 30: Verwaltungsgruppen für Konten-OE
Der OE-Besitzer kann bei Bedarf zusätzliche Verwaltungsgruppen erstellen. Beispielsweise kann in der
Administratoren-OE die optionale Gruppe <kto_oe>_helpdesk_admins erstellt werden, die über die
Berechtigung zum Zurücksetzen des Kennwortes verfügt.
Ressourcen-OEs
Ressourcen-OEs werden zur Verwaltung des Zugriffs auf Ressourcen verwendet. Sie entsprechen Windows NTRessourcendomänen. Der OE-Besitzer erstellt Computerkonten, so dass diese eine Verbindung zu Servern mit
Domänenressourcen, z. B. Dateifreigaben, Datenbanken und Druckern, herstellen können. Darüber hinaus
erstellt der Besitzer Gruppen, um den Zugriff auf die Ressourcen zu kontrollieren. Abbildung 31 zeigt zwei
mögliche Positionen für die Ressourcen-OE.
Abbildung 31: Modell für Ressourcen-OE
Das Ressourcen-OE-Modell unterscheidet sich vom Konten-OE-Modell in dreierlei Hinsicht:
•
Position in der OE-Verwaltungshierarchie.
Sind Windows NT-Ressourcendomänen vorhanden, die von separaten IT-Gruppen unabhängig
verwaltet werden, können die neuen OEs auf der höchsten Ebene unter dem Domänenstamm platziert
werden. Wenn ein Windows NT-MUD-Besitzer die ehemaligen Ressourcendomänen besitzt und
verwaltet, kann die Ressourcen-OE als untergeordnete OE der entsprechenden Konten-OE erstellt
werden.
Anmerkung Besitzer von Ressourcendomänen ziehen es möglicherweise vor, dem Windows NTMUD-Besitzer und nicht dem Domänenbesitzer untergeordnet zu werden, um besseren Support zu
erhalten. Kann beispielsweise aufgrund eines Verwaltungsfehlers auf Objekte in der Ressourcen-OE
nicht zugegriffen werden, ist der Ressourcenadministrator auf die Unterstützung eines übergeordneten
Administrators angewiesen. In einer großen Organisation ist wahrscheinlich ein Windows NT-MUDBesitzer in der Nähe, der darüber hinaus nur über einen relativ kleinen Verwaltungsbereich verfügt.
Dagegen befindet sich der Domänenbesitzer möglicherweise in einer anderen Region oder einem
anderen Land und ist für eine große Anzahl an Organisationseinheiten verantwortlich.
•
Einzelner OE-Entwurf.
Ressourcen-OEs verfügen nicht über standardmäßige untergeordnete OEs. Computer und Gruppen
werden direkt in der OE platziert.
•
Der Besitzer der Ressourcen-OE besitzt nur die Objekte innerhalb der OE.
Der Besitzer der Ressourcen-OE ist nicht Besitzer des eigentlichen OE-Containers. Resourcen-OEBesitzer verwalten nur Computer- und Gruppenobjekte; sie können keine anderen Objektklassen in
einer OE erstellen. Auf diese Weise werden Ressourcen-OE-Besitzer ausdrücklich auf die Verwaltung
von Computer- und Gruppenobjekten beschränkt, und es wird verhindert, dass sie untergeordnete OEs
erstellen.
Anmerkung Der Ersteller oder Besitzer eines Objekts kann die Zugriffssteuerungsliste für das Objekt
festlegen, unabhängig davon, welche Berechtigungen vom übergeordneten Container übernommen wurden.
Wenn ein Ressourcen-OE-Benutzer die Zugriffssteuerungsliste für eine OE zurücksetzen kann, kann er im
Wesentlichen jede beliebige Objektklasse in der OE erstellen, z. B. Benutzer. Aus diesem Grund können
Ressourcen-OE-Besitzer keine OEs erstellen.
Abbildung 32 definiert den Verwaltungsgruppenentwurf für eine Ressourcen-OE. Legen Sie für jede
Ressourcen-OE eine Gruppe als Ressourcenbesitzer fest. Diese Gruppe besitzt Vollzugriff auf die Gruppen- und
Computerobjekte in der OE, nicht jedoch auf den eigentlichen OE-Container. Die Gruppe <res_oe>_OU_admin
verwaltet ihre eigene Mitgliedschaft und befindet sich in der Ressourcen-OE.
Abbildung 32: Verwaltungsgruppenentwurf für Ressourcen-OE
Anmerkung In Windows NT besaßen Besitzer von Ressourcendomänen Vollzugriff auf Computer in ihrer
Domäne, da sie automatisch Mitglieder der lokalen Administratorengruppe auf allen Computern in der Domäne
waren. In einer Ressourcen-OE ist der Domänenadministrator der lokale Administrator für alle Computer. Um
Ressourcen-OE-Administratoren Vollzugriff auf Computer in einer OE zu gewähren, verwenden Sie
Gruppenrichtlinien für eingeschränkte Gruppen. Zusätzliche Informationen finden Sie in der weiterführenden
Literatur zu Gruppenrichtlinien.
OE-Entwurfsprozess
Der Domänenbesitzer entwirft die OE-Struktur der Domäne, indem er Konten-OEs und Ressourcen-OEs erstellt.
In Abbildung 33 wird dieser Prozess dargestellt.
Abbildung 33: Flussdiagramm der Aufgaben, die beim OE-Entwurfsprozess durchgeführt werden müssen
Erstellen von Konten-OEs
Ermitteln Sie mithilfe Ihres Domänenentwurfs, ob die Domäne direkt aktualisiert oder neu erstellt wurde und ob
sie Ziel einer MUD-Konsolidierung ist. Führen Sie die folgenden Schritte durch, um Konten-OEs zu erstellen:
1.
Wurde die Domäne direkt aktualisiert, erstellen Sie eine OE für die aktualisierten Konten.
Während der Bereitstellung unterscheiden Sie zwischen Benutzern und Gruppen, die zum
Domänenbesitzer gehören, und regulären Benutzern und Gruppen. Benutzer und Gruppen des
Domänenbesitzers bleiben im Standardcontainer Users. Reguläre Benutzer und Gruppen werden in die
entsprechende Konten-OE verschoben.
2.
Ist die Domäne Ziel einer MUD-Konsolidierung, erstellen Sie eine OE für jede unabhängig verwaltete
Quell-MUD.
Werden mehrere MUDs, die von derselben IT-Gruppe verwaltet werden, in der Domäne konsolidiert,
können Sie Konten aus diesen Domänen in eine einzige Konten-OE migrieren, anstatt mehrere KontenOEs zu verwenden.
3.
Wenn die Domäne neu erstellt wurde und nicht Ziel einer MUD-Konsolidierung ist, erstellen Sie eine
Konten-OE für die Domäne selbst.
Diese Konten-OE ist erforderlich, um den OE-Besitzer (Datenbesitzer) vom Domänenbesitzer
(Dienstbesitzer) zu trennen.
Erstellen von Ressourcen-OEs
Ermitteln Sie mithilfe Ihres Domänenentwurfs, ob die Domäne das Ziel einer Konsolidierung von
Ressourcendomänen ist.
Ist die Domäne das Ziel einer Konsolidierung von Ressourcendomänen, führen Sie die folgenden Schritte durch:
1.
Erstellen Sie eine OE für jede unabhängig verwaltete Quellressourcendomäne.
Werden mehrere Ressourcendomänen, die von derselben IT-Gruppe verwaltet werden, in der Domäne
konsolidiert, können Sie Objekte aus diesen Domänen in eine einzige Ressourcen-OE migrieren, anstatt
mehrere Ressourcen-OEs zu verwenden.
Für Ressourcendomänen, die von Windows NT-MUD-Besitzern verwaltet werden, können Sie Objekte
in die entsprechende Teilstruktur der Konten-OE (in die untergeordneten OEs Computer und Group)
migrieren, anstatt eine separate Ressourcen-OE unter der Konten-OE zu verwenden.
2.
Platzieren Sie die OE unter dem Domänenstamm oder unter einer Konten-OE. Der Besitzer der
Ressourcendomäne wird zum Besitzer der OE.
Ist die Domäne nicht das Ziel einer Konsolidierung von Ressourcendomänen, erstellen Sie Ressourcen-OEs
abhängig von Ihren Verwaltungsanforderungen.
Erstellen einer Standorttopologie
Ein Standort wird definiert als eine Menge sehr gut verbundener (mindestens LAN-Geschwindigkeit) IPSubnetze. Bei der Erstellung einer Standorttopologie identifizieren Sie Bereiche hoher Konnektivität als
Standorte und die WAN-Verbindungen zwischen diesen als Standortverknüpfungen. Nachdem Sie Standorte und
Standortverknüpfungen erstellt haben, erzeugt Active Directory automatisch eine Replikationstopologie
zwischen Domänencontrollern. Indem Sie Standorte Ihrer LAN/WAN-Topologie entsprechend definieren,
erhalten Sie eine Replikationstopologie, die WAN-Verbindungen außer bei der standortübergreifenden
Kommunikation vermeidet.
Funktionen der Standorttopologie in Windows-Netzwerkentwürfen
Active Directory-Standorte sind Ansammlungen von IP-Subnetzen, die ein LAN darstellen und über
Standortverknüpfungen miteinander verbunden sind. In Active Directory erfüllen Standorte folgende Aufgaben:
•
•
Optimieren der Replikation zwischen Domänencontrollern
Suchen nach dem nächsten Domänencontroller für Clientanmeldungen und Verzeichnissuchzugriffe
Replikationssteuerung
Die Standorttopologie steuert die Active Directory-Replikation, indem sie zwischen Replikationen innerhalb
eines Standortes und standortübergreifenden Replikationen unterscheidet und so einen Ausgleich zwischen
Replikationsgeschwindigkeit und Replikationskosten schafft.
Innerhalb von Standorten ist die Replikation vor allem auf Geschwindigkeit ausgerichtet; Datenaktualisierungen
lösen Replikationen aus und werden ohne den zusätzlichen Aufwand einer Datenkomprimierung gesendet.
Dagegen werden Replikationen zwischen Standorten komprimiert, um die Kosten für Übertragungen über
WAN-Verbindungen zu minimieren.
Replikationsweiterleitung
Active Directory verwendet eine Multimaster-, Speicher- und Weiterleitungsmethode bei der Replikation. Ein
Domänencontroller teilt einem zweiten Domänencontroller Verzeichnisänderungen mit, der sie wiederum einem
dritten mitteilt usw., bis alle Domänencontroller die Änderung erhalten haben. Bei Replikationen zwischen
Standorten werden die Verzeichnisänderungen auf einem Domänencontroller pro Domäne gesammelt, dort
gespeichert und zu einem geplanten Zeitpunkt einem Domänencontroller an einem anderen Standort mitgeteilt.
Clientzugehörigkeit
Active Directory-Clients verwenden bei der Suche nach Domänencontrollern das Kriterium der
Standortzugehörigkeit. Ein Client versucht, einen Domänencontroller innerhalb desselben Standortes zu finden.
Auf diese Weise können Kommunikationen über WAN-Verbindungen vermieden werden.
Netzwerktopologien
Die Netzwerktopologie einer Organisation sollte deren Geschäftsanforderungen entsprechen. In einigen
Organisationen erfordern diese, dass Benutzer sich an einigen großen Standorten befinden, die über eine hohe
Konnektivität verfügen. Dagegen sind Benutzer in anderen Organisationen auf zahlreiche kleine
Satellitenstandorte verteilt, die mit einem von mehreren sehr gut verbundenen Hubstandorten verbunden sind.
Solche Netzwerktopologien untergliedern sich in drei Gruppen: ringförmige, sternförmige und komplexe
Topologien. Diese werden in Abbildung 34 dargestellt.
Abbildung 34: Netzwerktopologien
Elemente einer Standorttopologie
Der Gesamtstrukturbesitzer und der Besitzer der Standorttopologie sind für die Erstellung eines
Standorttopologieentwurfs für die Gesamtstruktur verantwortlich. Der Plan muss Folgendes enthalten:
•
•
•
•
Einen Positionsplan mit folgenden Informationen:
o Die Anzahl der Benutzer und Computer an jedem Standort
o Die Geschwindigkeit und Auslastung der WAN-Verbindungen
o Die an jedem Standort verwendeten IP-Adressen
Eine Liste der Standorte mit folgenden Informationen für jeden Standort:
o Den Namen des Standortes
o Die Anzahl der Benutzer und Computer
o Die für diesen Standort relevanten Domänen
o Die Anzahl der Domänencontroller für jede Domäne und deren Hardwareausstattung
o Die Domänencontroller, die globale Kataloge enthalten
Eine Liste der Standortverknüpfungen mit folgenden Informationen für jede Verknüpfung:
o Die über die Verknüpfung miteinander verbundenen Standorte
o Die Kosten für die Verknüpfung
o Die geplante Replikationszeit für die Verknüpfung
o Das Replikationsintervall für die Verknüpfung
Berechnungen der Replikationswartezeiten
Rolle des Standorttopologiebesitzers
Der Standorttopologiebesitzer ist mit dem Zustand des Netzwerkes zwischen den Standorten vertraut und besitzt
die Berechtigung, Einstellungen in Active Directory zu ändern, um Änderungen an der Standorttopologie zu
implementieren. Änderungen an der Standorttopologie wirken sich auf Änderungen an der Replikationstopologie
aus. Einige Verantwortungsbereiche des Besitzers der Standorttopologie werden in Tabelle 30 dargestellt.
Tabelle 30: Verantwortungsbereiche des Besitzers der Standorttopologie
Rolle
Verantwortungsbereich
Durchführen von Änderungen an der Standorttopologie Wenn sich die Netzwerkkonnektivität ändert, nimmt der
Besitzer die entsprechenden Änderungen an der
Standorttopologie vor.
Verschieben von Domänencontrollern zwischen
Wenn sich die IP-Adresse eines Domänencontrollers
Standorten
ändert, so dass er einem anderen Subnetz an einem
anderen Standort angehört, oder wenn das Teilnetz an
einen anderen Standort verschoben wird, müssen Sie
den Domänencontroller manuell an den neuen Standort
verschieben.
Vermitteln zwischen Netzwerkgruppen
Der Besitzer sammelt und verwaltet Informationen zu
Verbindungen und Routern, die sich auf die
Standorttopologie auswirken.
• Der Besitzer ist mit Aspekten der
Netzwerkgeschwindigkeit und -kapazität, die sich auf
die Standorttopologie auswirken, vertraut und kann die
Kosten für die Standortverknüpfungen entsprechend
einschätzen.
• Er verwaltet eine Liste mit Subnetzadressen,
Subnetzmasken sowie den Standorten, den diese
angehören.
Optimale Vorgehensweisen beim Standorttopologieentwurf
Dieses Dokument beschreibt weniger ein Modell als Richtlinien für die Erstellung einer Standorttopologie, die
auf optimalen Vorgehensweisen basieren.
•
•
•
Delegieren Sie die Autorität für die Verwaltung der Standorttopologie an den Standorttopologiebesitzer.
Verwenden Sie bei der standortübergreifenden Replikation möglichst die Standardkonfiguration. D. h.
im Einzelnen:
o Deaktivieren Sie die Konsistenzprüfung (Knowledge Consistency Checker oder KCC) nicht.
o Deaktivieren Sie die Transitivität der Standortverknüpfungen nicht.
o Geben Sie keine Bridgeheadserver an.
o Halten Sie den Replikationsplan so lange wie möglich offen.
Berechnen Sie die erwarteten Replikationswartezeiten zwischen Standorten in Ihrer Topologie.
Weiterführende Informationen zur Replikation finden Sie in Active Directory – Planungshandbuch für
Zweigstellen, online verfügbar unter
http://www.microsoft.com/germany/ms/technetdatenbank/overview.asp?siteid=468904 bzw. in Active Directory
Branch Office Planning Guide unter
http://www.microsoft.com/windows2000/techinfo/planning/activedirectory/branchoffice/default.asp
(englischsprachig).
Im Folgenden werden die optimalen Vorgehensweisen beim Entwerfen von Standortverknüpfungen beschrieben:
•
•
Ordnen Sie Standortverknüpfungen und WAN-Verbindungen einander zu.
Stellen Sie sicher, dass kein Standort mit mehr als 20 anderen Standorten verbunden ist.
Dies kann in großen sternförmigen Bereitstellungen der Fall sein, in denen die meisten Standorte
Zweigstellenstandorte sind, die mit einem zentralen Hubstandort kommunizieren. Ist ein Hubstandort
mit mehr als 20 Zweigstellenstandorten verbunden, kann er in mehrere Standorte unterteilt werden, um
zusätzliche Bridgeheadserver zur Bewältigung des Replikationsaufkommens bereitzustellen. In einem
Standort ist ein Bridgeheadserver pro Domäne aktiv. Verfügt der Standort über mehr als 20
Standortverknüpfungen, kann es zu einer Überlastung der Bridgeheadserver kommen.
Entwurfsprozess für die Standorttopologie
Um eine auf optimalen Vorgehensweisen basierende Topologie zu entwerfen, führen Sie die folgenden
Aufgaben in der angegebenen Reihenfolge durch:
1.
2.
3.
4.
5.
Erstellen eines Positionsplanes
Platzieren von Domänencontrollern an den Positionen
Erstellen von Standorten auf der Grundlage der Positionen
Verbinden der Standorte mithilfe von Standortverknüpfungen
Planen der Domänencontrollerkapazität
Abbildung 35 stellt den Entwurfsprozess für die Standorttopologie dar.
Abbildung 35: Flussdiagramm der Aufgaben, die beim Entwerfen der Standorttopologie durchgeführt
werden müssen
Erstellen eines Positionsplanes
Ein Positionsplan ermittelt, welche Benutzer sich an welchen Positionen befinden und welche Positionen sich am
besten für die Replikation mit welchen anderen Positionen eignen. Es wird empfohlen, die Active DirectoryStandorte den Positionen der LAN-Segmente in Ihrem Netzwerk zuzuordnen. So erstellen Sie einen
Positionsplan:
1.
Erstellen Sie einen Positionsplan, der alle physischen Positionen in Ihrer Gesamtstruktur enthält, die
über Verbindungen mit mindestens LAN-Geschwindigkeit angeschlossen sind.
Als eine physische Position kann eine Gruppe von Benutzern mit einer internen Konnektivität von
mindestens 10 Mbit/s betrachtet werden.
2.
3.
Ermitteln Sie für jede Position die folgenden Informationen:
o Anzahl der Benutzer
o Anzahl der Arbeitsstationen
o Liste der lokalen IP-Subnetze
Fügen Sie dem Plan die WAN-Verbindungen des Netzwerkes hinzu, wobei Sie die folgenden
Informationen angeben:
o WAN-Geschwindigkeit zwischen allen Positionen
o Aktuelle Verwendung der WAN-Verbindung
In Abbildung 36 wird ein Beispiel für einen Positionsplan dargestellt. Jede Position enthält die Anzahl der
Benutzer, die Anzahl der Arbeitsstationen und die IP-Adressen der vorhandenen Subnetze des Netzwerkes. Für
jede Netzwerkverbindung wird die WAN-Geschwindigkeit und der Prozentsatz bzw. die verwendete Bandbreite
angegeben.
Abbildung 36: Ein Positionsplan mit LAN-Segmenten und WAN-Verbindungen
Platzieren von Domänencontrollern an Positionen
Zusammen mit den Domänenbesitzern ermittelt der Besitzer der Standorttopologie die Positionen der
Domänencontroller für die Stammdomäne der Gesamtstruktur und die regionalen Domänen. Durch das
Platzieren der Domänencontroller auf diese Weise, können Benutzer lokal authentifiziert werden, falls die
WAN-Verbindung fehlschlägt.
Beginnen Sie bei der Beurteilung der Positionen mit der Platzierung der Domänencontroller an den
Hubstandorten. Nachdem Sie Domänencontroller an allen Hubstandorten hinzugefügt haben, beurteilen Sie die
Satellitenstandorte. Unter den folgenden Umständen kann es sinnvoll sein, den kleinsten Standorten keine
Domänencontroller hinzuzufügen:
•
•
Ein Domänencontroller lohnt sich nicht, wenn der Standort über zu wenige Benutzer und
Arbeitsstationen verfügt.
Die physische Sicherheit des Domänencontrollers kann nicht garantiert werden.
In Abbildung 37 ist ein Standortplan mit allen Domänen dargestellt, die für den jeweiligen Standort relevant
sind.
Abbildung 37: Domänen an verschiedenen Standorten
Platzieren von Domänencontrollern in der Stammdomäne der Gesamtstruktur
Platzieren Sie für jeden Hubstandort einen Domänencontroller in der Stammdomäne der Gesamtstruktur.
Überlegen Sie für jeden Satellitenstandort, ob ein Domänencontroller im Gesamtstrukturstamm erforderlich ist.
Denken Sie daran, dass eine Verbindung mit dem Domänencontroller im Gesamtstrukturstamm vorhanden sein
muss, damit ein Client auf eine Ressource außerhalb seiner eigenen Domäne zugreifen kann. Aus diesem Grund
sollte ein Standort, der Domänencontroller von zwei oder mehr regionalen Domänen enthält, auch über einen
Domänencontroller in der Stammdomäne der Gesamtstruktur verfügen.
Platzieren regionaler Domänencontroller
Platzieren Sie einen Domänencontroller für regionale Domänen an einem Standort, wenn sichergestellt werden
soll, dass sich die Benutzer dieses Standortes auch dann anmelden können, wenn die WAN-Verbindung nicht zur
Verfügung steht. Versagt der lokale Domänencontroller, können sich die Benutzer an diesem Standort über das
WAN anmelden. Um die Anmeldungsleistung im Falle eines Versagens des Domänencontrollers zu verbessern,
können Sie einen zweiten Domänencontroller hinzufügen.
Platzieren primärer Domänencontroller (Primary Domain Controller oder PDC)
Jede Domäne verfügt über einen Betriebsmaster für die PDC-Emulation. Platzieren Sie den PDC an einem
Standort, für den Folgendes gilt:
•
•
Gute Verbindungen zu anderen Standorten.
Enthält eine große Anzahl an Benutzern aus dieser Domäne.
Der Standort, an dem der PDC platziert wird, ist der primäre Standort für diese Domäne.
Platzieren globaler Katalogserver
Ein globaler Katalogserver ist für die Anmeldung an Active Directory-Domänen im einheitlichen Modus
erforderlich. Sie sollten mindestens einen Domänencontroller pro Standort als globalen Katalog bestimmen, um
zu verhindern, dass für Anmeldungen und für gesamtstrukturweite Suchvorgänge eine Verbindung zu einem
globalen Katalogserver hergestellt werden muss.
Es wird empfohlen, dass die Hälfte aller Domänencontroller des Standortes globale Kataloge enthalten, wobei
mindestens zwei globale Kataloge zur Verfügung stehen sollten, wenn der Standort mehrere Domänencontroller
enthält. Wenn Sie ein Modell mit einer einzigen globalen Domäne verwenden, sollten alle Domänencontroller
für die globale Domäne zugleich globale Katalogserver sein. Da die Stammdomäne der Gesamtstruktur sehr
klein ist, sind nur wenige zusätzliche Ressourcen erforderlich, um alle Domänencontroller zu globalen
Katalogservern zu machen.
Erstellen von Standorten auf der Grundlage der Positionen
Jede Position, die einen Domänencontroller enthält, stellt einen Standort dar. So erstellen Sie einen Standort:
1.
2.
Geben Sie dem Standort einen Namen.
Geben Sie die dem Standort zugewiesene IP-Adresse an.
Positionen, die keine Domänencontroller enthalten, sollten nicht als Standorte definiert werden. Ordnen
Sie die Subnetze dieser Positionen stattdessen den Standorten zu, an denen diese Benutzer
authentifiziert werden sollen.
Verbinden von Standorten mit Standortverknüpfungen
Standortübergreifende Replikationen werden entsprechend den Einstellungen für die
Standortverknüpfungsobjekte durchgeführt, die Standortadministratoren in Active Directory erstellen. Jedes
Standortverknüpfungsobjekt repräsentiert die WAN-Verbindung zwischen zwei oder mehr Standorten.
Führen Sie die folgenden Schritte durch, um die Replikation zwischen Standorten zu steuern:
1.
2.
3.
Verbinden Sie die Standorte durch Standortverknüpfungen, die den Verbindungen zwischen den
Positionen entsprechen.
Benennen Sie die Standortverknüpfungen nach dem Muster <Name_von_Standort1><Name_von_Standort2>.
Legen Sie Parameter für die Standortverknüpfungen fest:
o Kosten
o Zeitplan
o Intervall
Anmerkung Weisen mehrere Standorte dieselbe Konnektivität und Verfügbarkeit auf, können Sie diese über
dieselbe Standortverknüpfung verbinden.
Abbildung 38 zeigt einen Standortplan mit Standortverknüpfungen und WAN-Geschwindigkeiten.
Abbildung 38: Netzwerkplan mit Standortverknüpfungen und WAN-Geschwindigkeiten
Festlegen der Kosten
Um die Kosten für Standortverknüpfungen zu ermitteln, führen Sie die folgenden Aufgaben durch:
1.
2.
3.
Prüfen Sie die Geschwindigkeit der Verknüpfung.
Erstellen Sie eine Tabelle, die die Verbindungsgeschwindigkeit für jede Standortverknüpfung enthält.
Berechnen Sie die Kosten für jede Standortverknüpfung anhand von Tabelle 31.
Um einen relativen Kostenfaktor für Standortverknüpfungen zu berechnen, der der verfügbaren
Bandbreite entspricht, verwenden Sie die folgende Formel:
Tabelle 31: Veranschlagen der Kosten für Standortverknüpfungen auf der Grundlage von WANGeschwindigkeiten
Verfügbare Bandbreite (Kbit/s) Kosten
9,6
1042
19,2
798
38,4
644
56
586
64
567
128
486
256
425
512
378
1024
340
2048
309
4096
283
Diese Kosten reflektieren nicht die Unterschiede bei der Zuverlässigkeit zwischen Netzwerkverknüpfungen.
Wenn einige Verknüpfungen weniger zuverlässig sind als andere, sollten Sie sich bei der Replikation nicht auf
diese Verknüpfungen verlassen. Veranschlagen Sie für fehleranfällige Netzwerkverbindungen höhere Kosten.
Fällt eine Standortverknüpfung aus, kann das Replikationsfailover durch Festlegen der Kosten für die
Standortverknüpfung vorhergesagt und gesteuert werden. In Abbildung 38 wird dargestellt, wie die relativen
Kosten für die Verknüpfung von zwei Standorten in der Topologie mithilfe der Standortverknüpfungskosten
aufgezeigt werden können.
Abbildung 39: Standortplan mit Verknüpfungskosten
Festlegen des Zeitplanes
Der Besitzer der Standorttopologie ermittelt, wann Standortverknüpfungen für die Replikation zur Verfügung
stehen, indem er einen geplanten Replikationszeitraum festlegt. Ein Replikationszyklus, der vor Ende des
Zeitplanes beginnt, wird jedoch vollständig ausgeführt, selbst wenn das Ende des geplanten
Replikationszeitraums erreicht ist.
Steuern Sie die Verfügbarkeit der Standortverknüpfung, indem Sie einen Zeitplan für Standortverknüpfungen
festlegen. Sie können den Standardzeitplan (100 % Verfügbarkeit) für die meisten Verknüpfungen verwenden,
aber den Replikationsverkehr zu bestimmten Remotestandorten während Spitzenzeiten sperren. Durch
Replikationssperren geben Sie anderem Verkehr Priorität, aber Sie verlängern möglicherweise auch die
Replikationswartezeiten.
Wenn die Replikation zwischen zwei Standorten mehrere Standortverknüpfungen durchläuft, ermitteln die
Überschneidungen der Replikationszeitpläne für alle relevanten Verknüpfungen den Verbindungszeitplan
zwischen den beiden Standorten. Außerdem kann die Replikation nicht stattfinden, wenn es zwischen den
Zeitplänen für die Verknüpfungen keine Überschneidungen gibt.
Festlegen des Intervalls
Innerhalb des geplanten Replikationszeitraums ermittelt das Intervall, wie oft Domänencontroller
Replikationspartner auf Änderungen abfragen.
Ermitteln Sie für jeden Zeitraum, der für die Replikation zur Verfügung steht, das Zeitintervall, das die Anzahl
der Replikationen innerhalb dieses Zeitraums angibt. Berücksichtigen Sie hierbei die folgenden Kriterien:
•
•
Ein kurzes Intervall reduziert Wartezeiten, erhöht jedoch das WAN-Verkehrsvolumen.
Damit die Verzeichnispartitionen der Domäne stets auf dem neuesten Stand sind, werden kurze
Wartezeiten empfohlen.
Berechnen der maximalen Wartezeiten
Mit einer Speicher- und Weiterleitungs-Replikationsstrategie ist es nicht leicht zu ermitteln, wie lange die
Replikation einer Verzeichnisaktualisierung auf jedem Domänencontroller in Anspruch nimmt. Um eine
konservative Schätzung der maximalen Wartezeiten vorzunehmen, führen Sie die folgenden Aufgaben durch:
1.
Erstellen Sie eine Tabelle mit allen Hubstandorten in Ihrem Netzwerk. Ihre Tabelle sollte Tabelle 32
ähneln.
Tabelle 32: Wartezeiten bei der Replikation zwischen Hubstandorten
Seattle
Seattle
0.25
Boston
Vancouver
Mailand
2.
3.
Boston
Vancouver Mailand
0,25
0,25
0,25
Die durchschnittliche maximale Wartezeit innerhalb eines Standortes wird auf 15 Minuten geschätzt.
Ermitteln Sie anhand des Replikationszeitplanes die maximale Replikationswartezeit für eine beliebige
Standortverknüpfung zwischen zwei Hubstandorten.
Nimmt beispielsweise die Replikation zwischen Seattle und Boston täglich eine Stunde in Anspruch,
dann beträgt die maximale Verzögerung für die Replikation zwischen diesen Standorten 23 Stunden. Ist
die Replikationsverzögerung zwischen Boston und Seattle die längste geplante Verzögerung zwischen
allen Hubstandorten, beträgt die maximale Verzögerung zwischen allen Hubs 23 Stunden.
4.
Erstellen Sie für jeden Hubstandort eine Tabelle mit den maximalen Wartezeiten zwischen dem
Hubstandort und jedem seiner Satellitenstandorte.
Wenn die Replikation zwischen Boston und Bar Harbor beispielsweise alle vier Stunden stattfindet und
dies die längste Replikationsverzögerung zwischen Boston und einem seiner Satellitenstandorte ist,
dann beträgt die maximale Wartezeit zwischen dem Hub Boston und seinen Satelliten vier Stunden.
5.
Kombinieren Sie diese maximalen Wartezeiten, um die maximale Wartezeit für das gesamte Netzwerk
zu ermitteln.
Ist die maximale Wartezeit zwischen Mailand und seinem Satellitenstandort Sevilla z. B. ein Tag, dann
beträgt die maximale Replikationswartezeit für diesen Satz von Verknüpfungen 52 Stunden (4 + 24 +
24).
Überprüfen Sie die maximalen Replikationswartezeiten, und ändern Sie ggf. den Replikationszeitplan.
Kapazitätsplanung für Domänencontroller
Die folgenden Operationen erhöhen die Auslastung von Domänencontrollern:
•
•
•
•
•
Anmeldungen von Benutzern und Arbeitsstationen
Verzeichnissuchvorgänge
Replikation
Betriebsmaster
Andere auf dem Domänencontroller ausgeführte Dienste
Anmeldungen von Benutzern und Arbeitsstationen gefolgt von Verzeichnissuchvorgängen wirken sich am
stärksten auf die Leistung des Domänencontrollers aus.
Von der Größe der Domäne lässt sich im Allgemeinen nicht auf die Leistung der Domänencontroller schließen.
Dagegen geben Verwendungsmuster sowie die Anzahl der Benutzeranmeldungen an einem Domänencontroller
einer bestimmten Domäne Aufschluss über die Leistung eines Domänencontrollers. In Tabelle 33 wird
dargestellt, wie Dienste sich auf die Leistung eines Domänencontrollers auswirken.
Tabelle 33: Auswirkung von Diensten auf die Leistung eines Domänencontrollers
Operation
Anmeldung von Benutzern
Dienst
Auswirkung auf die Leistung
Hoch
Interaktive Anmeldung von
Benutzern, Netzwerkanmeldung von
Benutzern, Batchanmeldung von
Benutzern
Anmeldung von Arbeitsstationen
Startvorgänge von Arbeitsstationen Mittel
Suchvorgänge
Suchvorgänge, LDAPAbhängig von der Verwendung
Suchvorgänge
Replikation mit 1 bis 10 Partnern
Active Directory-Replikation
Gering – Mittel
Replikation mit mehr als 10 Partnern Active Directory-Replikation
Hoch
Hoch
PDC-Betriebsmaster
Weiterleitung von
Kennwortänderungen, Weiterleitung
von Anmeldungen
Infrastruktur-Betriebsmaster
Validierung von Verknüpfungen mit Gering
verschobenen Objekten
RID-Pool-Betriebsmaster
Verteilung von RID-Pools auf
Gering
Domänencontroller in dieser
Domäne
Konsistenzprüfung für weniger als Berechnen der
Gering – Mittel
200 Standorte
Replikationstopologie
Konsistenzprüfung für mehr als 200 Berechnen der
Hoch
Standorte
Replikationstopologie
Globaler Katalogdienst
Suchvorgänge nach der
Gering – Hoch (mit Exchange 2000)
Mitgliedschaft einer universellen
Gruppe, gesamtstrukturweite
Suchvorgänge
Infrastrukturdienste
DNS, WINS, DHCP
Mittel
Andere Dienste
Datei- und Druckdienste,
Abhängig von der Verwendung
Datenbankoperationen
Prozessoranforderungen
In Tabelle 34 wird die Größe von Domänencontrollern und Diensten angegeben, die geladen werden können:
Tabelle 34: Kapazitätsplanung für Domänencontroller
Standortbenutzer
< 100
101 – 500
500 – 1.000
1.000 – 10.000
> 10.000 Benutzer
Domänencontroller Globaler Katalog
Ein Uniprozessor
Domänencontroller
PIII 500, 512 MB
ist ein globaler
Katalog.
Ein Uniprozessor
Domänencontroller
PIII 500, 512 MB
ist ein globaler
Katalog.
Ein PIII 500 mit
Domänencontroller
zwei Prozessoren,
ist ein globaler
1 GB
Katalog.
Zwei PIII XEON mit Beide
vier Prozessoren,
Domänencontroller
2 GB
sind globale
Kataloge.
Ein PIII XEON mit Ein globaler Katalog
für je zwei
vier Prozessoren,
Domänencontroller,
2 GB für jeweils
wobei mindestens
5.000 Benutzer
zwei globale
Kataloge
bereitgestellt
werden.
Dedizierter DC?
Nein
Server/Advanced Server
Server
Ja
Server
Ja
Server
Ja
Advanced Server
Ja
Advanced Server
Anmerkung Die auf optimalen Vorgehensweisen basierenden Richtlinien sehen folgende Hardware für
Domänencontroller vor:
•
•
•
•
Verwenden Sie Multiprozessorhardware für 100 bis 200 Standorte.
Bei mehr als 200 Standorten sollten Sie die Dokumentation für Zweigstellen zu Rate ziehen.
Verwenden Sie Multiprozessorhardware für Standorte, die mit 10 oder mehr Standorten verbunden
sind.
Verwenden Sie einen PIII XEON mit vier Prozessoren und 2 GB Arbeitsspeicher für den dedizierten
PDC.
Diese Tabelle bietet einen Anhaltspunkt für die Dimensionierung von Domänencontrollern. Ihre tatsächlichen
Hardwareanforderungen hängen jedoch von den Verwendungsmustern ab. Wenn Sie genauere Angaben zur
Hardwaredimensionierung benötigen oder Exchange 2000 in Ihrer Bereitstellung verwenden, führen Sie die
folgenden Schritte durch:
1.
Downloaden Sie ADSizer, und führen Sie das Programm aus.
Sie können ADSizer unter der folgenden Adresse downloaden:
http://www.microsoft.com/windows2000/downloads/tools/sizer/default.asp (englischsprachig).
2.
Testen Sie das Hardwaresetup vor der Bereitstellung in einer Laborumgebung.
Anforderungen für den Festplattenspeicher
Domänencontroller und globale Kataloge verwenden häufig einen Großteil des Datenspeichers für die Active
Directory-Datenbank. Anhand von Tabelle 35 können Sie ermitteln, wie viel Speicherplatz für die Active
Directory-Datenbank bereitgestellt werden muss.
Tabelle 35: Speicheranforderungen für die Active Directory-Datenbank
Server
Domänencontroller
Globaler Katalogserver
Für Active Directory-Datenbank erforderlicher Speicher
0,4 GB Speicherplatz für je 1.000 Benutzer.
Beispielsweise sind in einer Gesamtstruktur mit zwei Domänen, die jeweils 10.000 Benutzer enthalten, auf allen
Domänencontrollern 4 GB Speicherplatz erforderlich. Für alle globalen Kataloge sind 6 GB Speicherplatz
erforderlich.
Die Anforderungen stellen konservative Schätzwerte dar. Um die Speicheranforderungen genauer zu
bestimmten, downloaden Sie ADSizer, und führen Sie das Programm aus. Es ist unter der folgenden Adresse
erhältlich: http://www.microsoft.com/windows2000/downloads/tools/sizer/default.asp (englischsprachig).
Anforderungen für das Festplattenlayout
Ein Domänencontroller benötigt Platz auf Speichergeräten für das Betriebssystem, die Protokolldateien, die
Datenbank und SYSVOL. Auf Domänencontrollern an Standorten mit unter 10.000 Benutzern können sich alle
vier Komponenten auf einem einzigen RAID 1-Array befinden. Ein RAID 1-Array bietet Schutz vor Ausfall der
einzigen Festplatte.
Wenn Sie nach einer Weile feststellen, dass ein Domänencontroller E/A-gebunden ist, können Sie die
Computerleistung verbessern, indem Sie zusätzlichen Arbeitsspeicher (bis zu 2 GB) hinzufügen. Auf diese
Weise müssen das Betriebssystem, die Datenbank oder die Protokolldateien nicht auf separate RAID 1-Systeme
verschoben werden.
Für Domänencontroller an Standorten mit über 10.000 Benutzern sollten Sie separate RAID-Arrays verwenden,
wie in Tabelle 36 angegeben.
Tabelle 36: Planung der Festplattenkapazität für Domänencontroller
Komponente des
Verzeichnisdienstes
Betriebssystem
Protokolldateien
Datenbank und SYSVOL
Durchgeführte Operationen
RAID-System
Lese- und Schreiboperationen
Überwiegend Schreiboperationen
Überwiegend Leseoperationen
RAID 1
RAID 1
RAID 1 oder RAID 0+1
Implementierung des Entwurfs
Nachdem Sie alle Aufgaben des Entwurfsprozesses durchgeführt haben, können Sie den Entwurf
implementieren, indem Sie ihn in einer Testumgebung testen und dann ein Rollout in der Produktionsumgebung
durchführen. Das Begleithandbuch Best Practice Active Directory Deployment for NOS Environments
(englischsprachig) unterstützt Sie bei der Implementierung.
Teil III: Tabellenblätter
Tabellenblätter zur Anzahl der Gesamtstrukturen in Ihrer Organisation
Nach Abschluss sämtlicher Aufgaben des Entwurfsprozesses können Sie den Entwurf implementieren, indem
Sie ihn in einer Labor- und Pilotumgebung testen und dann ein Rollout in der Produktionsumgebung
durchführen. Das Begleithandbuch Best Practice Active Directory Deployment for Managing Windows Networks
(englischsprachig) unterstützt Sie bei der Implementierung.
Die folgenden Tabellenblätter entsprechen den Überschriften in diesem Handbuch. Die Tabellenblätter wurden
entwickelt, um Sie beim Sammeln und Organisieren von Informationen, die zur Anpassung der Active
Directory-Bereitstellung in Ihrer Organisation erforderlich sind, zu unterstützen.
Während Sie dieses Dokument lesen und Planungssitzungen durchführen, sollten Sie die entsprechenden
Tabellenblätter ausfüllen. Die gesammelten Tabellenblätter stellen einen wichtigen Bestandteil des Active
Directory-Bereitstellungsprojekts in Ihrer Organisation dar.
Tabellenblatt: Entwurfsteam für die Anzahl der Gesamtstrukturen
Das Tabellenblatt enthält die Mitglieder des Komitees, das damit beauftragt wurde, die Anzahl der Active
Directory-Gesamtstrukturen zu ermitteln, die Ihre Organisation entwirft und bereitstellt.
Tabellenblatt: Potenzielle Verzeichnisdienstanbieter
Die folgenden Abteilungen wurden als mögliche Verzeichnisdienstanbieter identifiziert und haben an einer
Reihe von Diskussionen zum Active Directory-Gesamtstrukturentwurf teilgenommen.
Listen Sie jede Organisation auf, die einen potenziellen Verzeichnisdienstanbieter darstellt, und geben Sie den
Namen der Kontaktperson oder des Mitarbeiters an, der die Organisation repräsentiert. Wird Active Directory in
der Organisation bereitgestellt, geben Sie den Namen der bestehenden Gesamtstruktur an.
Tabellenblatt: Begründung des Gesamtstrukturentwurfs
Das folgende Tabellenblatt enthält die Begründung für jede potenzielle Gesamtstruktur, die im vorherigen
Tabellenblatt identifiziert wurde. Erstellen Sie ein Tabellenblatt für jede potenzielle Gesamtstruktur in Ihrer
Organisation.
Tabellenblatt: Geplante Gesamtstrukturen
Das folgende Tabellenblatt enthält eine Liste der Gesamtstrukturen, die für Ihre Organisation geplant sind.
Tabellenblätter zum Entwurf der Active DirectoryGesamtstruktur
Füllen Sie für jede Gesamtstruktur, die Sie in den Tabellenblättern zur Anzahl der Gesamtstrukturen identifiziert
haben, einen Satz der übrigen Tabellenblätter aus. Leiten Sie für jede aufgelistete Gesamtstruktur eine Kopie
dieses Dokuments an die Kontaktperson für die jeweilige Gesamtstruktur weiter. Die entsprechende
Kontaktperson sollte dann die übrigen Tabellenblätter in diesem Handbuch ausfüllen, um den endgültigen Active
Directory-Entwurf für die betreffende Gesamtstruktur zu erstellen.
Tabellenblatt: Entwurfsteam für die Gesamtstruktur
In den folgenden Tabellenblättern werden die Mitglieder des Planungsteams und die Technologiebesitzer
aufgelistet, die für den Entwurf der Active Directory-Domäne in Ihrer Gesamtstruktur verantwortlich sind.
Tabellenblatt: Verwaltung der Stammdomäne der Gesamtstruktur
Das folgende Tabellenblatt identifiziert Administratoren für die Stammdomäne Ihrer Gesamtstruktur.
Tabellenblatt: Entwurf der Stammdomäne der Gesamtstruktur
Das folgende Tabellenblatt enthält den Entwurf der Stammdomäne Ihrer Gesamtstruktur.
Tabellenblatt: Identifizieren von Regionen
Das folgende Tabellenblatt identifiziert die Regionen in Ihrer Gesamtstruktur.
Tabellenblatt: Geplanter Domänenentwurf
Das folgende Tabellenblatt identifiziert das Domänenmodell für Ihre Gesamtstruktur.
Tabellenblatt: Bestandsaufnahme der Windows NT-MUDs (Master User
Domains)
Das folgende Tabellenblatt identifiziert vorhandene Windows NT-MUDs in Ihrer Gesamtstruktur.
Tabellenblatt: Informationen zur Master User Domain
Füllen Sie für jede Zeile des vorherigen Tabellenblattes eine Kopie des folgenden Tabellenblattes aus, in dem
Sie Ihre Migrationsstrategie im Detail darstellen und begründen.
Tabellenblatt: Zuordnung von Windows NT-Ressourcendomänen
Identifizieren Sie jede vorhandene Ressourcendomäne in Ihrer Gesamtstruktur, indem Sie das folgende
Tabellenblatt ausfüllen.
Tabellenblatt: Bestandsaufnahme eines vorhandenen DNS-Dienstes
Ist bereits ein DNS-Dienst in Ihrer Gesamtstruktur vorhanden, füllen Sie alle Tabellenblätter in diesem Abschnitt
aus. Falls Sie nicht über einen DNS-Dienst verfügen, können Sie die Tabellenblätter zur Bestandsaufnahme in
diesem Abschnitt ignorieren und löschen.
Tabellenblatt: Informationen zu DNS-Clients
Beantworten Sie die folgenden Fragen, um den DNS-Clientcomputer in Ihrer Gesamtstruktur zu beschreiben.
Das Tabellenblatt enthält eine Bestandsaufnahme der DNS-Clients in Ihrer Gesamtstruktur.
DNS-Clientkonfiguration
Erstellen Sie ein Diagramm, das Ihrem Clientmodell entspricht.
Tabellenblatt: DNS-Serverentwurf
Erstellen Sie ein Diagramm, das Ihrem DNS-Modell für Active Directory entspricht (DNS mit Hinweisen auf
den Stammserver, DNS mit Weiterleitung und/oder integrierte DNS/DHCP-Lösung).
Tabellenblatt: Entwurfsteam für Organisationseinheiten
Das folgende Tabellenblatt identifiziert die Mitglieder des OE-Entwurfsteams für Ihre Domäne.
Tabellenblatt: Identifizieren von Organisationseinheiten für jede Domäne
Das folgende Tabellenblatt identifiziert das Domänenmodell für Ihre Gesamtstruktur. Füllen Sie das folgende
Tabellenblatt für jede Domäne aus, wobei Sie die Organisationseinheiten in jeder Domäne auflisten.
Tabellenblatt: Entwurfsteam für die Standorttopologie
Das folgende Tabellenblatt identifiziert die Mitglieder des Entwurfsteams für die Standorttopologie.
Tabellenblatt: Geographische Positionen und
Kommunikationsverknüpfungen
Fassen Sie die Positionen und Verknüpfungen Ihrer Organisation in einem Plan zusammen, der auf
geographischen oder organisatorischen Kriterien basiert. Geben Sie die Anzahl der Benutzer an jedem Standort
sowie die Geschwindigkeit der Verknüpfung an.
Tabellenblatt: Geographische Positionen und Verknüpfungen
Dieses Tabellenblatt identifiziert jeden Standort sowie die direkt mit diesem Standort verbundenen Standorte,
den Verbindungstyp und die verfügbare Netzwerkkapazität (die nach anderem Netzwerkverkehr zur Verfügung
steht).
Tabellenblatt: Platzieren von Domänencontrollern
Auf den folgenden Tabellenblättern wird die vorhandene und geplante Platzierung von Domänencontrollern in
der Gesamtstruktur beschrieben. Listen Sie in der Spalte für den Namen des Standortes die geographischen
Positionen auf. Geben Sie dann für jede Position die Namen der Domänen an diesem Standort, die Anzahl der
Benutzer, die Domänencontroller und die als Domänencontroller verwendeten globalen Kataloge an diesem
Standort an.
Tabellenblatt: Zuordnen von Standorten zu Positionen und Subnetzen
Das folgende Tabellenblatt ordnet Standorte ihren Positionen und Subnetzen zu.
Tabellenblatt: Parameter für die Standortverknüpfungen
Auf dem folgenden Tabellenblatt werden die mit Standortverknüpfungen verbundenen Kosten, der Zeitplan und
das Replikationsintervall beschrieben.
Haftungsausschluss für die Betaversion
Bei diesem Dokument handelt es sich um die Betaversion der endgültigen Dokumentation, die bis zur
endgültigen Handelsausgabe wesentlichen Änderungen unterliegen kann. Sie enthält vertrauliche und proprietäre
Informationen von Microsoft. Diese werden gemäß einer Nichtverbreitungs-Vereinbarung zwischen dem
Empfänger und Microsoft bereitgestellt. Dieses Dokument dient nur zu Informationszwecken. Microsoft schließt
für dieses Dokument jede Gewährleistung aus, sei sie ausdrücklich oder konkludent. Die Informationen in
diesem Dokument, einschließlich URLs und Verweise auf Internetwebsites, können ohne vorherige
Ankündigung geändert werden. Das vollständige Risiko der Nutzung oder der Ergebnisse der Nutzung dieses
Dokumentes liegt bei dem Nutzer. Die in den Beispielen verwendeten Firmen, Organisationen, Produkte,
Personen und Ereignisse sind frei erfunden, sofern nichts anderes angegeben ist. Jede Ähnlichkeit mit
tatsächlichen Firmen, Organisationen, Produkten, Personen oder Ereignissen ist rein zufällig. Die Benutzer/innen
sind verpflichtet, sich an alle anwendbaren Urheberrechtsgesetze zu halten. Unabhängig von der Anwendbarkeit
der entsprechenden Urheberrechtsgesetze darf ohne ausdrückliche schriftliche Erlaubnis der Microsoft
Corporation kein Teil dieses Dokuments für irgendwelche Zwecke vervielfältigt oder in einem
Datenempfangssystem gespeichert oder darin eingelesen werden, unabhängig davon, auf welche Art und Weise
oder mit welchen Mitteln (elektronisch, mechanisch, durch Fotokopieren, Aufzeichnen usw.) dies geschieht.
Es ist möglich, dass Microsoft Rechte an Patenten bzw. angemeldeten Patenten, an Marken, Urheberrechten oder
sonstigem geistigen Eigentum besitzt, die sich auf den fachlichen Inhalt dieses Dokuments beziehen. Das
Bereitstellen dieses Dokuments gibt Ihnen jedoch keinen Anspruch auf diese Patente, Marken, Urheberrechte
oder auf sonstiges geistiges Eigentum, es sei denn, dies wird ausdrücklich in den schriftlichen Lizenzverträgen
von Microsoft eingeräumt.
Nicht veröffentlichte Dokumente. 2001 Microsoft Corporation. Alle Rechte vorbehalten.
Active Accessibility, Active Channel, Active Client, Active Desktop, Active Directory, ActiveMovie, ActiveX,
Authenticode, BackOffice, Direct3D, DirectAnimation, DirectDraw, DirectInput, DirectMusic, DirectPlay,
DirectShow, DirectSound, DirectX, DoubleSpace, DriveSpace, FrontPage, IntelliMirror, IntelliMouse,
IntelliSense, JScript, Links, Microsoft, Microsoft Press, Microsoft QuickBasic, MSDN, MS-DOS, MSN,
Natural, NetMeeting, NetShow, OpenType, Outlook, PowerPoint, SideWinder, Slate, TrueImage, Verdana,
Visual Basic, Visual C++, Visual FoxPro, Visual InterDev, Visual J++, Visual Studio, WebBot, Win32,
Windows, Windows Media, Windows NT sind entweder eingetragene Marken oder Marken der Microsoft
Corporation in den USA und/oder anderen Ländern.
Weitere in diesem Dokument aufgeführte tatsächliche Produkt- und Firmennamen können geschützte Marken
ihrer jeweiligen Inhaber sein.