Windows-Verwaltung

Eine Anleitung zur Active Directory-Replikation

Laura E. Hunter

 

Kurz zusammengefasst:

• Der Übergang zu Active Directory
• Wahren der Konsistenz
• Handhabung der Konfliktauflösung
• Änderungen in Windows Server 2008

Vor der Einführung von Windows 2000 Server und Active Directory wurde in vielen Unternehmensumgebungen Windows NT für die Serverinfrastruktur und die Identitäts- und

Zugriffsverwaltung verwendet. Mit dem Rollout von Windows NT® 4.0 wurde um robustes Angebot im Bereich des Netzwerkbetriebssystems (Network Operating System, NOS) bereitgestellt, aber es gab eine Reihe von Nachteilen, die die Bereitstellung in Großunternehmen erschwerten.

Zum einen verwendete Windows NT einen flachen Namespace zum Speichern von Netzwerkressourcen, sodass es keine gute Möglichkeit zum Aufteilen von Ressourcen in kleinere Untermengen oder zum Konfigurieren einer genauen Verwaltung gab. So konnten Sie beispielsweise keinen Abteilungscontainer für die Ressourcen in Ihrer Marketingabteilung und keinen lokalen Administrator konfigurieren, der über Rechte zum Zurücksetzen von Kennwörtern für die Benutzer nur innerhalb dieser Abteilung verfügte. Dadurch ging es bei der Windows NT-Sicherheit praktisch um alles oder nichts. Wenn administrative Aufgaben an einen Desktopsupporttechniker delegiert werden sollten, waren Sie oft gezwungen, weitaus mehr Berechtigungen zu gewähren, als dies normalerweise der Fall wäre.

Außerdem wurden in Windows NT alle Informationen in einer Datenbank zur Sicherheitskontenverwaltung (Security Account Manager, SAM) gespeichert, die nicht über 40 MB Größe hinauswachsen sollte. Wenn die SAM-Datenbank dieses empfohlene Maximum überstieg (dies geschah abhängig von der Konfiguration bei 25.000–40.000 Objekten), mussten die Umgebung in mehrere separate Domänen aufgeteilt werden, was sowohl die Verwaltung des Netzwerks als auch das Bereitstellen von Ressourcenzugriff für die Benutzer erschwerte. Jede NT-Domäne enthielt einen einzelnen primären Domänencontroller (Primary Domain Controller, PDC), der die einzige Lese-/Schreibkopie der SAM-Datenbank enthielt. Obwohl es möglich war, einen oder mehrere Sicherungsdomänencontroller (Backup Domain Controllers, BDCs) für die Fehlertoleranz bereitzustellen, waren diese BDCs schreibgeschützt und konnten keine Updates, beispielsweise die Änderung eines Benutzerkennworts durchführen, für die ein Schreibvorgang erforderlich war.

Schließlich stützte sich Windows NT auf die NetBIOS-Namensauflösung, die broadcastbasiert war und oft viel Datenverkehr generierte, wenn die Benutzer nach Netzwerkressourcen suchten, besonders, wenn dies über einen langsamen oder stark verwendeten WAN-Link erfolgte.

Ein neues Modell

Im Jahr 2000 wurde Windows® 2000 mit einer wesentlichen Überholung des vorherigen NOS-Angebots veröffentlicht. Der neue NOS-Dienst, Active Directory®, war im Vergleich zu Windows NT etwas völlig anderes. Statt auf einen flachen Namespace angewiesen zu sein, wurde Active Directory auf dem X.500-Standard entwickelt, der eine hierarchische Organisationsstruktur erstellte. Jetzt konnten Ressourcen in mehreren Organisationseinheiten innerhalb einer einzelnen Domäne organisiert und die Verwaltung der einzelnen Organisationseinheiten auf einer aufgabenbasierten Ebene delegiert werden.

Ein anderer wichtiger Unterschied gegenüber Windows NT war das neue Modell der Multimasterreplikation. Es gab keinen einzelnen beschreibbaren PDC und die dazugehörigen BDCs mehr. In Active Directory konnte jeder Domänencontroller in die Active Directory-Datenbank schreiben.

Doch obwohl dies zu sehr viel mehr Flexibilität beim Unterstützen einer großen bzw. dezentralisierten Umgebung führte, ergaben sich dadurch auch neue Herausforderungen für das Aufrechterhalten der Integrität von Active Directory. Wenn John Smith und Jane Dow eine Änderung an demselben Objekt in Büros an verschiedenen Orten vornehmen, was geschieht, wenn diese Änderungen in Konflikt zueinander stehen? Das Active Directory-Replikationsmodell definiert, wie Updates an alle Domänencontroller innerhalb einer Umgebung übermittelt werden und wie Konflikte, die sich aus der Multimasterfähigkeit ergeben, Änderungen von praktisch jedem Ort aus vorzunehmen, behandelt werden.

Die Funktionsweise der Active Directory-Replikation

In diesen Beispielen wird nur die standortübergreifende Replikation erörtert. Grundsätzlich soll die standortübergreifende Replikation Änderungen schnell auf Domänencontrollern innerhalb desselben Standorts replizieren und wird mithilfe von Änderungsbenachrichtigungen durchgeführt. Im Fall der standortübergreifenden Replikation wird DC2 von DC1 benachrichtigt, dass Änderungen vorhanden sind, die repliziert werden müssen, und DC2 übernimmt diese Änderungen von DC1 per Pull-Replikation. Ebenso wird DC1 von DC2 benachrichtigt, wenn bei DC2 Änderungen vorhanden sind, und DC1 übernimmt diese Änderungen von DC2 per Pull-Replikation. Wie Sie sehen, findet die gesamte Active Directory-Replikation in Pull-Vorgängen, nicht in Push-Vorgängen statt.

Da Active Directory Hunderttausende oder sogar Millionen von Objekten skalieren kann, ist es erforderlich, die Active Directory-Datenbank in Abschnitte aufzuteilen, die als Namenskontexte (Naming Context, NC) bezeichnet werden. Jeder Domänencontroller speichert mindestens drei NCs in seiner lokalen Kopie der Active Directory-Datenbank.

Schemanamenskontext Dieser Namenskontext wird auf allen anderen Domänencontrollern in der Gesamtstruktur repliziert. Er enthält Informationen zum Active Directory-Schema, das wiederum die verschiedenen Objektklassen und Attribute innerhalb von Active Directory definiert.

Konfigurationsnamenskontext Dieser Namenskontext wird ebenfalls auf allen anderen Domänencontrollern in der Gesamtstruktur repliziert. Er enthält gesamtstrukturübergreifende Informationen zum physischen Layout von Active Directory sowie Informationen zu Anzeigebezeichnern und gesamtstrukturübergreifende Active Directory-Kontingente.

Domänennamenskontext Dieser Namenskontext wird auf allen anderen Domänencontrollern innerhalb einer einzelnen Active Directory-Domäne repliziert. Dies ist der Namenskontext, der die Active Directory-Daten enthält, auf die am häufigsten zugegriffen wird: die eigentlichen Benutzer, Gruppen, Computer und anderen Objekte, die sich in einer bestimmten Active Directory-Domäne befinden.

Um den Replikationsdatenverkehr zu optimieren, wird jeder Namenskontext separat repliziert, damit ein Namenskontext wie beispielsweise der Schemanamenskontext keine Netzwerkbandbreite verwendet, die für den Domänennamenskontext erforderlich ist, der sich wahrscheinlich sehr viel häufiger ändert.

Da Verzeichnisänderungen von jedem beliebigen Active Directory-Domänencontroller durchgeführt werden können, gibt es zwei Arten von Schreibvorgängen, die von der Active Directory-Replikation verfolgt werden müssen. Eine Art sind Ursprungsschreibvorgänge, wobei es sich um bestimmte Änderungen handelt, die direkt auf einem bestimmten Domänencontroller durchgeführt wurden. Wenn Sie sich beispielsweise mit DC1 verbinden und das Kennwort eines Benutzers ändern, gilt diese Änderung als Ursprungsschreibvorgang auf DC1. Active Directory muss auch replizierte Schreibvorgänge verfolgen. Hierbei handelt es sich um eine bestimmte Änderung, die von einem anderen Domänencontroller aus repliziert wurde. Die Änderung, die auf DC1 ein Ursprungsschreibvorgang war, ist nun ein replizierter Schreibvorgang, wenn diese Änderung auf DC2, DC3 und anderen Domänencontrollern in der Domäne repliziert wird.

Active Directory-Domänencontroller verwalten die Übertragung von Verzeichnisänderungen durch Verwendung der Replikationsmetadaten. Neben der Übermittlung der eigentlichen Daten, die von einem Domänencontroller zu einem anderen hin geändert wurden (die Berufsbezeichnung von John Smith wurde beispielsweise in „Personalchef“ umgeändert), überträgt Active Directory auch zusätzliche Informationen zu dieser Änderung, damit Domänencontroller die Replikation möglichst effizient verwalten können, beispielsweise Informationen zum Domänencontroller, auf dem die ursprüngliche Änderung durchgeführt wurde, der Zeitpunkt der Änderung und andere wichtige Informationen.

Das erste Element der Replikationsmetadaten, das hier erörtert wird, ist die Aktualisierungssequenznummer (Update Sequence Number, USN). Jeder Domänencontroller verwaltet eine für ihn spezifische USN. Bei Durchführung einer Änderung an Active Directory durch diesen Domänencontroller wird die USN um 1 erhöht. Wenn ein Domänencontroller daher um 11 Uhr eine USN von 1.000 hat und um 11.30 Uhr eine USN von 1.005, wissen Sie, dass auf diesem Domänencontroller 5 Änderungen an der Active Directory-Datenbank durchgeführt wurden. Um was für Änderungen es sich dabei handelte, ist für die USN unwichtig. Möglicherweise wurden 5 verschiedene Objekte geändert, 5 Objekte erstellt, 5 Objekte gelöscht oder eine Kombination aus diesen Vorgängen durchgeführt. Die USN des Domänencontrollers erhöht sich dabei immer um 5. Außerdem gelten USNs nur für einen bestimmten Domänencontroller intern und haben beim Vergleich mit anderen Domänencontrollern keinerlei Relevanz. Ein Domänencontroller in einer Domäne könnte eine Änderung um 11.30 Uhr durchführen und ihr eine USN von 1051 zuweisen, und ein zweiter Domänencontroller in derselben Domäne könnte genau im selben Augenblick eine Änderung vornehmen, der eine USN von 5084 zugewiesen wird. Diese beiden Domänencontroller verfügen zwar offensichtlich über völlig unterschiedliche USNs für eine Änderung, die ungefähr zur selben Zeit erfolgte, aber diese Tatsache ist für die Replikation dieser Änderungen irrelevant. Die Aktualisierungssequenznummer eines Domänencontrollers hat keinerlei Bedeutung für andere Domänencontroller, was den Vergleich einer Änderung mit einer anderen betrifft.

Doch dies ist nicht die einzige Möglichkeit zum Erhöhen der USN eines Domänencontrollers. Bedenken Sie, dass eine Änderung an der Active Directory-Datenbank aus einem Ursprungsschreibvorgang oder einem replizierten Schreibvorgang bestehen kann. Die Aktualisierungssequenznummer eines Domänencontrollers wird durch beide Arten von Schreibvorgängen erhöht, was heißt, dass sie jedes Mal erhöht wird, wenn Änderungen von einem anderen Domänencontroller aus repliziert werden. Jeder Domänencontroller muss nachverfolgen können, welche Änderungen bereits repliziert wurden, da sonst jeder Domänencontroller bei jeder Replikation die gesamte Active Directory-Datenbank senden würde. Um dies zu verhindern, verwaltet jeder Active Directory-Domänencontroller einen als „High Watermark“-Vektor (HWMV) bezeichneten Wert für andere Domänencontroller, bei denen Replikationen durchgeführt werden. Jeder Domänencontroller ordnet diesen HWMV der eindeutigen globalen Kennung (Globally Unique Identifier, GUID) des Remotedomänencontrollers zu, um Verwirrung zu verhindern, wenn ein Remotedomänencontroller umbenannt oder aus dem Verzeichnis entfernt wird.

Hier ein einfaches Beispiel: zwei Domänencontroller sind in der contoso.com-Domäne als dc1.contoso.com und dc2.contoso.com konfiguriert. Da in der contoso.com-Domäne nur zwei Domänencontroller vorhanden sind, werden DC1 und DC2 nur miteinander repliziert. (Dies ist lediglich ein vereinfachtes Beispiel, das die Active Directory-Replikation noch nicht ganz beschreibt. Darauf wird später beim Erörtern weiterer Einzelheiten näher eingegangen.)

Weiter wird davon ausgegangen, dass die aktuelle USN von DC1 3.000 ist und die aktuelle USN von DC2 4.500 und dass die Replikation zwischen diesen beiden Domänencontrollern zu Beginn des Beispiels auf dem neuesten Stand ist.

Schritt 1: Die Replikation zwischen DC1 und DC2 ist auf dem neuesten Stand. DC1 hat einen „High Watermark“-Vektor für DC2 von 4.500, und DC2 hat einen „High Watermark“-Vektor für DC1 von 3.000, wie in Abbildung 1 dargestellt.

Abbildung 1** Aktueller Zustand von zwei Domänencontrollern **

Schritt 2: Ein Administrator erstellt ein neues Objekt auf DC1, und die USN von DC1 wird auf 3.001 erhöht, wie in Abbildung 2 dargestellt. Beachten Sie, dass sich der HWMV von DC1 auf DC2 nicht geändert hat, weil DC2 von DC1 noch nicht benachrichtigt wurde, dass Änderungen vorhanden sind.

Abbildung 2** Ein neues Objekt wird hinzugefügt **

Schritt 3: DC1 benachrichtigt DC2, dass Änderungen verfügbar sind. DC2 initiiert nun die Replikation mit DC1 und fordert verfügbare Updates an. Als Teil dieser Anforderung sendet DC2 den „High Watermark“-Vektor an DC1, der für DC1 gespeichert ist, wie in Abbildung 3 aufgezeigt.

Abbildung 3** Benachrichtigung über Änderungen **(Klicken Sie zum Vergrößern auf das Bild)

Schritt 4: DC1 sendet DC2 die Änderung, die USN 3.001 entspricht, d. h. das in Schritt 2 auf DC1 erstellte Objekt. DC2 aktualisiert die eigene USN auf 4.501 und seinen HWMV für DC1 auf 3.001, wie in Abbildung 4 dargestellt.

Abbildung 4** Änderungen und Aktualisierungen **(Klicken Sie zum Vergrößern auf das Bild)

So weit so gut. Dabei gibt es allerdings ein Problem. DC2 liegt eine Änderung vor, die repliziert werden muss. Wenn nur USNs und „High Watermark“-Vektoren vorhanden wären, würde DC2 an dieser Stelle DC1 kontaktieren, um dieselbe Änderung, die von DC1 gerade auf DC2 repliziert wurde, wieder auf DC1 replizieren, was zu einem endlosen, immer mehr Bandbreite beanspruchenden Replikationszyklus führen würde. Damit dies nicht geschieht, sind einige weitere Elemente erforderlich, wobei das erste der Aktualitätsvektor (Up-to-Dateness-Vektor, UTDV) ist.

Der UTDV ist ein weiterer Teil der Replikationsmetadaten, das zur Propagierungsdämpfung verwendet wird. Seine Aufgabe besteht darin, zu verhindern, dass dieselbe Änderung Bandbreite verschwendet, indem sie über das Netzwerk hinweg immer wieder repliziert wird. Jeder Domänencontroller verwaltet eine UTDV-Tabelle für alle anderen Domänencontroller, in der ein Replikat des betreffenden Namenkontexts gespeichert wird. Für den Domänennamenskontext verwaltet jeder Domänencontroller in einer Domäne einen UTDV für alle anderen Domänencontroller in der Domäne. Beim Konfigurations- und Schemanamenskontext wird der UTDV für alle Domänencontroller in der Gesamtstruktur verwaltet. Die UTDV-Tabelle verfolgt nicht nur die höchste USN, die die einzelnen Domänencontroller von ihren Replikationspartnern erhalten haben, sondern auch den höchsten USN-Wert, den sie von allen Domänencontrollern, die einen bestimmten Namenskontext replizieren, erhalten hat. Um dies zu ermöglichen, umfasst jede replizierte Änderung auch die folgenden Informationen:

• Die GUID des Domänencontrollers, der die Änderung repliziert. Dabei kann es sich um eine Änderung handeln, die als Ursprungsschreibvorgang oder als replizierter Schreibvorgang repliziert wird.
• Die USN des Domänencontrollers, der die Änderung repliziert. Wieder kann es sich um eine Replikation als Ursprungs- oder replizierter Schreibvorgang handeln.
• Die GUID des Domänencontrollers, der die Änderung verursacht hat. Wenn diese GUID identisch mit der GUID des Domänencontrollers ist, der die Änderung repliziert, handelt es sich um einen Ursprungsschreibvorgang. Andernfalls kommt die UTDV-Tabelle ins Spiel.
• Die USN des Domänencontrollers, der die Änderung verursacht hat. Auch hier gilt: wenn diese USN identisch mit der USN des Domänencontrollers ist, der die Änderung repliziert, handelt es sich um einen Ursprungsschreibvorgang. Andernfalls kommt die UTDV-Tabelle ins Spiel.

Um diesen Prozess besser zu illustrieren, wird das Beispiel durch Hinzufügen eines dritten Domänencontrollers (DC3) komplexer gestaltet. Bei diesem Beispiel sind DC1, DC2 und DC3 Replikationspartner, die alle miteinander replizieren. DC1 repliziert mit DC2 und DC3, DC2 mit DC1 und DC3 und DC3 mit DC1 und DC2:

Schritt 1: Die Replikation zwischen DC1, DC2 und DC3 ist auf dem neuesten Stand.

Schritt 2: DC3 führt einen einzelnen Ursprungsschreibvorgang durch, indem das Kennwort für das Benutzerkonto „jsmith“ zurückgesetzt wird. DC3 benachrichtigt DC1 und DC2, dass Änderungen verfügbar sind. DC1 und DC2 erhalten den Ursprungsschreibvorgang von DC3 per Pull-Replikation und aktualisieren dann ihre HWMV- und UTDV-Tabelle für DC3, wie in Abbildung 5 dargestellt.

Abbildung 5** Aktualisierung der HWMV- und UTDV-Tabelle **(Klicken Sie zum Vergrößern auf das Bild)

Schritt 3: An dieser Stelle kommt der Aktualitätsvektor ins Spiel. DC2 benachrichtigt DC1, dass Änderungen verfügbar sind. Dann wird DC2 von DC1 kontaktiert, um neue Änderungen anzufordern, indem folgende Informationen an DC2 gesendet werden:

• Der „High Watermark“-Vektor von DC1 für DC2, in diesem Fall 4.501.
• Die UTVD-Tabelle von DC1 (dargestellt in Abbildung 6), die die höchste Ursprungs-USN anzeigt, die sie von allen Domänencontrollern einschließlich DC3 erhalten hat.

Figure 6 UTDV-Tabelle

Alle Domänencontroller, die diesen Namenskontext replizieren	UTDV
<GUID von DC2>	4501
<GUID von DC3>	7002

Basierend auf dem HWMV 4.501 erkennt DC2, dass die betreffende Änderung auf DC1 nicht repliziert wurde (siehe Abbildung 7).

Figure 7 Eine Änderung muss repliziert werden

Eigenschaft	Wert	GUID des lokalen Domänencontrollers	Lokale USN	GUID des Ursprungsdomänencontrollers	Ursprungs-USN
jsmith-Kennworteigenschaft	%#FH%2rfg2	<GUID von DC2>	4501	<GUID von DC3>	7002

Doch auf Grundlage der UTDV-Tabelle, die von DC1 vor Beginn der Replikation übertragen wurde, stellt DC2 fest, dass diese Änderung für DC1 nicht erforderlich ist, da DC1 diese Änderung bereits von DC3 erhalten hat. An dieser Stelle aktualisiert DC1 einfach seinen HWMV-Eintrag für DC2, damit die erhöhte USN wiedergegeben wird. Dies ist in Abbildung 8 dargestellt. Damit keine Bandbreite verschwendet wird, werden die eigentlichen Daten nicht über das Netzwerk gesendet.

Abbildung 8** Propagierungsdämpfung **(Klicken Sie zum Vergrößern auf das Bild)

Schritt 4: Dieselbe Propagierungsdämpfung findet statt, wenn DC3 von DC2 benachrichtigt wird, dass Änderungen verfügbar sind, und wenn DC1 auf ähnliche Weise DC2 und DC3 benachrichtigt. Alle drei Domänencontroller aktualisieren ihre jeweiligen HWMV-Einträge für ihre Replikationspartner wie in Abbildung 8 dargestellt, aber die eigentlichen Daten werden nicht erneut über das Netzwerk gesendet, da sie bereits in Schritt 2 an die einzelnen Domänencontroller übertragen wurden.

Konfliktauflösung in einer Multimasterumgebung

Bei den bisher vorgestellten Beispielen handelte es sich um eine perfekte Umgebung, in der jeweils nur ein Administrator Änderungen an einem Domänencontroller vornimmt und niemand ihm in die Quere kommt. In der Realität ist dies jedoch nur selten der Fall. Updates an einem Active Directory-Objekt können von jedem beliebigen Domänencontroller in der Domäne stammen. Was passiert, wenn zwei Administratoren widersprüchliche Updates von zwei verschiedenen Domänencontrollern aus durchführen? In einer Active Directory-Umgebung können drei verschiedene Arten von Konflikten auftreten, wobei es für jeden eine andere Methode der Konfliktauflösung gibt.

Widersprüchliche Eigenschaftsänderungen . Dieser Konflikt findet statt, wenn zwei Administratoren dasselbe Objekt auf widersprüchliche Weise aktualisieren: ein Administrator beispielsweise legt die Beschreibung eines Benutzers auf „Marketing“ fest, während ein anderer Administrator die Beschreibung dieses Benutzers auf einem anderen Domänencontroller auf „Vertrieb und Marketing“ festlegt.

Erstellen neuer widersprüchlicher Objekte . Zu diesem Konflikt kommt es, wenn zwei Administratoren gleichzeitig ein Objekt mit demselben Namen erstellen, etwa zwei Benutzer mit dem Namen „jsmith“.

Verschieben eines Objekts in einen gelöschten Container . Diese Konfliktart ist viel seltener. Er tritt ein, wenn ein Administrator ein Objekt, beispielsweise eine Organisationseinheit, innerhalb eines Containers zu derselben Zeit erstellt oder verschiebt, wenn ein anderer Administrator diesen Container auf einem anderen Domänencontroller löscht.

Zum Lösen der ersten beiden Konfliktarten müssen zwei weitere Teile von Replikationsmetadaten vorgestellt werden, die hauptsächlich zur Konfliktauflösung dienen. Der versionID-Wert wird jedem einzelnen Attribut auf einem Objekt mit dem Anfangswert 1 zugewiesen, wenn das Objekt ursprünglich erstellt wird. Die versionID wird immer dann um 1 erhöht, wenn ein einzelnes Attribut von einem beliebigen Domänencontroller geändert wird. Wenn also das Beschreibungsattribut eines bestimmten Benutzers von seinem Standardwert (leer oder <nicht festgelegt>) auf „Marketingabteilung“ aktualisiert wird, erhält das Beschreibungsattribut die versionID 2. Wenn die Beschreibung später auf „Vertrieb und Marketingabteilung“ geändert wird, erhält das Beschreibungsattribut die versionID 3 und so weiter. Diese versionID ist in jedem Replikationseintrag zusammen mit den anderen Teilen der Metadaten enthalten, die bereits vorgestellt wurden.

Die versionID kann zudem zur weiteren Reduzierung des Replikationsdatenverkehrs verwendet werden. Wenn beispielsweise ein Administrator auf DC2 mehrere Änderungen an einem einzelnen Attribut vorgenommen hat (vielleicht hat er die Änderung mehrmals falsch eingegeben), sodass über DC2 Ursprungsschreibvorgänge verfügt, die den versionID-Werten 2, 3, 4 und 5 entsprechen, repliziert DC2 nur den Schreibvorgang, der der letzten versionID, also 5, entspricht. Da die vorherigen Änderungen sowieso einfach überschrieben würden, ist dies eine Abkürzung, um unnötige Bandbreitennutzung zu verringern.

Jede Änderung an Active Directory umfasst auch den zweiten zusätzlichen Teil der Metadaten, das zur Konfliktauflösung verwendet wird: ein Zeitstempel in den Replikationsmetadaten, der anzeigt, wann die Änderung durchgeführt wurde.

Das Zeitstempelattribut dient auch als proaktive Messung der Replikationsintegrität von Active Directory. Wenn ein Domänencontroller von einem bestimmten anderen Domänencontroller keine Änderungen mit einem relativ neuen Zeitstempel empfangen hat, werden Fehlermeldungen generiert, die anzeigen, dass bei dem betreffenden Domänencontroller ein Problem vorliegen könnte.

Wie werden diese beiden Attribute nun bei der Konfliktauflösung verwendet? Die Konfliktarten werden hier der Reihe nach untersucht.

Die Auflösung widersprüchlicher Eigenschaftsänderungen

Im Beispiel geht es um das Benutzerobjekt „jsmith“ in der contoso.com-Domäne. Ein Administrator auf DC1 ändert die Beschreibung von jsmith in „Marketing“. Fast gleichzeitig ändert ein Administrator auf DC3 die Beschreibung desselben Benutzers in „Vertrieb und Marketing“. Zu diesem Zeitpunkt lassen sich die Informationen von DC1 und DC3 über das Beschreibungsattribut von jsmith wie in Abbildung 9 dargestellt vergleichen.

Figure 9 Fast gleichzeitige Änderungen

Server	Eigenschaft	Wert	VersionID	TimeStamp	GUID des lokalen Domänencontrollers	Lokale USN	GUID des Ursprungsdomänencontrollers	Ursprungs-USN
DC1	jsmith-Beschreibungseigenschaft	„Marketing“	2	2007-06-07 14:03:25	<GUID von DC1>	3003	<GUID von DC1>	3003
DC3	jsmith-Beschreibungseigenschaft	„Vertrieb und Marketing“	2	2007-06-07 14:04:57	<GUID von DC3>	7003	<GUID von DC3>	7003

Wenn DC2 diese beiden Änderungen gleichzeitig erhält, muss offensichtlich bestimmt werden, welche Änderung nun wirklich repliziert werden soll. Die Konfliktauflösung erfolgt dabei nach den folgenden Regeln:

1. Die Änderung mit der höheren versionID wird für die Replikation akzeptiert, während die Änderung mit der niedrigeren versionID überschrieben wird. In diesem Fall ist die versionID für beide Datensätze 2, sodass die zweite Regel ins Spiel kommt.
2. Wenn beide Datensätze dieselbe versionID haben, wird die Änderung mit dem späteren Zeitstempel akzeptiert, während die andere Änderung überschrieben wird. In diesem Fall zeigt der Zeitstempel des Ursprungsschreibvorgangs von DC3 ein späteres Datum, sodass die Beschreibung von jsmith auf „Vertrieb und Marketing“ festgelegt wird. In dem seltenen Fall, dass sowohl die versionID als auch der Zeitstempel identisch sind, ist eine dritte und endgültige Regel erforderlich.
3. Wenn beide Datensätze über dieselbe versionID und denselben Zeitstempel verfügen, wird der Schreibvorgang, der seinen Ursprung auf dem Domänencontroller mit der niedrigeren GUID hat, akzeptiert, und der Schreibvorgang vom Domänencontroller mit der höheren GUID wird überschrieben. Wenn also die GUID von DC1 1234567890 ist und die GUID von DC3 2345678901, würde der Ursprungsschreibvorgang von DC1 akzeptiert, wenn sowohl versionID als auch Zeitstempel identisch sind.

Wahrscheinlich fragen Sie sich, ob es nicht sinnvoller wäre, wenn der Zeitstempel an erster Stelle den Ausschlag geben würde. Das ist nicht so eindeutig, wie Sie vielleicht denken. Wenn der Zeitstempel bei der Konfliktauflösung in Active Directory primär den Ausschlag geben würde, müsste ein böswilliger Administrator zum Propagieren seiner Änderungen nur die Uhr auf einem bestimmten Domänencontroller zurückstellen, sodass dieser bei den Zeitstempeln immer als Sieger hervorgehen würde.

Auflösung einer widersprüchlichen Objekterstellung

In Fällen, in denen zwei Objekte mit demselben Namen erstellt werden, verwendet Active Directory dieselben drei ausschlaggebenden Regeln, die im vorherigen Abschnitt beschrieben wurden, um zu bestimmen, welches Objekt akzeptiert wird. Im Gegensatz zum vorherigen Abschnitt wird das jeweils nicht akzeptierte Objekt jedoch nicht überschrieben. Stattdessen wird das nicht akzeptierte Objekt mithilfe der Zeichen CNF (Conflict Objekt, Konfliktobjekt) gefolgt durch einen Doppelpunkt und der GUID des nicht akzeptierten Objekts umbenannt. So können Administratoren methodischer bestimmen, welches Objekt erhalten bleiben und welches gelöscht werden soll.

Auflösung einer Objektverschiebung in einen gelöschten Container

Wie bereits erwähnt, ist die Auflösung einer Objektverschiebung in einen gelöschten Container ein recht seltener Konflikt, der nur in einem von zwei Szenarios eintritt. In einem Szenario erstellt ein Administrator auf einem Domänencontroller innerhalb eines bestimmten Containers, beispielsweise in der Organisationseinheit Schulung, zum selben Zeitpunkt ein Objekt, zu dem ein Administrator auf einem anderen Domänencontroller die Organisationseinheit Schulung löscht. Das zweite Szenario kann eintreten, wenn ein Administrator auf einem Domänencontroller zum gleichen Zeitpunkt ein Objekt in einen Container verschiebt, zu dem ein Administrator auf einem anderen Domänencontroller diesen Container löscht.

Die Auflösung in diesem Fall ist ziemlich einfach: Active Directory verschiebt das „verwaiste“ Objekt in einen besonderen Container innerhalb von Active Directory, der zu diesem Zweck entworfen wurde: der LostAndFound-Container, der vom Stamm jeder Active Directory-Domäne ausgeht. Für die contoso.com-Domäne befindet sich der LostAndFound-Container entlang des folgenden LDAP-Pfads: LDAP://cn=LostAndFound,dc=contoso,dc=com. Wenn Sie den LostAndFound-Container beim Öffnen des Snap Ins „Active Directory-Benutzer und -Computer“ nicht sehen, klicken Sie einfach auf „Ansicht | Advanced Features“ (Ansicht | Erweiterte Features).

Schutz vor einem USN-Rollback

Eine der schwierigsten Situationen, denen Sie in einer Active Directory-Umgebung begegnen können, lässt sich gleichzeitig sehr einfach vermeiden, wenn Sie ihre Ursache verstehen und die Problemumgehung kennen. Ein USN-Rollback ist eine Fehlerbedingung, die die Replikation auf Ihrem Netzwerk völlig stilllegen kann. Sie wird dadurch verursacht, dass ein Domänencontroller zu lange offline bleibt und dann seinen Dienst wiederaufnimmt, oder durch das Wiederherstellen eines Domänencontrollers mithilfe einer nicht unterstützten Methode.

Eine der zugrunde liegenden Ursachen eines USN-Rollbacks ist die Art und Weise, wie Objektlöschungen in der Active Directory-Multimasterumgebung verarbeitet werden. Wenn ein Objekt auf einem Domänencontroller gelöscht wird, statt sofort entfernt zu werden, handelt es sich um ein Tombstone-Objekt. Tombstone-Objekte können auf anderen Domänencontrollern repliziert werden, sodass diese über die Löschung benachrichtigt werden. Am wichtigsten ist, dass ein Tombstone-Objekt ein isDeleted-Attribut besitzt, das auf TRUE eingestellt ist. Um die Größe des Tombstone-Objekts zu verringern, werden die meisten in dem Objekt enthaltenen Werte wie die Beschreibung, persönlich Informationen und die Gruppenmitgliedschaft eines Benutzerobjekts entfernt (weitere Informationen zu diesem Prozess finden Sie in Gil Kirkpatricks Artikel „Tombstone-Wiederbelebung in Active Directory“, der online unter technetmagazine.com/issues/2007/09 verfügbar ist).

Ein USN-Rollback kann eintreten, weil diese Tombstone-Objekte nicht unendlich lange vorhanden sind. Sie werden (abhängig von der Version von Windows Server®, die bei der ersten Erstellung der Active Directory-Umgebung ausgeführt wurde) standardmäßig nach 60 oder 180 Tagen aus der Active Directory-Datenbank gelöscht. Diese Zeitdauer von 60 oder 180 Tagen wird als Tombstone-Lebensdauer bezeichnet. Alle Domänencontroller müssen in der Lage sein, in dieser Zeit mindestens einmal eine Replikation vorzunehmen. Andernfalls sind sie völlig nutzlos, und die Gefahr eines USN-Rollbacks tritt auf. Im Grunde findet ein USN-Rollback statt, wenn ein Domänencontroller so vollständig veraltet ist, dass er eins oder mehrere Tombstone-Objekte „verpasst“ hat und folglich seine lokale Kopie der Active Directory-Datenbank nicht vollständig mit anderen Domänencontrollern auf den neuesten Stand bringen kann. Zum Schutz davor, sollte ein Domänencontroller, der länger als die Tombstone-Lebensdauer offline war, nicht wieder in den Dienst gestellt, sondern ganz neu erstellt werden, nachdem die alten Metadaten des Domänencontrollers mithilfe der im Microsoft Knowledge Base-Artikel 216498 (support.microsoft.com/kb/216498) beschriebenen Schritte entfernt wurden.

Die zweite Ursache für ein USN-Rollback besteht darin, dass ein Domänencontroller mit einer nicht unterstützten Methode (am häufigsten mit einem Tool zum Datenträgerklonen oder einem Abbilderstellungstool) wiederhergestellt wurde. In diesem Fall erkennt die wiederherstellte Active Directory-Datenbank nicht, dass sie „in der Zeit zurückgegangen“ ist, da die Wiederherstellungsmethode nicht Active Directory-fähig war. Ein USN-Rollback war in Windows 2000 und der ersten veröffentlichten Version von Windows Server 2003 nur schwer zu erkennen, doch Windows Server 2003 SP1 (und die bevorstehende Windows Server 2008-Version) verfügen über integrierte Steuerelemente, um zu erkennen, wann ein Domänencontroller nicht richtig wiederherstellt wurde. In diesen neueren Betriebssystemversionen protokolliert ein Domänencontroller die Ereignis-ID 1115, 2095, 2103 und 2110 im Verzeichnisdienste-Ereignisprotokoll. Der Text dieser Ereignisse sowie die erforderlichen Schritte zur Wiederherstellung nach einem USN-Rollback sind im Knowledge Base-Artikel 875495 (support.microsoft.com/kb/875495) für Windows Server 2003 enthalten. (Informationen zum Behandeln eines USN-Rollbacks in Windows 2000 finden Sie im Knowledge Base-Artikel 885875, der unter support.microsoft.com/kb/885875 verfügbar ist.)

Aktualisierung des Multimastermodells in 2008

Mit der bevorstehenden Veröffentlichung von Windows Server 2008 hat Microsoft mit der Einführung des Domänencontrollers ohne Schreibzugriff (Read-Only Domain Controller, RODC) eine geringfügige Änderung am Multimastermodell vorgenommen. Der RODC wurde hauptsächlich für Zweigstellenbereitstellungen oder für Szenarios entwickelt, in denen es vor Ort an einem bestimmten Standort keine dedizierten IT-Mitarbeiter gibt und zusätzliche Schritte unternommen werden müssen, um die Integrität eines bestimmten Domänencontrollers sicherzustellen. Die Erörterung der technischen Einzelheiten des RODC wäre Stoff für einen ganzen Artikel, doch hier werden nur die Hauptpunkte vorgestellt, mit denen Sie vertraut sein sollten.

Wie der Name schon sagt, ist die Kopie der Active Directory-Datenbank, die sich auf einem RODC befindet, schreibgeschützt. Sie können eine Verbindung zu einem RODC herstellen, um fast alle erforderlichen Informationen zu lesen, aber Sie können keine Schreibvorgänge auf einem RODC durchführen.

Zweitens führt ein RODC keine ausgehende Replizierung durch. Dies ist eine grundlegende Änderung gegenüber dem Multimasterreplikationsmodell, das hier bisher erörtert wurde. Ein RODC empfängt die eingehende Replizierung von anderen beschreibbaren Windows Server 2008-Domänencontrollern, repliziert jedoch keinerlei Informationen für andere Domänencontroller. Dies sorgt für eine zusätzliche Sicherheitsschicht, denn selbst wenn ein böswilliger Benutzer das Active Directory vom RODC aus irgendwie ändern könnte, würden diese Änderungen nicht in der übrigen Umgebung propagiert.

Vielleicht am interessantesten ist jedoch die Tatsache, dass der RODC Benutzerkennwörter nicht standardmäßig repliziert. Wenn die Active Directory-Datenbank eingehend von einem beschreibbaren Domänencontroller auf einem RODC repliziert wird, werden alle Benutzerobjekte ohne die Kennwortinformationen des Benutzers repliziert. Dies sorgt für eine weitere Sicherheitsschicht in einer Zweigstellenumgebung, sodass sich selbst beim Diebstahl eines Domänencontrollers keine Kennwortinformationen auf seiner Festplatte befinden. Insgesamt sorgen diese Änderungen an der ursprünglichen Idee der Multimasterreplikation in Active Directory für ein stark verbessertes Modell zur Sicherung von Domänencontrollern in Zweigstellen oder an anderen Remotestandorten.

Laura E. Hunter wurde vier Mal mit dem Microsoft MVP Award im Bereich von Windows Server Networking ausgezeichnet. Sie ist seit zehn Jahren in der IT-Branche tätig und ist Verfasserin oder Mitverfasserin zahlreicher branchenbezogener Bücher, Artikel, und Whitepapers, darunter „Active Directory Cookbook“, zweite Auflage (O'Reilly, 2006).

© 2008 Microsoft Corporation und CMP Media, LLC. Alle Rechte vorbehalten. Die nicht genehmigte teilweise oder vollständige Vervielfältigung ist nicht zulässig.