Eines der Schutzmechanismen der AD-Replikation ist die strict replication consistency (strikte Replikationskonsistenz), die standardmäßig bei einer Migration von NT 4.0 auf Windows Server 2003 oder wenn ein Forest ab Windows Server 2003 erstellt wurde, aktiviert ist. Die Funktion der „strict replication consistency“ steht ab Windows 2000 Server SP3 (sogar schon mit Post-SP2 Hotfix) zur Verfügung, diese ist aber unter Windows 2000 standardmäßig deaktiviert!
Was es mit der strict replication consistency auf sich hat und wann diese vor allem zum Einsatz kommt, wird in dem folgenden Artikel detailliert erläutert:
LDAP://Yusufs.Directory.Blog/ - Lingering Objects (veraltete Objekte)
Kurz gesagt verhindert die „strict replication consistency“, dass Lingering Objects (herumlungernde/veraltete Objekte) von einem (veralteten) Domänencontroller (DC) der sich länger als die Tombstone-Lifetime nicht mehr mit seinen Replikationspartnern repliziert hat, zurück zu den (aktuellen!) Replikationspartnern repliziert werden.
Ein Forest der unter Windows Server 2003 oder höher installiert wurde, verfügt über einen speziellen operativen GUID, der standardmäßig aber nicht in einem Forest mit Windows 2000 Wurzeln existiert!
Wird ein Server zum DC hochgestuft, überprüft dieser ob das folgende Objekt existiert:
CN=94fdebc6-8eeb-4640-80de-ec52b9ca17fa,CN=Operations,CN=ForestUpdates,CN=Configuration,DC=<Root-Domain>
Erst wenn dieser Container zum Zeitpunkt des heraufstufen existiert, aktiviert der künftige DC die „strict replication consistency“ automatisch.
Ab Windows Server 2003 SP1 kann man die „strict replication consistency“ auf einem einzelnen DC mit dem folgenden REPADMIN-Befehl aktivieren: Repadmin /regkey <DC> +strict.
Auf allen DCs im Forest lässt sich die „strict replication consistency“ wie folgt aktivieren: Repadmin /regkey * +strict
Das bedeutet jedoch, jedes Mal wenn weitere DCs (in einen Forest mit Windows 2000 Wurzeln) hinzukommen, muss jedes Mal auf dem DC die „strict replication consistency“ mit dem Befehl „Repadmin /regkey <DC> +strict“ aktiviert werden.
Eine elegantere Variante ist, damit ab sofort auf allen künftigen DCs automatisch die „strict replication consistency“ aktiviert ist, man erstellt den operativen Container in der Konfigurationspartition manuell.
Mit ADSIEdit kann man das folgendermaßen erledigen:
- Nachdem ADSIEdit gestartet und der Eintrag ADSI Edit auf der linken Seite markiert wurde, gilt es zuerst auf Action und anschließend auf Connect to… zu klicken.
- Im darauf erscheinenden “Connection Settings” Dialogfenster kann man dann im Bereich Connection Point im Feld Select or type a Distinguished Name or Naming Context den folgenden LDAP-Pfad, sprich den Distinguished Name des folgenden Containers angeben und anschließend mit OK bestätigen: CN=Operations,CN=ForestUpdates,CN=Configuration,DC=<Root-Domain>
- Als nächstes gilt es mit einem Rechtsklick auf CN=Operations,CN=ForestUpdates,CN=Configuration,DC=<Root-Domain> die Option New -> Object... auszuwählen.
- Als class muss der Eintrag container ausgewählt werden.
- Im nächsten Schritt muss als Value dieser Wert eingegeben warden: 94fdebc6-8eeb-4640-80de-ec52b9ca17fa.
- Danach sollte man auf auf More Attributes klicken und unter Select a property to view die Option showInAdvancedViewOnly auswählen.
- Zusätzlich sollte im Bereich Attribute Values im Feld Edit Attribute als Wert TRUE eingetragen und mit SET bestätigt werden.
- Mit einem abschließenden Klick auf OK und Finish hat man dann das Objekt 94fdebc6-8eeb-4640-80de-ec52b9ca17fa erstellt. Ab sofort wird nun bei einem neuen DC der in einer Gesamtstruktur mit Windows 2000 Wurzeln hochgestuft (promotet) wurde, die „strict replication consistency“ automatisch aktiviert.
Wem jedoch dieser Vorgang zu heikel ist, der kann auch regelmäßig (evtl. in einem geplanten Task) den REPADMIN – Befehl ausführen, damit auf allen neuen DCs auch die „strict replication consistency“ aktiviert wird: Repadmin /regkey * +strict
Mit der folgenden GPO-ADM Datei lässt sich das ebenfalls lösen:
CLASS MACHINE
CATEGORY "Strict Replication Consistency"
KEYNAME "System\CurrentControlSet\Services\NTDS\Parameters"
POLICY "Enable Strict Replication Consistency"
EXPLAIN "This enables Strict Replication Consistency”.
VALUENAME "Strict Replication Consistency"
VALUEON NUMERIC 1
VALUEOFF DELETE
END POLICY
END CATEGORY
Wird anschließend diese GPO auf die OU “Domain Controllers” verlinkt, wird ebenfalls auf jedem neuen DC die „strict replication consistency“ automatisch aktiviert.
Weitere Informationen:
Event ID 1388 or 1988: A lingering object is detected: Active Directory
Der Generator für die standortübergreifende Replikationstopologie (Inter-Site Topology Generator, kurz ISTG), der, unabhängig von der Anzahl an Domänen und Verzeichnispartitionen, nur einmal pro AD-Standort existiert, ist eine Komponente des Knowledge Consistency Checker, kurz KCC. Der ISTG ist für die Berechnung der standortübergreifenden Replikationstopologie und für das Erstellen von eingehenden Replikationsverbindungen auf Bridgeheadserver (BHS) zuständig. Der ISTG ist in jedem AD-Standort auch dafür verantwortlich, automatisch einen BHS für jede Verzeichnispartition sowie für jedes Replikationstransportprotokoll an einem AD-Standort zu ermitteln. Der DC, der die Rolle des ISTG innehat, muss nicht unbedingt auch ein BHS sein!
Der BHS dient im Hinblick auf die AD-Replikation mit BHS aus anderen AD-Standorten als Brückenkopf und somit als Anlaufstelle, über den Replizierungsinformationen mit anderen AD-Standorten ausgetauscht werden. Der BHS ist der Einzige, der für die AD-Standort zu -Standort Replikation zuständig ist. Das bedeutet, über den BHS und nur über ihn, läuft die AD-Replikation zwischen den AD-Standorten (Inter-Site) ab! Dazu sammeln die BHS alle getätigten AD-Änderungen die auf allen DCs eines AD-Standorts stattgefunden haben, um diese dann zu anderen BHS aus anderen AD-Standorten zu replizieren. Deshalb erhält ein BHS an einem AD-Standort bevorzugt als erster die Replikationsdaten.
Der BHS ist dabei ausschließlich für die Verzeichnispartitionen autorisierend und repliziert auch nur die, die der BHS selbst in seiner Verzeichnisdatenbank (NTDS.dit) hält (einschließlich der Verzeichnispartitionen für den globalen Katalog). Jede Verzeichnispartition, die ein BHS eines AD-Standorts nicht innehat, benötigt einen weiteren BHS, der die entsprechende Verzeichnispartition in seiner Verzeichnisdatenbank gespeichert hat. Unter anderem können deshalb an einem AD-Standort mehrere BHS existieren. Ein BHS kann mehrere Verzeichnispartitionen über dasselbe Replikationstransportprotokoll oder auch über beide Replikationstransportprotokolle verwalten. Die AD-Replikation findet aber standortintern und standortübergreifend standardmäßig über das RPC über IP Protokoll statt. Die AD-Replikation könnte jedoch auch mit dem SMTP-Protokoll durchgeführt werden, allerdings ist das nur eingeschränkt möglich. Denn die Domänenpartition kann by Design nicht über das SMTP-Protokoll repliziert werden und es ist ein höherer Aufwand notwendig, um das entsprechend zu konfigurieren (eine Zertifizierungsstelle muss vorhanden sein).
Des Weiteren ist der ISTG für das Erstellen von eingehenden Verbindungsobjekten zwischen den BHS zuständig. Da die standortübergreifende AD-Replikation ausschließlich zwischen den BHS konfiguriert wird, werden im Gegensatz zu der standortinternen (Intra-Site) AD-Replikation, keine redundanten Verbindungsobjekte erstellt. Es werden lediglich weitere Verbindungsobjekte mit BHS in mehreren AD-Standorten erstellt, wenn es in der Standortverknüpfung (Site-Link) so konfiguriert wurde.
Einen Bridgeheadserver konfigurieren
Es gibt seit Windows 2000 mehrere Möglichkeiten einen DC als BHS für das IP- und SMTP-Protokoll zu bestimmen. Diese wären:
- Die automatische Auswahl des BHS wird dem ISTG überlassen. Standardmäßig bestimmt der ISTG eigenständig den DC, der als BHS in einem AD-Standort tätig sein soll. Es ist kein manuelles Eingreifen erforderlich. Fällt der aktuelle BHS eines AD-Standorts aus, wählt beim nächsten KCC-Lauf (standardmäßig nach maximal 15 Minuten) der ISTG automatisch und eigenständig, ohne das Zutun des Administrators, einen anderen DC am gleichen AD-Standort als BHS aus. Dabei wird der DC, der die niedrigste objectGUID am AD-Standort hat, zum BHS ausgewählt.
- Der Administrator kann aber auch manuell einen DC als bevorzugten BHS festlegen. Das kann beispielsweise dann von Interesse sein, wenn zwischen den AD-Standorten eine Firewall steht und nur gezielt einem bestimmten DC die standortübergreifende AD-Replikation erlaubt werden soll. Ein weiterer Anwendungsfall wäre zum Beispiel, wenn die meisten DCs an einem AD-Standort auf veralteter Hardware laufen und nur ein bestimmter DC, der auf aktueller Hardware läuft, soll als BHS bestimmt werden. Denn der BHS muss mehr Replikationsverkehr verarbeiten (insbesondere in größeren AD Umgebungen), als alle anderen DCs am selben AD-Standort.
Wird manuell ein DC an einem AD-Standort explizit als BHS für ein oder beide Replikationstransportprotokolle konfiguriert, bedeutet das bei einem Ausfall dieses BHS, dass der Administrator manuell einen anderen DC zum BHS deklarieren muss, damit die AD-Replikation weiterhin durchgeführt werden kann. Denn nur wenn ein vom ISTG bestimmter BHS ausfällt, wird automatisch ein anderer DC als BHS bestimmt. Deshalb sollte man wenn möglich, entweder keinen BHS manuell bestimmen und dem ISTG die automatische Auswahl des BHS überlassen oder wenn man schon manuell die BHS bestimmen möchte, sollten idealerweise mehrere (mindestens immer zwei) DCs als BHS bestimmt werden. In einer Gesamtstruktur mit mehreren Domänen sollte stets der globale Katalog (GC) an einem AD-Standort der bevorzugte BHS sein. Andernfalls wird das mit der FehlerID 1567 im Eventlog protokolliert. Wenn in einem Multi-Domain Forest an einem AD-Standort ein GC existiert, und sich nicht zusätzlich an demselben AD-Standort mindestens ein DC aus allen anderen AD-Domänen existiert, muss der GC zwingend ein BHS sein.
-
Es können vom Administrator mehrere DCs am gleichen AD-Standort als bevorzugte BHS bestimmt werden. Jedoch wählt der ISTG je nach Umgebung, nur aus den manuell bestimmten BHS einen oder mehrere BHS pro AD Standort aus. Fällt ein BHS aus, wählt der ISTG wieder automatisch von den anderen manuell bestimmten DCs einen BHS aus.
-
Wenn zwischen zwei DCs, die sich an verschiedenen AD-Standorten befinden, manuell ein Verbindungsobjekt erstellt wird, werden diese beiden DCs ebenfalls zu BHS.
Möchte man einen DC oder mehrere DCs als bevorzugten BHS konfigurieren, so kann man das in der MMC Active Directory-Standorte und -Dienste durchführen. Dazu wählt man aus einem AD-Standort den entsprechenden DC aus und wählt im Kontextmenü zuerst die Eigenschaften aus. Danach wählt man im Reiter Allgemein aus dem Feld Transporte für die standortübergreifende Datenübermittlung das entsprechende Replikationstransportprotokoll, entweder IP oder SMTP aus und fügt es in das Feld Server ist ein bevorzugter Bridgeheadserver für folgende Transporte hinzu. Damit wird der DC zum manuell bestimmten bevorzugten BHS.
Ist ein vom ISTG bestimmter BHS ausgefallen und möchte man bis zum nächsten KCC-Lauf nicht warten (max. 15 Minuten), kann man in der Kommandozeile mit Repadmin /KCC die Replikationstopologie manuell neu berechnen lassen und somit den ISTG dazu zwingen, einen neuen BHS zu bestimmen. Die Replikationstopologie kann man auch in der grafischen Oberfläche, in der MMC Active Directory-Standorte und –Dienste neu berechnen und somit einen neuen BHS vom ISTG bestimmen lassen. Dazu muss man mit einem Rechtsklick auf das NTDS Settings Objekt eines bestehenden DCs, im Kontextmenü unter Alle Aufgaben die Option Replikationstopologie überprüfen auswählen. Beide Vorgehensweisen fordern den KCC dazu auf, die Replikationstopologie zu überprüfen und bei etwaigen Veränderungen, diese anzupassen. Fällt dem ISTG bei einem KCC-Lauf auf, dass der BHS eines AD-Standorts nicht mehr existiert, bestimmt er einen anderen DC (falls ein weiterer DC an diesem AD-Standort existiert) an diesem AD-Standort zu einem BHS.
In der AD-PowerShell lässt sich manuell ein DC ebenfalls als einen bevorzugten BHS konfigurieren.
Der Befehl für das Bestimmen eines BHS für das IP-Protokoll lautet:
Set-ADObject -Identity „CN=<DC>,CN=Servers,CN=<AD-Standort>,CN=Sites,CN=Configuration,DC=Root-Domäne“ -Add @{ bridgeheadTransportList=”CN=IP,CN=Inter-Site Transports,CN=Sites,CN=Configuration,DC=Root-Domäne“ }
Wird ein DC manuell, für ein oder beide Replikationstransportprotokolle zu einem bevorzugten BHS bestimmt, passiert im Hintergrund folgendes:
- Im mehrwertigen Forward-Link Attribut bridgeheadTransportList, das sich in den Eigenschaften des DC-Objekts befindet, wird der Distinguished Name (DN) des entsprechenden Replikationstransportprotokolls eingetragen. Also z.B. CN=IP,CN=Inter-Site Transports,CN=Sites,CN=Configuation,DC=Root-Domäne.
- Auf der gegenüberliegenden Seite wird im mehrwertigen Back-Link Attribut bridgeheadServerListBL, das sich in den Eigenschaften des Replikationstransportprotokoll-Containers (in der MMC dssite.msc unter Sites – Inter-Site Transports - IP/SMTP) befindet, der DN des bestimmten BHS eingetragen. Beispielsweise: CN=<DC>,CN=Servers,CN=<AD-Standort>,CN=Sites,CN=Configuration,DC=Root-Domäne.
Wird ein BHS vom ISTG bestimmt, enthalten die Attribute keinen Wert!
Bei jedem Durchlauf des ISTG überprüft dieser das Attribut bridgeheadTransportList. Ist in dem Attribut der DN eines Replikationstransportprotokolls eingetragen, wird dieser DC vom KCC als der bevorzugte BHS für das eingetragene Replikationstransportprotokoll verwendet.
Im Übrigen kann man sich alle aktuellen BHS in der Kommandozeile, mit dem Schweizer Messer Werkzeug für die AD-Replikation REPADMIN folgendermaßen anzeigen lassen: Repadmin /bridgeheads
Die Auswahl und die Lastverteilung des BHS
Windows 2000
Unter Windows 2000 kann es nur einen einzigen BHS pro AD-Standort geben! Die Auswahl des BHS ändert sich unter Windows 2000 nur, wenn der bisher ausgewählte BHS nicht mehr verfügbar ist. Das Problem mit dem BHS unter Windows 2000 ist, dass der BHS in der Zentrale (Hub) schnell zu einem Engpass werden kann, wenn die AD Standorttopologie nach der Hub-and-Spoke Topologie aufgebaut wurde und viele Außenstellen (Spokes) existieren. Denn alle BHS aus allen Außenstellen führen die standortübergreifende AD-Replikation stets nur mit dem einen BHS in der Zentrale durch. Kommen weitere DCs in der Zentrale hinzu, werden diese von den BHS in den Außenstellen nicht berücksichtigt! Es existiert also weder eine Skalierung, noch eine Lastverteilung!
Windows Server 2003
Ab Windows Server 2003 wurde das Problem mit dem einzelnen BHS pro AD-Standort behoben. Von nun an kann jeder DC an einem AD-Standort zeitgleich ein BHS sein. Es können also mehrere BHS pro AD-Standort zeitgleich existieren. Wurden mehrere DCs an einem AD-Standort manuell als BHS bestimmt, beschränken sich die möglichen BHS eines AD-Standorts auf diese DCs. Somit wurde eigentlich in Bezug auf die Skalierbarkeit sowie Lastverteilung Rechnung getragen. Man muss lediglich beim manuellen bestimmen von BHS Vorsicht walten lassen. Denn BHS werden pro Verzeichnispartition und pro Replikationstransportprotokoll bestimmt. Wird beispielsweise an einem AD-Standort kein BHS für die Schemapartition bestimmt, wird diese Verzeichnispartition (auf Englisch Naming Context, kurz NC) zu diesem AD-Standort niemals repliziert.
Diese neue Funktion der Lastverteilung hat jedoch einen gravierenden Nachteil. Denn haben sich in einer Hub-and-Spoke Topologie die BHS in den Außenstellen die Replikationstopologie mit einem BHS aus der Zentrale aufgebaut, überprüfen die BHS in den Außenstellen die Replikationstopologie nicht erneut, wenn weitere BHS Kandidaten in Form von zusätzlichen DCs in der Zentrale installiert werden. Sogar wenn mehrere DCs in der Zentrale manuell als bevorzugte BHS bestimmt werden, führen die BHS in den Außenstellen die AD-Replikation weiterhin mit dem bereits ausgewählten BHS in der Zentrale durch. Die neu hinzugefügten DCs in der Zentrale werden von den BHS in den Außenstellen einfach ignoriert.
Microsoft hat dieses Fehlverhalten erkannt. Leider erst, als Windows Server 2003 RTM wurde. Somit blieb keine Zeit mehr das im Quellcode des Serverbetriebssystems zu überarbeiten. Stattdessen wurde ein Tool entwickelt, um dieses Verhalten zu korrigieren. Das Tool heist Active Directory Load Balancer, kurz adlb.exe, und befindet sich im “Windows Server 2003 Active Directory Branch Office Guide”. Führt man das Tool jedes Mal aus, nachdem ein neuer DC in der Zentrale (Hub) hinzugefügt wurde, wird unter Berücksichtigung der neuen DCs die Replikationstopologie neu berechnet und möglicherweise weitere BHS an einem AD-Standort bestimmt. Bedauerlich dabei ist, dass man das Tool jedes Mal manuell ausführen muss, nach dem ein neuer DC hinzugefügt wurde.
Das Tool selbst und weitere Informationen dazu gibt es hier:
Windows Server 2003 Active Directory Branch Office Guide
Windows Server 2008
Unter Windows Server 2008 wurde die automatische Auswahl eines BHS verbessert, leider wieder einmal mehr halbherzig. Denn unter Windows Server 2008 nutzen lediglich Read-Only Domänencontroller (RODCs) die automatische Auswahl eines BHS. Beschreibbare DCs (RWDC) dagegen verhalten sich weiterhin wie unter Windows Server 2003, was die automatische Auswahl eines BHS anbetrifft. Das bedeutet also, dass ein RODC aus einer Außenstelle die neu hinzugefügten DCs in der Zentrale als BHS berücksichtigt, ein beschreibbarer Windows Server 2008 DC jedoch nicht. Für RODCs besteht nicht die Notwendigkeit, das zusätzliche Werkzeug adlb.exe auszuführen, denn die automatische BHS Lastverteilung ist bei RODCs standardmäßig aktiviert. Doch auf beschreibbaren Windows Server 2008 DCs muss in Bezug auf die BHS Lastverteilung, weiterhin das Tool adlb.exe ausgeführt werden, damit neue DCs als mögliche BHS berücksichtigt werden.
Möchte man die automatische Lastverteilung auf RODCs deaktivieren, zum Beispiel weil sich eine Firewall zwischen dem RODC und einem beschreibbaren DC befindet und der RODC stets die AD Aktualisierungen immer nur von einem bestimmten beschreibbaren DC erhalten soll, so kann man das mit diesem Registryeintrag, der standardmäßig nicht existiert:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters
Random BH Loadbalancing Allowed
1 = Aktiviert (standardmäßig)
0 = Deaktiviert
Review Bridgehead Server Load-Balancing Improvements with Windows Server 2008 RODCs
Die verbesserte Lastverteilung der BHS unter Windows Server 2008 R2
Ab Windows Server 2008 R2 wurde die BHS Lastverteilung zusätzlich zu RODCs, für beschreibbare DCs eingeführt. RODCs und vor allem beschreibbare DCs verteilen nun Replikationsverbindungen und die standortübergreifende Replikationslast gleichmäßig zwischen allen BHS, die an einem AD-Standort zur Verfügung stehen. Kommen zum Beispiel in einer Hub-and-Spoke Topologie weitere DCs in der Zentrale (Hub) und somit potentiell neue BHS dazu, berechnen Read-Only- und beschreibbare DCs aus den Außenstellen die Replikationstopologie neu. Die Replikationslast und Replikationsverbindungen werden dann stets gleichmäßig über alle DCs in der Zentrale verteilt.
Insbesondere in größeren AD Umgebungen profitiert man von dieser Verbesserung und deshalb sollten bei einer Domänenaktualisierung auf mindestens Windows Server 2008 R2, stets die DCs in der Zentrale als erste aktualisiert werden, um von der BHS Lastverteilung zu profitieren.
Es gibt aber bei dem verbesserten Auswahlverfahren eines BHS unter Windows Server 2008 R2 folgende Einschränkungen:
- Die BHS Lastverteilung funktioniert erst, wenn sich DCs mindestens in zwei AD-Standorten (logischerweise) befinden.
- Existiert eine „Full-Mesh“ AD-Standorttopologie (jeder AD-Standort repliziert mit jedem anderen), mit denselben Kosten in allen Standortverknüpfungen, kann keine Lastverteilung durchgeführt werden. Die BHS Lastverteilung findet immer zwischen zwei AD-Standorten statt.
- Wenn der KCC zum gleichen Zeitpunkt simultan auf allen BHS in den Außenstellen läuft, wird in allen eingehenden Replikationsverbindungen derselbe BHS aus der Zentrale verwendet. Erst wenn der KCC auf den BHS zwischen den Außenstellen, mindestens eine Sekunde versetzt läuft, findet die BHS Lastverteilung statt!
Weitere Informationen:
AD-PowerShell Befehle
Die Active Directory Verbindungsobjekte
Bridgehead Server Selection
How Active Directory Replication Topology Works
Use ADLB from the Windows Server 2003 Branch Office Guide to Rebalance Connections Between Writeable Domain Controllers in the Hub
The Role of the Inter-Site Topology Generator in Active Directory Replication
Description of Bridgehead Servers in Windows 2000
Ein Verbindungsobjekt (auf Englisch: connection object) ist ein Active Directory-Objekt, das eine direkte logische Replikationsverbindung zwischen zwei Domänencontrollern (DC) darstellt. Bei den Verbindungsobjekten handelt es sich stets um unidirektionale Pull-Replikationsverbindungen. Dabei werden die Verbindungsobjekte automatisch von der Konsistenzprüfung (bekannt als Knowledge Consistency Checker, kurz KCC) erstellt und in der Konfigurationspartition, im folgenden LDAP-Pfad gespeichert:
CN=<Verbindungsobjekt>,CN=NTDS Settings,CN=<DC>,CN=Servers,CN=<AD-Standort>,CN=Sites,CN=Configuration,DC=Root-Domäne
Der KCC, der standardmäßig alle 15 Minuten die Replikationstopologie auf jedem DC neu berechnet, ist ein Active Directory Prozess. Er ist dafür zuständig, dass zum einen die Verbindung zwischen den Replikationspartnern besteht und zum anderen in der Gesamtstruktur eine effiziente sowie fehlertolerante Replikationstopologie entsteht. Dazu erstellt der KCC alle notwendigen Verbindungsobjekte. In der Regel erfordern diese keine Änderungen durch den Administrator. Die Anzahl der Verbindungsobjekte die vom KCC erstellt werden, hängt logischerweise von der Anzahl der DCs ab.
Das Merkmal eines vom KCC erstellten Verbindungsobjekts ist der Name der Replikationsverbindung. Dieser kann in der MMC Active Directory-Standorte und -Dienste (dssite.msc) überprüft werden und lautet <automatisch generiert>.
Wenn aber die vom KCC automatisch berechnete Replikationstopologie nicht den Anforderungen genügt, kann der Administrator an den Verbindungsobjekten Änderungen vornehmen. Der Administrator kann ein neues Verbindungsobjekt erstellen oder ein vom KCC erstelltes Verbindungsobjekt bearbeiten. Beides ist jedoch in den meisten Umgebungen nicht notwendig!
Das manuelle Erstellen eines neuen Verbindungsobjekts
Verbindungsobjekte können nicht nur vom KCC, sondern auch vom Administrator manuell erstellt werden. Zum Beispiel um die Replikationstopologie des Netzwerks anzupassen, oder um die Anzahl an Hops von einem DC zu einem anderen bestimmten DC zu verringern. Das hat aber einen gewaltigen Nachteil! Denn die Verbindungsobjekte, die vom KCC erstellt wurden, werden auch von diesem verwaltet. Das bedeutet, wenn Verbindungsobjekte durch den KCC erstellt werden, werden sie automatisch durch den KCC entfernt, sobald sich die Replikationstopologie ändert. Somit ist ein manuelles Eingreifen nicht erforderlich! Dahingegen werden die Verbindungsobjekte, die manuell vom Administrator erstellt wurden, nicht vom KCC entfernt, wenn sich die Replikationstopologie einmal ändern sollte. Manuell erstellte Verbindungsobjekte werden nicht vom KCC verwaltet und müssen, bei etwaigen Veränderungen in der Replikationstopologie, immer vom Administrator manuell entfernt werden. Das erfordert die Aufmerksamkeit des Administrators.
Ein vom Administrator erstelltes Verbindungsobjekt erkennt man am Namen. Wenn der Administrator ein neues Verbindungsobjekt erstellt, erhält es eine GUID als Namen, den man anschließend umbenennen kann.
Beim Erstellen eines Verbindungsobjekts muss der Quell-DC angegeben werden, von dem die AD-Änderungen repliziert werden sollen. Ist das Verbindungsobjekt erstellt, kann anschließend der Zeitplan bearbeitet werden und bei einem Verbindungsobjekt, das für die standortübergreifende AD-Replikation verwendet wird, kann zusätzlich noch das Transport-Protokoll geändert werden. In der grafischen Oberfläche wird ein Verbindungsobjekt in der MMC dssite.msc erstellt. Dort navigiert man zum AD-Standort, an dem sich der entsprechende DC befindet, wählt den DC aus und ruft mit einem Rechtsklick auf das NTDS Settings Objekt die Option „Neu à Verbindung“ auf.
Der KCC verwendet jedes manuell erstellte Verbindungsobjekt, als wenn er es selbst erstellt hätte. Gegebenenfalls führt der KCC aber eine erneute Konfiguration an den Verbindungsobjekten durch, um eventuell fehlende Verbindungsobjekte auszugleichen.
Das Bearbeiten eines vom KCC erstellten Verbindungsobjekts
Ändert der Administrator ein vom KCC erstelltes Verbindungsobjekt, erhält es als Namen ebenfalls eine GUID. Daran lässt sich in der MMC dssite.msc leicht erkennen, welche Verbindungsobjekte nicht vom KCC, sondern ausschließlich vom Administrator verwaltet werden (müssen)! Das Verbindungsobjekt lässt sich jedoch umbenennen, damit es leichter identifiziert werden kann.
In den Eigenschaften eines Verbindungsobjekts kann man den Zeitplan und den Quell-DC ändern. Im Zeitplan kann man definieren, an welchen Wochentagen, zu welcher Uhrzeit und wie oft (man hat die Wahl zwischen Keine, Einmal-, Zweimal- oder Viermal pro Stunde) die Replikation durchgeführt werden soll. Dabei muss man allerdings zwischen der standortinternen (Intra-Site) und standortübergreifenden (Inter-Site) AD-Replikation unterscheiden!
Denn standardmäßig findet die standortinterne AD-Replikation, ab dem Gesamtstrukturfunktionsmodus „Windows Server 2003“, bereits 15 Sekunden nach einer AD-Änderung statt. Bei der standortinternen AD-Replikation dient das Intervall im Verbindungsobjekt lediglich dazu, dass falls eine Änderungsbenachrichtigung durch einen Ziel-DC nicht empfangen bzw. verarbeitet werden sollte (beispielsweise wegen Überlastung), jeder DC im konfigurierten Intervall (standortintern standardmäßig „Einmal pro Stunde“) seine Replikationspartner in jedem Fall anfragt, ob es Änderungen gab. Falls ja, repliziert der Ziel-DC die AD-Änderungen als wenn er eine Änderungsbenachrichtigung erhalten hätte. Das Replikationsintervall im Intra-Site Verbindungsobjekt („Einmal pro Stunde“) wird vom NTDS Site Settings Objekt, genauer vom Attribut schedule das sich in den Eigenschaften des "NTDS Site Settings Objekt" befindet, vererbt.
Bei der standortübergreifenden AD-Replikation gilt der Zeitplan, der in der Standortverknüpfung (Site-Link) definiert ist. Dort ist festgelegt, dass standardmäßig alle 180 Minuten die standortübergreifende AD-Replikation stattfindet.
Das Intervall aus der Standortverknüpfung wird auf die Verbindungsobjekte, die für die standortübergreifende AD-Replikation verwendet werden, vererbt. Ändert man das Intervall in der Standortverknüpfung, werden automatisch die entsprechenden Verbindungsobjekte aktualisiert! Die Verbindungsobjekte werden aber weiterhin vom KCC verwaltet.
In den Eigenschaften eines Verbindungsobjekts kann man auch im Feld Replizierte Namenskontexte erkennen, welche Verzeichnispartitionen über dieses Verbindungsobjekt repliziert werden.
Ein manuell erstelltes oder bearbeitetes Verbindungsobjekt vom KCC verwalten lassen
Wurde ein Verbindungsobjekt manuell erstellt oder ein vom KCC erstelltes Verbindungsobjekt bearbeitet, trägt der Administrator die Verantwortung für dieses Verbindungsobjekt. Doch oft wird in der täglichen Praxis versehentlich eine Änderung an einem Verbindungsobjekt durchgeführt und selten steckt eine absichtlich gewollte administrative Änderung dahinter.
Die Nachteile der vom Administrator erstellten Verbindungsobjekte sind:
- Das Verbindungsobjekt bleibt weiterhin bestehen, obwohl es nicht mehr benötigt wird.
- Beim Ändern des Intervalls in der Standortverknüpfung vererbt sich die Aktualisierung nicht automatisch auf ein Verbindungsobjekt, das für die standortübergreifende AD-Replikation verwendet wird.
- Neue Anwendungsverzeichnispartitionen werden nicht automatisch repliziert.
Deshalb ist es empfehlenswert, wann immer möglich, die Verwaltung der Verbindungsobjekte dem KCC zu überlassen. Er verrichtet seine Arbeit zuverlässig und berechnet bei Veränderungen zeitnah die Replikationstopologie neu und gleicht eventuell fehlende Verbindungsobjekte aus.
Möchte man statt manuell verwalteter automatisch generierte und vom KCC verwaltete Verbindungsobjekte erhalten, so hat man folgende Möglichkeiten:
- Man löscht das manuell erstellte oder bearbeitete Verbindungsobjekt und wartet maximal 15 Minuten. Denn für den Aufbau der Replikationstopologie ist wie bereits erwähnt der KCC zuständig, der auf jedem DC alle 15 Minuten die Replikationstopologie neu berechnet. Spätestens nach 15 Minuten erstellt der KCC automatisch die notwendigen Verbindungsobjekte.
- Wer die Replikationsunterbrechung von maximal 15 Minuten nicht in Kauf nehmen kann, muss den KCC in der MMC dssite.msc manuell anstoßen, nach dem das entsprechende Verbindungsobjekt gelöscht wurde. Dazu gilt es mit einem Rechtsklick auf das NTDS Settings Objekt, unterhalb des entsprechenden DC-Objekts, die Option Replikationstopologie überprüfen unter Alle Aufgaben auszuwählen. Dadurch berechnet der KCC die Replikationstopologie sofort und erstellt die fehlenden Verbindungsobjekte.
- Auch mit dem Allroundwerkzeug für die AD-Replikation, REPADMIN, lässt sich der KCC sofort ausführen. Führt man in der Kommandozeile den Befehl REPADMIN /KCC <DC> aus, berechnet der KCC die Replikationstopologie neu und erstellt die erforderlichen Verbindungsobjekte.
Das Attribut options in den Eigenschaften eines Verbindungsobjekts
Doch die Verwaltung der manuell erstellten oder bearbeiteten Verbindungsobjekte lässt sich auch ohne das Löschen von Verbindungsobjekten und ohne eine Replikationsunterbrechung an den KCC im laufenden Betrieb übergeben! Dazu muss das options Attribut, das sich in den Eigenschaften des Verbindungsobjekts befindet, bearbeitet werden. Diese Vorgehensweise bietet sich ebenfalls für dann an, wenn man eine manuell verwaltete Replikationstopologie an den KCC übergeben und somit automatisch generierte Verbindungsobjekte erhalten möchte.
Das Attribut options im Verbindungsobjekt besteht aus einer Bitmaske, wobei die Bedeutung der Einzelnen Flags von Objektklasse zu Objektklasse variiert. Die Klassen, in denen das Attribut options existiert, sind: interSiteTransport, nTDSConnection, nTDSDSA, nTDSSiteSettings und siteLink. Wobei das options Attribut im Verbindungsobjekt wie das Verbindungsobjekt selbst zur Klasse nTDSConnection gehört.
Enthält das Attribut options den Wert 1 (Dezimal), wird das Verbindungsobjekt vom KCC verwaltet. Wird das vom KCC erstellte Verbindungsobjekt durch den Administrator geändert, ändert sich der Wert im Attribut options. Erstellt der Administrator ein Verbindungsobjekt, erhält das Attribut options den Wert 0 (Dezimal).
Das Attribut options im Verbindungsobjekt, besteht aus den folgenden Flags, wobei mehrere gleichzeitig gesetzt werden können:
- Bit 0 - Dezimal 1 – Hex 0x1 (IS_GENERATED): Das Verbindungsobjekt wird vom KCC verwaltet. Das ist der Wert, der am meisten verwendet wird.
- Bit 1 - Dezimal 2 – Hex 0x2 (TWOWAY_SYNC): Ist dieses Flag gesetzt, findet eine bidirektionale Replikation zwischen dem Quell- und Ziel-DC über ein und dasselbe Verbindungsobjekt statt, wozu ansonsten zwei Verbindungsobjekte nötig wären. Dieses Flag gibt an, dass der Ziel-DC den Quell-DC nach Abschluss der eingehenden Replikation darüber zu informieren hat, das der Quell-DC in die umgekehrte Richtung replizieren muss. Dieses Feature ist in Dial-up Szenarien interessant, in denen nur einer der beiden DCs eine DFÜ-Verbindung initiieren kann.
- Bit 2 - Dezimal 4 - Hex 0x4 (OVERRIDE_NOTIFY_DEFAULT): Mit diesem Flag werden die Benachrichtigungen überschrieben und die Replikationsdaten komprimiert.
- Bit 3 - Dezimal 8 - Hex 0x8 (USE_NOTIFY): Ist dieses Bit gesetzt, wird die Änderungsbenachrichtigung verwendet.
- Bit 4 - Dezimal 16 - Hex 0x10 (DISABLE_INTERSITE_COMPRESSION): Dieses Flag deaktiviert die Datenkomprimierung bei der standortübergreifende (Inter-Site) AD-Replikation.
- Bit 5 - Dezimal 32 - Hex 0x20 (USER_OWNED_SCHEDULE): Ist dieses Flag gesetzt, wurde vom Administrator ein benutzerdefinierter Zeitplan konfiguriert.
- Bit 6 - Dezimal 64 - Hex 0x40 (RODC_TOPOLOGY): Dieses Flag wird für die AD-Replikation zu einem RODC gesetzt. Wenn der KCC das Verbindungsobjekt eines RODCs erstellt, erhält das Attribut options den Dezimalwert 65. Der Wert 65 bedeutet, dass Bit 0 (IS_GENERATED) und Bit 6 (RODC_TOPOLOGY) gesetzt sind.
Options
Alle Verbindungsobjekte die vom Administrator verwaltet werden abfragen und vom KCC verwalten lassen
Alle Verbindungsobjekte die nicht vom KCC, sondern vom Administrator verwaltet werden und es sich nicht um ein Verbindungsobjekt eines RODCs handelt, kann man sich mit diesem AD-PowerShellbefehl Anzeigen lassen:
Get-ADObject -LDAPFilter "(&(objectCategory=nTDSConnection)(!(|(options:band:=1)(options:band:=65))))" -Properties Name -Searchbase "CN=Configuration,DC=Root-Domäne" -SearchScope Subtree | Select Name,DistinguishedName | FT -A -Wrap
Sollen alle manuell verwalteten Verbindungsobjekte ab sofort vom KCC verwaltet werden, so kann man das durch diesen AD-PowerShellbefehl erreichen:
Get-ADObject -LDAPFilter "(&(objectCategory=nTDSConnection)(!(|(options:band:=1)(options:band:=65))))" -Properties options -Searchbase "CN=Configuration,DC=Root-Domäne" -SearchScope Subtree | Set-ADObject -Replace @{options=1}
Übrigens kann man sich mit dem Befehl Repadmin /showconn <DC>, alle Verbindungsobjekte vom angegebenen DC anzeigen lassen.
Weitere Informationen:
Die Vektoren zur Steuerung der AD-Replikation
Die dringende AD-Replikation
Die Inter-Site (standortübergreifende) Änderungsbenachrichtigung aktivieren
Die Linked Value Replikation (LVR)
Zwei wichtige IDs eines DCs: DC GUID und InvocationId
Die unterschiedliche Größe der AD-Datenbank
Domänencontroller vergleichen
Die Active Directory-Replikation stellt sicher, dass der Datentransfer zwischen Verzeichnispartitionen auf unterschiedlichen Domänencontrollern (DCs) ordnungsgemäß durchgeführt wird. Dabei achtet das AD zum einen darauf, dass bei der Replikation keine Endlosschleifen entstehen und zum anderen, die AD-Daten unabsichtlich nicht repliziert werden. Deshalb enthält jede Verzeichnispartition mehrere Replikationsmetadaten, die sich auf die Replikation der jeweiligen Verzeichnispartition beziehen. Anhand der Replikationsmetadaten verwalten die DCs den Datentransfer von Verzeichnisänderungen. Denn neben der Übertragung der eigentlichen Daten, werden vom AD zusätzliche Informationen zu dieser Änderung übertragen. In den zusätzlichen Informationen sind unter anderem die Informationen zu dem DC enthalten, auf dem die ursprüngliche Änderung durchgeführt wurde, das Datum und die Uhrzeit der Änderung.
Da es sich bei der AD-Replikation um einen hochkomplexen Vorgang handelt, benötigen die DCs einen Mechanismus, der sicherstellt, dass zwischen zwei DCs nur die erforderlichen Änderungen repliziert werden. Dazu ist es notwendig, dass die DCs Änderungen, die noch nicht repliziert wurden, ermitteln können und sofern vorhanden, anschließend nur diese erforderlichen Änderungen replizieren. Ohne einen solchen Mechanismus würde jeder DC bei jeder AD-Replikation die komplette AD-Datenbank replizieren. Deshalb verwendet das AD für die Replikationsverwaltung eine Kombination aus der Update Sequence Number (USN), den beiden Vektoren High-Watermark Vector (HWMV) sowie Up-To-Dateness Vector (UTDV) und dem Änderungsstempel, bestehend aus der Versionsnummer (versionID) und dem Zeitstempel.
Aktualisierungstypen
Auf einem beschreibbaren DC können zwei Arten von Aktualisierungen an den AD-Informationen durchgeführt werden. Dabei handelt es sich um die ursprüngliche Aktualisierung (originating update) und um die replizierte Aktualisierung (replicated update).
Eine ursprüngliche Aktualisierung (auch bekannt als Ursprungsschreibvorgang) findet auf einem DC stets dann statt, wenn ein AD-Objekt bearbeitet, gelöscht, hinzugefügt oder verschoben wird.
Eine replizierte Aktualisierung findet hingegen dann statt, wenn die auf einem anderen DC durchgeführten AD-Änderungen auf den lokalen DC repliziert werden. Zwischen dem DC, auf dem die Aktualisierung durchgeführt wurde und seinen direkten Replikationspartnern muss es sich dabei nicht unbedingt um eine direkte eins-zu-eins Replikation handeln. Eine einzelne, replizierte Aktualisierung hat möglicherweise ihren Ursprung in einer Reihe von ursprünglichen Aktualisierungen auf demselben Objekt. Diese ursprünglichen Aktualisierungen können durchaus auch auf verschiedenen DCs durchgeführt worden sein. Beispielsweise wird auf DC1 im Benutzerobjekt Yusuf die Beschreibung und zur gleichen Zeit wird im selben Benutzerobjekt auf DC2 die Mailadresse geändert. DC3 erhält nun die Änderungen die im Benutzerobjekt Yusuf vorgenommen wurden separat von DC1 und DC2. Anschließend erhält DC4 von DC3 alle Änderungen durch eine einzige replizierte Aktualisierung.
Es findet also per se für jede beliebige Änderung im AD immer eine ursprüngliche Aktualisierung auf dem DC statt, auf dem die Änderung durchgeführt wurde. Alle anderen DCs erhalten die ursprüngliche Aktualisierung dann über die AD-Replikation aber nur dann, wenn sie ein Replikat der entsprechenden Verzeichnispartition besitzen. Dabei handelt es sich bei jeder ursprünglichen Aktualisierung im AD um eine vollständige Transaktion. Entweder wird der gesamte Ursprungsschreibvorgang in die AD-Datenbank übernommen oder nichts!
Die Update Sequence Number (USN)
Für die AD-Replikation ist es elementar zu erkennen, welche Daten sich geändert haben und infolgedessen repliziert werden müssen. Dabei basiert die Erkennung der Daten die repliziert werden müssen, auf der Update Sequence Number (USN), zu Deutsch Aktualisierungssequenznummer. Die USN ist ein 64Bit Wert und wird zum schnellen Auffinden indiziert. Ein Quell-DC verwendet USNs um festzustellen, welche Änderungen bei seinen direkten Replikationspartnern, die von ihm die aktuellsten Änderungen anfordern, bereits eingegangen sind. Der Ziel-DC wiederum verwendet USNs, um zu bestimmen, welche Änderungen er von seinem Replikationspartner benötigt, die er sich dann per Pull-Replikation repliziert. Jedes Attribut in jedem Objekt hat bereits seine eigene USN!
Jeder ursprünglichen und replizierten Aktualisierung wird automatisch eine fortlaufende DC-spezifische USN zugewiesen und diese hat im Vergleich mit anderen DCs, keine Bedeutung. Wenn zum Beispiel bei einem Benutzer die E-Mailadresse (das Attribut mail) auf DC01 geändert wird, erhält die Aktualisierung der Mailadresse auf diesem DC die USN 9530. Nach der Replizierung dieser Änderung, vergibt der direkte Replikationspartner DC02 derselben Mailadresse die USN 43643. Die nächste Änderung auf DC01 würde die USN 9531 erhalten, unabhängig vom geänderten Objekt.
Die USN der einzelnen Attribute eines bestimmten Objekts, auf einem bestimmten DC, kann man sich mit dem Kommandozeilentool REPADMIN wie folgt anzeigen lassen: Repadmin /showobjmeta <DC> "<DN des entsprechenden Objekts>“. Die USN der Attribute, sind in der Repadmin-Ausgabe, in der Spalte Lok.USN zu sehen.
Lässt man sich mit demselben Befehl die USNs der Einzelnen Attribute desselben Objekts von einem anderen DC anzeigen, so erkennt man, dass sich die USNs der Attribute komplett unterscheiden.
Beide DCs besitzen zwar erkennbar über komplett verschiedene USNs für dasselbe Objekt, aber das ist in Bezug auf die AD-Replikation einer Änderung Bedeutungslos.
Werden stattdessen während einer Aktualisierung mehrere Attribute eines Objekts gleichzeitig geändert (z.B. die Straße, Postfach, Ort, Bundesland, Postleitzahl und Land eines Benutzers), erhält jedes geänderte Attribut dieselbe USN. Somit wird der gesamten Aktualisierung nur eine einzige USN zugewiesen.
Welche drei Möglichkeiten für die Zuweisung einer USN gibt es?
Wird eine Änderung im AD vorgenommen, gibt es drei Möglichkeiten für die Zuweisung einer USN. Die erste wäre, der lokale USN-Wert wird mit dem geänderten Attribut gespeichert. Im geänderten Attribut wird die USN mit dem lokalen USN Wert gekennzeichnet. Führt man diesen REPADMIN-Befehl aus Repadmin /showobjmeta <DC> "<DN des entsprechenden Objekts>“, sieht man den lokalen USN Wert der Einzelnen Attribute in der Spalte Lok.USN.
Als nächstes wird die USN für das indizierte Attribut uSNChanged im geänderten Objekt verwendet. Das system only Attribut uSNChanged, das in jedem Objekt enthalten ist, kennzeichnet die höchste USN für jedes beliebige Attribut des Objekts. Oder anders ausgedrückt, das Attribut uSNChanged enthält die USN für die letzte Änderung an einem Objekt, die auf diesem DC durchgeführt wurde. Dabei wird die lokale USN, zusammen mit dem Attribut uSNChanged sowohl bei einer ursprünglichen Aktualisierung, als auch bei einer replizierten Aktualisierung angewendet. Durch beide Aktualisierungstypen wird die lokale USN und das Attribut uSNChanged eines DCs erhöht! Wenn beispielsweise die Mailadresse (das Attribut mail) eines Benutzers geändert wird, erhält zum einen das Attribut mail, als auch das Attribut uSNChanged denselben USN Wert, z.B. 6700. Wird anschließend die Beschreibung (das Attribut description) im selben Benutzerobjekt, auf demselben DC geändert, erhält die lokale USN des Attributs description als auch uSNChanged im Benutzerobjekt denselben Wert, also 6701. Der Wert in der lokalen USN des Attributs mail bleibt jedoch weiterhin auf 6700 bestehen, da diese USN bei der letzten Änderung dem Attribut mail auf diesem DC zugeordnet wurde.
Wenn man in der MMC Active Directory-Benutzer und -Computer (dsa.msc) unter Ansicht die Option „Erweiterte Features“ aktiviert, findet man anschließend in den Eigenschaften eines Objekts, im Reiter Objekt, unter anderem die aktuelle USN (das Attribut uSNChanged) des Objekts.
Und zuletzt wird die USN im originating USN, auf Deutsch im ursprünglichen USN Wert gespeichert, die im Up-To-Dateness Vector (UTDV) verwendet wird. Dieser Wert wird nur bei einer ursprünglichen Aktualisierung festgelegt. Bei einem Ursprungsschreibvorgang auf einem DC, wird die neue USN mit jedem aktualisierten Attribut im lokalen USN Wert und zusätzlich im ursprünglichen USN Wert gespeichert. Im Gegensatz zur lokalen USN und dem Attribut uSNChanged, wird die ursprüngliche USN mit dem Wert des aktualisierten Attributs repliziert. Führt man den Befehl Repadmin /showobjmeta <DC> "<DN des entsprechenden Objekts>“ auf einem deutschen DC aus, findet man die ursprüngliche USN in der Spalte Ur. USN. Wenn zum Beispiel die Straße im Benutzerobjekt Yusuf auf dem DC geändert wird, erhält im Attribut streetAddress die lokale USN, die ursprüngliche USN und das Attribut uSNChanged denselben Wert!
Wird nun die geänderte Straße repliziert, wird neben dem geänderten Attribut streetAddress auch die ursprüngliche USN repliziert, die im Übrigen auf dem Ziel-DC nicht geändert wird. Auf dem Ziel-DC wird aber die lokale USN und das Attribut uSNChanged bearbeitet, da beide Werte DC-spezifisch sind. Die ursprüngliche USN wird so lange nicht geändert, bis das Attribut erneut aktualisiert wird.
Man kann erkennen, dass das Benutzerobjekt Yusuf Dikmenoglu auf dem R2DCON01 erstellt und das Attribut streetAddress am 25.08.2010 um 23:15:46 Uhr auf dem R2DCON02 geändert wurde.
Die höchste USN eines DCs
Jeder DC merkt sich auch in einem eigens dafür vorgesehenen Attribut, welche USN er als letztes einer lokalen AD-Änderung zugewiesen hat. Dabei kann eine lokale AD-Änderung durch eine ursprüngliche und replizierte Aktualisierung stattfinden. Die aktuelle USN eines DCs, sprich die letzte bestätigte bzw. zugewiesene USN des DCs, wird im Attribut highestCommittedUSN gespeichert. Dieses Attribut befindet sich in den Eigenschaften des rootDSE-Objekts, wobei jeder DC sein eigenes rootDSE Objekt besitzt. Mit anderen Worten: Das Attribut highestCommittedUSN enthält die höchste USN auf diesem DC!
Der Wert im Attribut highestCommittedUSN ändert sich bereits, sobald ein DC gestartet wird. Denn es werden Änderungen an der AD-Datenbank durchgeführt, auch ohne dass ein Administrator Änderungen im AD vorgenommen hat. Daher kann es sein, dass sich der Wert im Attribut highestCommittedUSN nach zwei hintereinander durchgeführten Änderungen um mehrere und nicht nur um eine einzige USN unterscheidet.
Mit REPADMIN kann man sich die höchste USN auf einem DC wie folgt Anzeigen lassen:
Repadmin /showattr <DC> "" /atts:highestCommittedUSN
Von allen DCs aus der Domäne kann man sich die Werte mit diesem Befehl anzeigen lassen:
Repadmin /showattr * "" /atts:highestCommittedUSN
Mit der AD-PowerShell kann man sich den Wert aus dem Attribut highestCommittedUSN von einem DC folgendermaßen anzeigen lassen:
Get-ADRootDSE –Server <DC> | Select highestCommittedUSN | FL
Natürlich kann man sich das Attribut highestCommittedUSN ebenfalls mit LDP anzeigen lassen. Dazu genügt es sich in LDP lediglich mit einem DC zu verbinden. Danach erhält man alle Einträge, unter anderem das Attribut highestCommittedUSN, aus dem rootDSE-Objekt von dem DC, mit dem man sich in LDP verbunden hat.
Dank des Attributs highestCommittedUSN, kann man sich die letzten durchgeführten Änderungen auf einem DC anzeigen lassen. Möchte man sich die letzten 500 Änderungen an der AD-Datenbank auf einem bestimmten DC anzeigen lassen, so kann man dies mit einem LDIFDE-Export herausfinden. Der LDIFDE-Befehl zum Export lautet wie folgt:
Ldifde /d „DC=<Domäne>,DC=<TLD> /s <DC> /x /r „(uSNChanged>=<Wert>)” /f C:\USNÄnderungen.txt
Nicht so schnell! Vorher muss man natürlich die aktuelle (höchste) USN des DCs in Erfahrung bringen. Daher gilt es zuerst eine Abfrage nach dem Attribut highestCommittedUSN durchzuführen. Mit der AD-PowerShell kann man die aktuelle USN wie folgt in Erfahrung bringen:
Get-ADRootDSE | Select highestCommittedUSN | FL
Enthält das Attribut highestCommittedUSN als Wert 5500, muss man lediglich im Ldifde-Filter „(uSNChanged>=5000)” angeben und schon werden die letzten 500 Änderungen, die in der AD-Datenbank dieses DC durchgeführt wurden, exportiert.
Der High-Watermark Vector (HWMV)
Der HWMV (auch bekannt als direct up-to-dateness vector) ist ein Mechanismus, der vom AD bei der Replikation der AD-Informationen verwendet wird, um die Replikation effizient und bandbreitenschonend durchzuführen. Der HWMV dient auch zur Ressourcenschonung, denn es verringert während einer AD-Replikation die CPU-Zeit und die Anzahl an Festplatten I/O eines DCs.
Durch den HWMV können die zwischen den DCs zu replizierenden AD-Informationen bestimmt werden. Dadurch ist es anderen DCs möglich, Änderungen basierend auf einer speziellen USN von einem Replikationspartner anzufordern.
Die Basis für den High-Watermark Vector stellt die USN einer Verzeichnispartition dar. Dabei erhöht sich der HWMV einer Verzeichnispartition auf einem DC, durch beide Aktualisierungstypen.
Der HWMV wird vom Ziel-DC für jede Verzeichnispartition und für jeden seiner direkten Replikationspartner verwaltet. Jeder DC verwaltet für jede Verzeichnispartition die er hält, eine HWMV-Tabelle. In der HWMV-Tabelle ist die höchste replizierte USN (also der HWMV) der entsprechenden Verzeichnispartition, von allen eingehenden direkten Replikationspartnern gespeichert. Mit dem HWMV verfolgt der Ziel-DC in seiner HWMV-Tabelle, welche Änderung, aus welcher Verzeichnispartition, er bereits von einem bestimmten Replikationspartner erhalten hat.
Jeder DC der kein GC ist, verwaltet je eine HWMV-Tabelle für die Schemapartition, Konfigurationspartition, Domänenpartition sowie für die beiden DNS Anwendungsverzeichnispartition (ab Windows Server 2003) „ForestDNSZones“ und „DomainDNSZones“, also insgesamt fünf HWMV-Tabellen. Ein GC in einer Gesamtstruktur mit mehreren Domänen, verwaltet zusätzlich je eine HWMV-Tabelle für jede andere Domänenpartition.
Doch letztlich handelt es sich bei dem HWMV lediglich um den aktuellen Wert im Attribut uSNChanged, den der Ziel-DC von einem bestimmten Replikationspartner erhalten hat! Wird eine Aktualisierung an einem Objekt durchgeführt, erhält automatisch auch das Attribut uSNChanged im geänderten Objekt einen höheren Wert. Der Quell-DC repliziert dann zusätzlich neben der eigentlichen Aktualisierung, das Attribut uSNChanged des zuletzt geänderten Objekts zum Ziel-DC. Der Ziel-DC wiederum, trägt den Wert aus dem mitgesendeten Attribut uSNChanged für seinen Replikationspartner, als den HWMV für die entsprechende Verzeichnispartition in seine HWMV-Tabelle ein. Und obwohl das Attribut uSNChanged mit der Aktualisierung zum Ziel-DC repliziert wurde, erhält das Attribut uSNChanged im selben Objekt auf dem Ziel-DC, nicht denselben Wert den der Quell-DC mitgeschickt hat!
Im HWMV wird neben weiteren Replikationsmetadaten, der Datenbank-GUID (Globally Unique Identifier) und der objectGUID, die beide in der Gesamtstruktur einmalig sind, und nicht der Computername des Remote-DCs gespeichert. Dadurch das sich der objectGUID zu Lebzeiten eines DCs niemals ändert, kommt es auch nicht zu Problemen, wenn sich der Computername eines DCs ändert. Bei dem Datenbank-GUID handelt es sich um das Attribut invocationId und dieser befindet sich so wie der objectGUID in der Konfigurationspartition, in den Eigenschaften des NTDS Settings Objekts eines DCs. Der LDAP-Pfad lautet: CN=NTDS Settings,CN=<DC>,CN=Servers,CN=<AD-Standort>,CN=Sites,CN=Configuration,DC=Root-Domäne.
Zwei wichtige IDs eines DCs: DC GUID und InvocationId
Den High-Watermark Vector anzeigen
Führt man den REPAMIN-Befehl Repadmin /showrepl /verbose aus, wird in der Ausgabe die HWMV USN neben dem Eintrag „/OU“ (steht für object update), für jede Verzeichnispartition von jedem Replikationspartner (und nicht der eigene HWMV!) angezeigt. Der Wert der mit der Angabe von „/OU“ angezeigt wird, ist der echte HWMV für die entsprechende Verzeichnispartition des Replikationspartners! Die object update USN ist der tatsächliche HWMV der benötigt wird, um die Attribute bzw. Objekte in der entsprechenden Verzeichnispartition zu bestimmen, die repliziert werden müssen.
Den Fortschritt innerhalb eines Replikationszyklus zeigt die object update USN an (gibt an ob gerade repliziert wird) und der USN-Wert bei „/PU“ (steht für property update), zeigt den letzten erfolgreich durchgeführten(!) Replikationszyklus an. Am Ende eines Replikationszyklus lautet die USN im object update und im property update gleich. Existiert bei /PU kein Wert, bedeutet das, dass die AD-Replikation noch nie erfolgreich durchgeführt wurde, wie es bei der Erstsynchronisation eines neuen DCs der Fall sein kann. Wenn sich die Werte im object update und im property update unterscheiden, bedeutet dies, dass ein Replikationszyklus im Gange ist. Die beiden Werte „/OU“ und „/PU“, die das Repadmin ausliest, stammen vom Attribut repsFrom. Das mehrwertige, optionale (system only) Attribut repsFrom wird nicht zwischen den DCs repliziert (aber in den GC schon) und befindet sich in den Eigenschaften der entsprechenden Verzeichnispartition! In dem Attribut ist von jedem Replikationspartner neben weiteren Replikationsmetadaten der HWMV (nicht der eigene!), gespeichert. Zum Anzeigen der Werte aus repsFrom eignet sich LDP.
Die Replikationsmetadaten eines Objekts anzeigen
Die Replikationsmetadaten eines Objekts kann man sich mit einer Abfrage nach dem mehrwertigen (multivalue) constructed Attribut msDS-ReplAttributeMetaData anzeigen lassen. Dieses Attribut zeigt die Metadaten für jedes replizierte Attribut im XML Format an. Aus den Metadaten erfährt man unter anderem, auf welchem DC ein Attribut geändert wurde. Mit REPADMIN kann man sich die Replikationsmetadaten eines Objekts folgendermaßen anzeigen lassen:
Repadmin /showattr <DC> "<DN des Objekts>" /atts: msDS-ReplAttributeMetaData
In der AD-PowerShell lautet die Abfrage wie folgt:
Get-ADObject -Server <DC> "<DN des Objekts>" -Properties msDS-ReplAttributeMetaData
Im Folgenden einfachen Beispiel wird gezeigt, was es mit dem HWMV auf sich hat
1. In einer Domäne existieren zwei DCs: DC01 und DC02. Der aktuelle HWMV der Domänenpartition von DC01 ist 20500 und von DC02 37250. In der HWMV-Tabelle auf DC01 ist der HWMV der Domänenpartition von DC02 gespeichert. Dieser lautet wie bereits genannt: 37250. In der HWMV-Tabelle für die Domänenpartition auf DC02 ist wiederum gespeichert, dass der HWMV der Domänenpartition von DC01 20500 ist.
2. Wird nun auf dem Quell-DC DC02 ein Benutzer erstellt (es wird eine ursprüngliche Aktualisierung in der Domänenpartition durchgeführt), erhöht sich der lokale HWMV der lokalen Domänenpartition von DC02, auf den neuen Wert 37258. Da aber DC01 von DC02 noch nicht benachrichtigt wurde, dass Änderungen vorliegen und demzufolge die AD-Replikation noch nicht stattgefunden hat, ist weiterhin in der HWMV-Tabelle auf DC01 als HWMV Wert für die Domänenpartition auf DC02 37250 gespeichert. Erst wenn die AD-Replikation stattgefunden hat, aktualisiert DC01 seine HWMV-Tabelle.
3. Innerhalb eines AD-Standorts versendet DC02 ab dem Gesamtstrukturfunktionsmodus Windows Server 2003 nach 15 Sekunden eine Änderungsbenachrichtigung (change notification) an DC01. Standortübergreifend wird die Benachrichtigung, dass Änderungen vorliegen, nach dem in der Standortverknüpfung konfigurierten Zeitplan verschickt. Zur Erinnerung: Bei der AD-Replikation findet per se eine Pull-Replikation und keine(!) Push-Replikation statt! Wenn DC01 die Benachrichtigung erhalten hat, dass Änderungen auf DC02 verfügbar sind, initiiert DC01 die AD-Replikation. DC01 sendet neben weiteren Replikationsmetadaten, die detaillierter im folgenden UTDV-Beispiel aufgelistet werden, den HWMV an DC02, der für DC02 in der HWMV-Tabelle auf DC01 gespeichert ist.
4. Nun, da DC02 den HWMV für die Domänenpartition kennt, den DC01 in seiner HWMV-Tabelle für DC02 gespeichert hat, sendet DC02 die Änderungen zwischen den HWMV-Werten 37250 und 37258. Letzten Endes also das Benutzerobjekt. Zeitgleich aktualisiert der Ziel-DC DC01 seinen lokalen HWMV für die Domänenpartition von 20500 auf 20508, sowie den HWMV von DC02 in seiner HWMV-Tabelle auf 37258.
Wenn es jetzt keinen anderen Mechanismus als den HWMV gäbe, würde die Änderung die gerade zu DC01 repliziert wurde, wieder zurück zu DC02 repliziert werden. Schließlich hat sich auf DC01 durch die replizierte Aktualisierung der lokale HWMV der Domänenpartition erhöht. Das bedeutet im Umkehrschluss, dass Änderungen auf DC01 vorliegen die angeblich repliziert werden müssen. Damit es zu genau dieser Endlosschleife nicht kommt, gibt es einen weiteren Vektor, nämlich den Up-To-Dateness Vector.
Der Up-To-Dateness Vector (UTDV)
So wie beim HWMV, stellt die USN die Basis für den Up-To-Dateness Vector dar. Der Up-To-Dateness Vector ist ein weiterer Mechanismus der ebenfalls dazu dient, die zu replizierenden AD-Informationen zwischen den DCs zu verwalten, damit die AD-Replikation effizient durchgeführt werden kann. Der UTDV verhindert, dass dieselbe Änderung, die der DC erhalten hat, permanent zurück repliziert wird und dadurch eine Endlosschleife entsteht. Deshalb spricht man beim UTDV auch von Propagierungsdämpfung.
Durch den Up-To-Dateness Vector (auf Deutsch Aktualitätsvektor), auch bekannt als Up-To-Date Vector, verfolgt der Ziel-DC die ursprünglichen Aktualisierungen (originating update) in allen Verzeichnispartitionen, die er von beliebigen DCs erhalten hat. Der lokale UTDV eines DCs erhöht sich dabei nur, wenn der DC selbst eine Änderung im AD, also eine ursprüngliche Aktualisierung in der lokalen AD-Datenbank durchführt. Erhält der DC eine replizierte Aktualisierung, erhöht sich lediglich sein lokaler HVMW, aber nicht der lokale UTDV! Den UTDV eines anderen DCs kennt ein DC nur dann, wenn der Quell-DC eine ursprüngliche Aktualisierung in einer Verzeichnispartition die auch auf dem Ziel-DC existiert, durchgeführt hat und die Änderung repliziert wird (was standardmäßig immer der Fall ist).
Genau wie bei den HWMV-Tabellen verwaltet jeder DC zusätzlich je eine UTDV-Tabelle für jede Verzeichnispartition, die ein DC hält. In den entsprechenden UTDV-Tabellen wird jeder beschreibbare DC aufgelistet, der jemals eine ursprüngliche Aktualisierung in einer Verzeichnispartition durchgeführt hat, was in der Praxis auf jeden beschreibbaren DC in fast allen Verzeichnispartitionen zutrifft. In einer UTDV-Tabelle speichert jeder DC die Datenbank-GUIDs (das Attribut invocationId) der Replikationspartner. Des Weiteren werden die Einträge in den entsprechenden UTDV-Tabellen für die Lebensdauer einer Verzeichnispartition verwaltet, unabhängig davon, ob der DC oder die Verzeichnispartition vom DC bereits entfernt wurde.
Jeder DC, der kein GC ist, verwaltet je eine UTDV-Tabelle für die Schemapartition, Konfigurationspartition, Domänenpartition sowie für die beiden DNS Anwendungsverzeichnispartition (ab Windows Server 2003) „ForestDNSZones“ und „DomainDNSZones“, also insgesamt fünf UTDV-Tabellen. Ein GC in einer Gesamtstruktur mit mehreren Domänen verwaltet zusätzlich je eine UTDV-Tabelle für jede andere Domänenpartition.
Für die gesamtstrukturweiten Verzeichnispartitionen Schemapartition, Konfigurationspartition sowie die Anwendungsverzeichnispartition ForestDNSZones verfolgt ein DC in der jeweiligen UTDV-Tabelle den UTDV für alle DCs in der Gesamtstruktur. Im Grunde verfolgen bei der Schemapartition alle DCs einer Gesamtstruktur lediglich den UTDV eines DCs, nämlich den vom Schemamaster. Der Schemamaster ist der Einzige DC, der in der Schemapartition Änderungen durchführen darf. Was die Konfigurationspartition und die DNS Anwendungsverzeichnispartition „ForestDNSZones“ anbetrifft, verfolgt jeder DC den UTDV, jedes DCs in der Gesamtstruktur. Denn jeder DC erstellt Objekte in der Konfigurationspartition (z.B. Verbindungsobjekte) und jeder DC erstellt SRV-Einträge in der Anwendungsverzeichnispartition „ForestDNSZones“, genauer in der Forward Lookup Zone _msdcs.Root-Domäne.de. Für die Domänenpartition und für die DNS Anwendungsverzeichnispartition „DomainDNSZones“, verwaltet jeder DC den UTDV in der entsprechenden UTDV-Tabelle, für jeden anderen DC in der Domäne. Ein GC in einer Gesamtstruktur mit mehreren Domänen, verfolgt zusätzlich die Up-To-Dateness Vektoren für jeden DC aus den anderen Domänenpartitionen.
Genau genommen spiegelt das Attribut highestCommittedUSN aus dem rootDSE-Objekts eines DCs den lokalen UTDV eines DCs wieder. In dem Attribut highestCommittedUSN speichert der DC die letzte bestätigte und somit die höchste USN eines DCs, die einer lokalen AD-Änderung zugewiesen wurde.
Den Up-To-Dateness Vector anzeigen
Die Up-To-Dateness Vektoren, die ein bestimmter DC für eine Verzeichnispartition von seinen direkten und transitiven Replikationspartnern in seiner UTDV-Tabelle gespeichert hat, kann man sich mit dem Kommandozeilenbefehl Repadmin /showutdvec <DC> <DN der Verzeichnispartition> anzeigen lassen. Der Befehl listet auf dem angegebenen DC die eigene höchste USN und die höchste USN seiner direkten sowie transitiven Replikationspartner für die angegebene Verzeichnispartition auf, die zum Zeitpunkt der Abfrage in seiner lokalen UTDV-Tabelle gespeichert sind.
Repadmin /showutdvec
Führt man den Kommandozeilenbefehl Repadmin /showutdvec <DC> <DN der Root-Domäne> auf einem DC in der Root-Domäne aus, werden die UTDV für die Domänenpartition nur von allen DCs der Root-Domäne angezeigt und nicht der GC aus der Subdomäne! Denn wie bereits geschrieben, verfolgt der UTDV nur die ursprüngliche Aktualisierung, die innerhalb einer Verzeichnispartition durchgeführt wurde, und deshalb erscheint bei der Abfrage auf dem DC in der Root-Domäne der GC aus der Subdomäne nicht auf. Ein GC hat nur das Schreibrecht in der Domäne und somit nur in der Domänenpartition, in der er selbst Mitglied ist. Es werden zwar in einem Multi-Domain Forest alle Domänenpartitionen in den GC repliziert, jedoch besitzt der GC in allen anderen Domänenpartitionen nur das Leserecht! Erst wenn man denselben(!) Repadmin-Befehl auf einem DC in der Subdomäne ausführt, wird neben den DCs der Root-Domäne auch der GC der Subdomäne angezeigt.
Das Attribut, in dem die Up-To-Dateness Vektoren der Replikationspartner gespeichert sind
Jeder UTDV ist in dem system only Attribut replUpToDateVector gespeichert, das nicht zwischen den DCs repliziert wird (aber in den GC schon) und sich in den Eigenschaften einer Verzeichnispartition befindet. In diesem Attribut werden die UTDV von allen Replikationspartnern gespeichert, die jemals eine ursprüngliche Aktualisierung in der entsprechenden Verzeichnispartition durchgeführt und repliziert haben. In dem Attribut ist aber nicht der eigene UTDV gespeichert!
Am einfachsten lassen sich die Werte des Attributs, mit LDP anzeigen. Nach dem man sich in LDP zuerst mit einem DC verbunden und anschließend mit dem AD "Gebunden" hat, kann man sich unter Durchsuchen - Suchen die Werte aus dem Attribut replUpToDateVector für die angegebene Verzeichnispartition anzeigen lassen.
Möchte man in Erfahrung bringen, welche DCs hinter den Datenbank-GUIDs stecken die einem das LDP anzeigt, so kann man das leicht herausfinden. Dazu sollte man zuerst den Repadmin-Befehl Repadmin /showutdvec <DC> <DN der Verzeichnispartition> ausführen. Bei diesem Befehl werden die Computernamen der DCs angezeigt. Wenn anschließend der gleiche Befehl, mit dem Parameter /nocache ausgeführt wird, werden die Datenbank-GUIDs angezeigt. Anhand der UTDV Werte kann man dann sehen, hinter welchem Computernamen welche Datenbank-GUID steckt.
Anhand eines einfachen Beispiels, wird die Funktionsweise des UTDV gezeigt
1. In einer Domäne existieren drei DCs: DC01, DC02 und DC03. Der aktuelle HWMV der Domänenpartition von DC01 ist 20508, von DC02 37258 und von DC03 39270. Der aktuelle UTDV von DC01 ist 20508, von DC02 37258 und von DC03 39270. In den HWMV- und den UTDV-Tabellen auf allen DCs, sind jeweils die aktuellen Werte der anderen beiden DCs gespeichert.
2. Angenommen ein Administrator ändert auf dem Quell-DC DC01 im Benutzerobjekt Yusuf die Beschreibung. Es findet also eine einzelne ursprüngliche Aktualisierung auf DC01 statt und dieser weist dem Attribut description die lokale und ursprüngliche USN 20509 zu.
Der Wert 20509 wird als lokaler HWMV und UTDV für die Domänenpartition und im Attribut highestCommittedUSN auf DC01 gespeichert. Denn das ist zu diesem Zeitpunkt, die letzte bestätigte und höchste USN auf DC01.
3. DC01 versendet nach 15 Sekunden eine Änderungsbenachrichtigung zu DC02 und nach weiteren drei Sekunden zu DC03 und informiert beide DCs, dass Änderungen in der Domänenpartition vorliegen, die repliziert werden müssen.
4. Im Gegenzug senden die Ziel-DCs DC02 sowie DC03, die folgenden Informationen zum Quell-DC DC01:
-
Die Verzeichnispartition, in diesem Fall die Domänenpartition, in der die Änderung durchgeführt wurde.
-
Die maximale Anzahl der angeforderten Objekte.
-
Die maximale Anzahl der angeforderten Werte.
-
Den HWMV für die Domänenpartition vom Quell-DC DC01, den die Ziel-DCs DC02 und DC03 in ihren HWMV-Tabellen für DC01 gespeichert haben. Anhand des mitgesendeten HWMV erkennt der Quell-DC DC01, welche Änderungen die Ziel-DCs bereits besitzen und repliziert nur die aktuellsten Änderungen. Das bedeutet, es werden lediglich die Änderungen mit einer größeren USN, als der mitgesendete HWMV angefordert (in dem Beispiel, alle Änderungen ab der HWMV USN 20508), sofern der UTDV den Vorgang nicht verwirft.
-
Die Ziel-DCs senden ihre gesamte UTDV-Tabelle der entsprechenden Verzeichnispartition zum Quell-DC. Die UTDV-Tabelle enthält einen Eintrag für jeden DC, der ein vollständiges Replikat der Verzeichnispartition hält. Für die Domänenpartition sind es alle DCs der Domäne, für die Konfigurationspartition sind es alle DCs der Gesamtstruktur usw.
5. Der Quell-DC DC01 wiederum, antwortet dann unter anderem mit diesen Informationen:
-
Die DC-GUID (das Attribut objectGUID) von DC01.
-
Die Datenbank-GUID (das Attribut invocationId) von DC01.
-
Eine Reihe von Einträgen, die die Objektaktualisierung betreffen.
-
Der höchste uSNChanged Wert. Diesen Wert trägt der Ziel-DC in seine HWMV-Tabelle, als den aktuellen HWMV Wert für den Quell-DC ein.
-
Den UTDV von DC01
6. Findet nun die eigentliche Pull-Replikation vom Quell DC DC01 zu den Ziel-DCs DC02 und DC03 statt, wird neben dem aktualisierten Attribut description auch die ursprüngliche USN 20509 zu den Ziel-DCs repliziert.
7. Wenn die Ziel-DCs diese Änderung erhalten, aktualisieren sie in ihrer HWMV- und UTDV-Tabelle der Domänenpartition, die Werte für den Quell-DC DC01 auf den neuen Wert 20509. Zusätzlich aktualisieren die Ziel-DCs ihren eigenen HWMV, jedoch nicht ihren eigenen UTDV. Die Änderung wurde schließlich auf dem Quell-DC DC01 durchgeführt. Zur Erinnerung: Der UTDV wird nur bei einer ursprünglichen und nicht bei einer replizierten Aktualisierung erhöht.
8. Nach der Replikation liegen auf den Ziel-DCs Änderungen vor, die angeblich repliziert werden müssen. Auf beiden Ziel-DCs hat sich der lokale HWMV erhöht. Der neue HWMV der Domänenpartition von DC02 ist 37259 und von DC03 39271.
Wenn nun DC02 eine Änderungsbenachrichtigung an DC03 sendet und ihn darüber informiert, dass Änderungen vorliegen, sendet im Gegenzug DC03 den HWMV zu DC02, den er für DC02 in seiner HWMV-Tabelle gespeichert hat, also 37258 und seine komplette UTDV-Tabelle. In der UTDV-Tabelle die DC03 zu DC02 sendet, stehen die Werte „DC01-UTDV Domain NC 20509“ und „DC02-UTDV Domain NC 37258“.
9. Anhand des HWMV 37258 den DC03 zu DC02 gesendet hat, geht DC02 davon aus, dass DC03 die aktuelle Änderung noch nicht erhalten hat.
Und an dieser Stelle, kommt der UTDV zum Einsatz! DC02 erkennt nämlich anhand der UTDV-Tabelle (genauer an dem Eintrag DC01-UTDV Domain NC 20509), die DC03 vor der Replikation zu DC02 gesendet hat, das DC03 bereits die Änderung von DC01 erhalten hat. Die Änderung wird also nicht erneut repliziert! Danach aktualisiert DC03 nur den HWMV und UTDV von DC02 in seinen Tabellen, auf den aktuellen Wert 37259.
10. Das gleiche Verfahren wird in umgekehrter Konstellation angewendet, also wenn DC03 die beiden anderen DCs DC01 und DC02 informiert das Änderungen vorliegen oder wenn DC01 von DC02 benachrichtigt wird. Das Einzige was passiert ist, das jeder DC in seiner HWMV- und UTDV-Tabelle, die aktuellen Werte der beiden anderen Replikationspartner einträgt.
Der Änderungsstempel
Wenn ein Objekt erstellt wird, erhält jedes einzelne Attribut für das ein Wert vergeben wurde, einen Änderungsstempel. Der Änderungsstempel besteht aus dem Ursprungsserver, dem Zeitstempel und der Versionsnummer. Wird ein Attribut geändert, werden diese drei Komponenten aktualisiert.
Die drei Komponenten bedeuten:
Ursprungsserver: Bei dem Ursprungsserver handelt es sich um den DC, auf dem die ursprüngliche Aktualisierung eines Attributs durchgeführt wurde. Dieser Wert wird mit dem aktualisierten Attribut auf die Replikationspartner repliziert.
Zeitstempel: Bei der Änderung eines Attributs, wird der Zeitpunkt der Durchführung, in Form von Datum und Uhrzeit, mit dem Attribut gespeichert. Dieser Zeitwert wird ebenfalls mit dem aktualisierten Attribut repliziert.
Versionsnummer: An der Versionsnummer lässt sich erkennen, wie oft ein Attribut geändert wurde. Bei der Erstellung eines Objekts, wird jedem Attribut das einen Wert enthält, die Versionsnummer 1 zugewiesen. Alle Attribute die keinen Wert besitzen, erhalten die Versionsnummer 0. Jedes Mal wenn sich der Wert eines Attributs ändert, erhöht sich die Versionsnummer um einen Zähler. Auch dieser Wert wird so wie die anderen beiden Komponenten auf die Replikationspartner repliziert.
Mit Repadmin lassen sich die Komponenten mit diesem Befehl Anzeigen:
Repadmin /showobjmeta <DC> <DN des Objekts>
In der Repadmin-Ausgabe befindet sich der Ursprungsserver in der Spalte Ursprüngl. DSA. Hinter dieser Komponente steckt das Attribut objectGUID eines DCs. Wie zu erkennen, befindet sich der Zeitstempel in der Spalte Ur.Zeit/Datum und die Versionsnummer in der Spalte Ver.
Mittels des Änderungsstempels wird bei einem Replikationskonflikt darüber entschieden, welche Änderung übernommen wird. Wie das AD einen Replikationskonflikt auflöst und welche Konflikte wann entstehen können, beschreibt der folgende Artikel:
Active Directory-Replikationskonflikt
Weitere Informationen:
Die Linked Value Replikation (LVR)
Die unterschiedliche Größe der AD-Datenbank
Die konstruierten Attribute abfragen
Domänencontroller vergleichen
Die Active Directory-Attribute hinter den Feldnamen
Troubleshooting replication with repadmin
How the Active Directory Replication Model Works: Active Directory
Ein weit verbreitetes Missverständnis ist, das ein Ereignis, welches die dringende AD-Replikation auslöst, sofort an alle Domänencontroller (DC) repliziert wird. Genau genommen handelt es sich bei einer dringenden AD-Replikation (urgent replication) noch nicht einmal um eine echte sofortige Replikation. In Wirklichkeit wird lediglich die Benachrichtigung, dass Änderungen auf dem Quell-DC vorliegen, an erster Stelle der Replikationswarteschlange hinzugefügt.
Genau wie bei der standortinternen (Intra-Site) Replikation, basiert die dringende AD-Replikation auf Änderungsbenachrichtigungen (change notification). Außer das beim Eintreten eines wichtigen Ereignisses die Benachrichtigung unverzüglich versendet wird, statt 15 Sekunden (bzw. 300 Sekunden unter Windows 2000) abzuwarten. Diese Änderungsbenachrichtigung wird sofort an alle Replikationspartner versendet, noch bevor die in der Replikationswarteschlange anstehenden Änderungsbenachrichtigungen verschickt werden. Jeder DC, der eine dringende Aktualisierung erhält, leitet diese ebenfalls umgehend an seine Replikationspartner weiter. Durch diese Vorgehensweise ist sichergestellt, dass alle DCs am gleichen AD-Standort innerhalb von Sekunden aktualisiert werden.
Durch die dringende AD-Replikation erhalten die Replikationspartner in gewohnter Weise sofort eine Änderungsbenachrichtigung über das RPC over IP Protokoll. Aufgrund des hohen Replikationsaufkommens werden bei der dringenden AD-Replikation standardmäßig die AD-Standortgrenzen nicht überschritten. Das lässt sich jedoch konfigurieren.
Ereignisse, die eine dringende AD-Replikation auslösen
Die dringende AD-Replikation wird bei Eintreten bestimmter Ereignisse standardmäßig nur innerhalb eines AD-Standorts durchgeführt. Dabei ist es unabhängig, unter welchem Betriebssystem die DCs betrieben werden. Ist allerdings die standortübergreifende Änderungsbenachrichtigung in der Standortverknüpfung (Site-Link) aktiviert, werden diese Ereignisse auch unverzüglich zwischen den AD-Standorten repliziert.
Siehe dazu:
Die Inter-Site (standortübergreifende) Änderungsbenachrichtigung aktivieren
Zwischen den DCs, die sich innerhalb des gleichen AD-Standorts befinden, wird die dringende AD-Replikation durch folgende Änderungstypen ausgelöst:
- Benutzerkontosperrung (nachdem ein Benutzer sein Kennwort zu oft falsch eingegeben hat). Die Sperrung eines Benutzerkontos wird über die dringende AD-Replikation in erster Linie zu dem DC, der die FSMO-Rolle des PDC-Emulators innehat, repliziert. Das Entsperren eines Benutzerkontos hingegen löst keine dingende AD-Replikation aus!
- Bearbeitung der Kontosperrungsrichtlinie. Die Bearbeitung der gleichen Optionen in einem PSO (Password Setting Object) löst hingegen keine dringende AD-Replikation aus! Die Änderung eines PSO wird über die normale standortinterne (Intra-Site) und standortübergreifende (Inter-Site) AD-Replikation durchgeführt.
- Bearbeitung der domänenweiten Kennwortrichtlinie. Aber das Bearbeiten der Kennwortvorgaben in einem PSO löst ebenfalls keine dringende AD-Replikation aus! Die Änderung der Kennwortvorgaben innerhalb einer PSO wird ebenfalls über die normale standortinterne und standortübergreifende AD-Replikation durchgeführt.
- Verschiebung der RID-Master FSMO-Rolle auf einen anderen DC.
- Änderung eines LSA-Schlüssels (Local Security Authority, lokale Sicherheitsautorität). Wenn zum Beispiel das Kennwort des Computerkontos eines DCs oder für eine Vertrauensstellung geändert wird.
Die dringende AD-Replikation durch eine Benutzerkontosperrung
Gibt ein Benutzer sein Kennwort häufiger falsch ein, als es in der Kontosperrungsrichtlinie oder im PSO definiert ist, wird sein Benutzerkonto gesperrt. Die Benutzerkontosperrung wird dann über die dringende AD-Replikation zum PDC-Emulator repliziert. Unabhängig davon, an welchem AD-Standort dieser sich befindet.
Anschließend wird ebenfalls über die dringende AD-Replikation die Benutzerkontosperrung zu den folgenden DCs repliziert:
- Zu allen DCs der gleichen Domäne, die sich am gleichen AD-Standort befinden wie der DC der die FSMO-Rolle des PDC-Emulators innehat.
- Zu allen DCs der gleichen Domäne, die sich am gleichen AD-Standort befinden wie der DC der die Benutzerkontosperrung durchgeführt hat.
- Zu allen DCs der gleichen Domäne, die sich an einem AD-Standort befinden zu der die standortübergreifende Änderungsbenachrichtigung (und demnach die dringende AD-Replikation) mit dem AD-Standort aktiviert wurde, in dem sich der PDC-Emulator oder der DC befindet, der die Benutzerkontosperrung durchgeführt hat.
Wenn die Benutzerauthentisierung an einem DC, nicht jedoch am PDC-Emulator fehlschlägt, wird die Authentisierung auf dem PDC-Emulator wiederholt. Aus diesem Grund ist letzten Endes auch der PDC-Emulator derjenige, der das Benutzerkonto nach den Vorgaben der Kontosperrungsrichtlinie zuerst sperrt. Und nicht der DC, der die fehlgeschlagene Benutzerauthentisierung als erster entgegennahm.
Die Replikation einer Kennwortänderung
Oftmals wird auch fälschlicherweise angenommen, dass die Kennwortänderung eines Benutzers über die dringende AD-Replikation zu allen anderen DCs repliziert wird. Kennwortänderungen werden anders als die normale AD-Replikation und anders als die dringende AD-Replikation durchgeführt.
Bei der Kennwortänderung eines Domänen-Benutzers oder eines Computerkontos repliziert der DC, der die Kennwortänderung durchgeführt hat, umgehend das neue Kennwort durch den sicheren Kanal zum PDC-Emulator. Das neue Kennwort wird sogar dann zum PDC-Emulator repliziert, wenn dieser an einem anderen AD-Standort steht. Dabei greift der DC auch nicht auf die Bridgeheadserver an den AD-Standort zurück. Der DC, auf dem das Kennwort geändert wurde, nutzt stattdessen eine RPC over IP-Verbindung direkt zum PDC-Emulator, um das Kennwort zu aktualisieren.
Authentisiert sich der Benutzer danach an einem DC (z.B. aus einem anderen AD-Standort) der das neue Kennwort noch nicht kennt, fragt der DC beim PDC-Emulator nach, ob ihm ein neueres Kennwort vorliegt, bevor er dem Benutzer die Anmeldung verweigert. Falls ja, wird der Benutzer vom PDC-Emulator authentisiert und der Benutzer kann sich anmelden. Falls nicht, schlägt die Anmeldung fehl. Der PDC-Emulator hat also bei der Kennwortfrage immer das letzte Wort. Wenn die Kennwortnachfrage beim PDC-Emulator erfolgreich verlief, repliziert der PDC-Emulator das neue Kennwort unverzüglich zu dem DC, von dem die Anfrage kam. Dadurch ist sichergestellt, dass der DC nicht erneut wegen des geänderten Kennworts beim PDC-Emulator nachfrägt.
Die Kennwortaktualisierung wird sofort zum PDC-Emulator repliziert, ohne Rücksicht auf einen eventuell konfigurierten Zeitplan in der Standortverknüpfung. Anschließend wird sie innerhalb des AD-Standorts des PDC-Emulators und innerhalb des AD-Standorts des DC, der die Kennwortänderung durchgeführt hat, durch die standortinterne AD-Replikation zu den anderen DCs repliziert. Alle anderen DCs, die sich an entfernten AD-Standorten befinden, erhalten die Kennwortänderung ganz normal durch die standortübergreifende AD-Replikation.
Ist allerdings der PDC-Emulator nicht erreichbar (beispielsweise wegen Überlastung) oder schlägt die RPC over IP-Verbindung fehl, wird die Kennwortänderung über das normale Replikationsverfahren (standortintern und standortübergreifend) an alle DCs inklusive dem PDC-Emulator repliziert.
Wenn es nicht gewünscht wird, dass die Kennwortaktualisierung eines Benutzers oder eines Computers sofort zum PDC-Emulator an einem anderen AD-Standort repliziert wird, kann man dieses Verhalten unterbinden. Dazu muss folgender neuer Eintrag in die Registry erstellt werden:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Netlogon\Parameters
REG_DWORD
AvoidPdcOnWan
1 = Aktiviert (True)
Dieser Registryeintrag muss auf jedem DC erstellt werden, der eine Kennwortaktualisierung nicht sofort zu einem (an einem entfernten AD-Standort stehenden) PDC-Emulator replizieren soll. Der PDC-Emulator erhält die Kennwortaktualisierung dann ganz normal über den konfigurierten Zeitplan für die standortübergreifende AD-Replikation. Befindet sich aber der PDC-Emulator am gleichen AD-Standort wie der DC, der die Kennwortaktualisierung durchgeführt hat, wird der Registryeintrag ignoriert und das neue Kennwort wird unverzüglich zum PDC-Emulator repliziert.
Komfortabler lässt sich diese Einstellung über die folgende GPO konfigurieren:
Computerkonfiguration\Richtlinien\Administrative Vorlagen\System\Netzwerkanmeldung\Verbindung mit PDC bei Anmeldungsfehler herstellen
Wird diese Richtlinie auf Deaktiviert konfiguriert, repliziert der DC, auf dem die Kennwortänderung stattgefunden hat, das neue Kennwort ebenfalls nicht sofort zum PDC-Emulator an einem anderen AD-Standort. Stattdessen wird das neue Kennwort dann über den konfigurierten Zeitplan für die standortübergreifende AD-Replikation repliziert. Wenn sich jedoch der PDC-Emulator am gleichen AD-Standort befindet wie der die Kennwortänderung durchführende DC, wird das neue Kennwort sofort zum PDC-Emulator repliziert.
Auf der anderen Seite hat man sowohl mit dem Registryeintrag als auch mit der GPO Einfluss darauf, wie sich ein DC Verhalten soll, wenn sich ein Benutzer oder Computer mit einem für den DC fremden Kennwort authentisieren möchte. Setzt man den Registryeintrag oder konfiguriert man die GPO, leitet der DC die Kennwortabfrage nicht an den PDC-Emulator weiter, wenn dieser sich an einem anderen AD-Standort befindet.
Der Registryeintrag oder die GPO kann zum Beispiel dann sinnvoll sein, wenn sich der PDC-Emulator an einem AD-Standort befindet, der mit einer geringen Bandbreite mit anderen Standorten angebunden ist (was in unserer Hemisphäre schon kaum mehr möglich ist). Oder um bei einer Brute Force Attacke nicht zusätzlich den PDC-Emulator und die VPN-Verbindung zu belasten. Dann muss man aber in Kauf nehmen, dass der Benutzer sich über einen längeren Zeitraum nicht an der Domäne anmelden kann.
Weitere Informationen:
Password Setting Objects erstellen und verwalten
Der RID-Master und sein RID-Pool
How the Active Directory Replication Model Works
New Password Change and Conflict Resolution Functionality in Windows
Zwei wichtige IDs eines Domänencontrollers (DC) sind der DC GUID (Globaly Unique Identifier) und der Datenbank GUID. Beide IDs sind wichtige Bestandteile bei der AD-Replikation. Mit dem Kommandozeilenbefehl Repadmin /Showrepl <DC> kann man sich beide IDs anzeigen lassen. Gibt man den <DC> nicht an, wird der Befehl gegen den DC ausgeführt, auf dem man den Repadmin Befehl ausführt. Führt man den Befehl auf einem Windows Server 2003 DC aus, so erhält man diese Ausgabe auf dem ersten DC einer Gesamtstruktur:
Auf einem Windows Server 2008 R2 DC sieht das Ergebnis auf dem ersten DC wie folgt aus:
Jeder DC besitzt eine eindeutige DC GUID innerhalb einer Gesamtstruktur, der auch als Directory Service Agent GUID (kurz DSA-GUID) bekannt ist. Mit der DC GUID der im Attribut objectGUID gespeichert ist, wird der DC in der Gesamtstruktur identifiziert. Dabei spielt es auch keine Rolle in welcher Domäne sich der DC innerhalb einer Gesamtstruktur befindet. Der DC GUID eines DCs ist in der Gesamtstruktur einmalig und ändert sich solange der DC existiert (im Gegensatz zu der invocationId) niemals! Es sei denn, der DC wird zuerst herunter- und anschließend wieder zum DC heraufgestuft. Denn der DC GUID eines DCs wird beim heraufstufen eines Servers zu einem DC erstellt und beim herunterstufen eines DCs entfernt. Natürlich ist das manuelle bearbeiten des DC GUIDs ebenso nicht möglich, weil das Attribut objectGUID system-only ist. Das Attribut objectGUID findet man in den Eigenschaften des „NTDS Settings“ Objekts unterhalb des entsprechenden DC-Objekts in der Konfigurationspartition und ist als ein Oktett-String gespeichert. Der LDAP-Pfad zum “NTDS Settings” Objekt lautet: CN=NTDS Settings,CN=<DC>,CN=Servers,CN=<AD-Standort>,CN=Sites,CN=Configuration,DC=Root-Domäne.
Die objectGUID wird unter anderem auch dazu verwendet, um die Reihenfolge der DCs einer ringförmigen Replikationstopologie zu bestimmen und ist außerdem bei der Wahl des Bridgeheadservers eines AD-Standorts von Bedeutung. Damit der DC für seine Replikationspartner erreichbar ist, erstellt dieser mit der objectGUID in der Forward Lookup Zone _msdcs.Root-Domäne im DNS einen CNAME Eintrag.
Beim heraufstufen eines Servers zu einem DC wird der AD-Datenbank (NTDS.dit) ebenfalls eine GUID zugeordnet, die als Datenbank GUID bezeichnet wird. Diese GUID wird dazu verwendet, um die AD-Datenbank eines DCs bei einem Replikationsaufruf zu identifizieren. Bei der Datenbank GUID handelt es sich um das Attribut invocationId und befindet sich so wie die objectGUID ebenfalls in der Konfigurationspartition, in den Eigenschaften des NTDS Settings Objekts eines DCs im LDAP-Pfad: CN=NTDS Settings,CN=<DC>,CN=Servers,CN=<AD-Standort>,CN=Sites,CN=Configuration,DC=Root-Domäne. Auch die invocationId wird wie die objectGUID beim heraufstufen eines Servers zu einem DC erstellt und beim herunterstufen eines DCs entfernt. Replikationspartner nutzen die invocationId und die Update Sequence Number (USN) um die aktuellen Änderungen für die AD-Replikation zu bestimmen.
Die invocationId des ersten DCs mit dem die Gesamtstruktur erstellt wurde, hat den gleichen Wert wie die objectGUID. Bei allen weiteren DCs einer Gesamtstruktur werden unterschiedliche Werte in den beiden Attributen objectGUID und invocationId gespeichert.
Im Gegensatz zur objectGUID ändert sich die invocationId wenn:
- eine neue Anwendungsverzeichnispartition erstellt wird. Oder wenn eine bestehende Anwendungsverzeichnispartition entfernt und erneut erstellt wird.
- der DC mit einer gültigen Sicherung und einer unterstützten Rücksicherungsmethode (supportet von Microsoft!) rückgesichert wird. Eine gültige Sicherung ist eine Sicherung die mit einer Sicherungssoftware durchgeführt wurde, dass das entsprechende API des Betriebssystems verwendet und somit das AD in Kenntnis setzt, dass eine Sicherung durchgeführt wurde. Nur wenn eine gültige und somit eine supportete Sicherung mindestens vom System State durchgeführt wird, erspart man sich je nach Umgebung größeren Schaden im Fall einer Rücksicherung! Ab Windows Server 2003 SP1 kann man mit dem Kommandozeilenbefehl Repadmin /Showbackup überprüfen, ob eine Verzeichnispartition jemals supportet gesichert wurde.
Eine unterstützte Rücksicherung findet in Abstimmung mit der AD-Replikation statt. Denn nur wenn das AD durch eine ordnungsgemäß durchgeführte System State Sicherung und einer supporteten Rücksicherungsmethode rückgesichert wird, erhält die invocationId auf dem rückgesicherten DC einen neuen Wert. Dadurch erkennen alle anderen DCs, dass die Metadaten für die AD-Replikation zu dem rückgesicherten DC hinfällig sind und das die AD-Replikation ab dem durchgeführten Sicherungsdatum mit dem der DC rückgesichert wurde, neu aufgebaut und durchgeführt werden muss. Einige Sicherungsprogramme (bis Windows Server 2003 NTBACKUP und ab Windows Server 2008 Wbadmin, ARCServe…) führen eine ordnungsgemäße Sicherung und Rücksicherung des System States durch und darauf kommt es an!
Das entscheidende bei der Rücksicherung ist nun mal, dass die invocationId einen neuen Wert erhalten muss! Das ist genau der Nachteil bei Image-Programmen. Beim klassischen Imagen zieht man sich eine eins zu eins Kopie des DCs. Sollte es nun zum Rückspielen des Images kommen, erhält die invocationId keinen neuen Wert und somit erfahren je nach Umgebung die Replikationspartner auch nicht, dass ein DC rückgesichert wurde und das die Replikation mit dem rückgesicherten DC neu aufgebaut werden muss. Beim rücksichern eines Images schafft man sich ein USN Rollback, was je nach Fall zu einem größeren Schaden für die AD-Umgebung bedeutet! Im günstigsten Fall hätte man sich lediglich den zurück-geimageten DC zerstört. Diesen müsste man dann gewaltsam herunterstufen und anschließend die Metadaten des AD bereinigen (siehe weiterführende Informationen). Im ungünstigsten Fall hätte man mindestens doppelte RIDs verteilt, nicht mehr gültige Computerkontokennwörter und keine funktionierende AD-Replikation mit diesem DC mehr!
Wenn eine unterstützte Rücksicherung stattgefunden hat, wird der nicht mehr gültige Wert aus dem Attribut invocationId in das Attribut retiredReplDSASignatures (das sich ebenfalls im NTDS Settings Objekt eines DCs befindet) gesetzt.
Auch eine IFM (Install from Media) Installation eines DCs kommt einer Rücksicherung eines DCs gleich. Denn bei einer IFM-Installation wird der Wert aus dem Attribut invocationId das von der Sicherung stammt, in das Attribut retiredReplDSASignatures auf dem neuen DC geschrieben. Der Grund dafür ist, wenn ein Verbindungsobjekt für die Replikation erstellt wird, überprüft der neue DC sein Attribut retiredReplDSASignatures um festzustellen ob das Attribut einen Wert enthält, der mit den invocationIds im Up-To-Dateness Vector (UTDV) des Ziel-DCs übereinstimmt. Durch diese Vorgehensweise ist sichergestellt, dass nur eine Teilmenge der AD-Datenbank, nämlich nur die Änderungen die ab der Sicherung durchgeführt wurden repliziert wird.
Durch die ausschließlich ordnungsgemäß durchgeführte Sicherung und der Rücksicherungsmethode wird ein USN Rollback und somit Schaden verhindert! Wenn man sich nicht sicher ist ob das eingesetzte Sicherungsprogramm eine unterstützte Sicherung sowie Rücksicherung durchführt, sollte man ein klärendes Telefonat mit dem Hersteller führen. Von ungültigen Sicherungsmethoden wie das Rücksichern eines Images, VM-Images und VM-Snapshots (mindestens auf Servern die transaktionale Datenbanken bereitstellen wie ein DC, Exchange und SQL) sollte man stets Abstand halten und wird seitens Microsoft auch nicht supportet!
Auf einem DC ist es Pflicht mindestens das System State zu sichern und das kann man bereits mit Windows-Bordmittel (NTBACKUP, Wbadmin) durchführen!
Weiterführende Informationen:
Domänencontroller-Installation von einer Sicherung
Images als Sicherung?
Das Active Directory gewaltsam vom DC entfernen
Die Metadaten des Active Directory unter Windows Server 2008 bereinigen
Der RID-Master und sein RID-Pool
Lingering Objects (veraltete Objekte)
How to detect and recover from a USN rollback in Windows Server 2003
How To Convert a String Formatted GUID to a Hexadecimal String Form For Use When Querying the Active Directory
Mit Windows Server 2008 führte Redmond den Read Only Domänencontroller (kurz RODC) ein. Der RODC der für Außenstellen die eine geringe bis keine physikalische Sicherheit den Servern bieten können konzipiert wurde, ist ein Domänencontroller (DC) der ausschließlich einen lesenden Zugriff auf die Active Directory-Domänendienste (AD DS) hat. Der RODC kann keine Änderungen in den AD DS und im AD-integrierten DNS vornehmen (RODNS). Clients oder Applikationen die einen Lesezugriff auf die AD DS benötigen erhalten Zugriff auf den RODC, während Clients oder Applikationen die einen Schreibvorgang in die AD DS durchführen wollen, diesen nicht auf dem RODC durchführen können sondern vom RODC an einen beschreibbaren DC verwiesen werden.
Der RODC besitzt ein vollständiges Replikat der AD-Datenbank, mit allen Attributen und Objekten die sich auch auf einem beschreibbaren DC befinden. Neben dem Unterschied das der RODC lediglich das Leserecht auf die AD-Datenbank hat, werden im Gegensatz zu einem beschreibbaren DC standardmäßig auch keine Benutzer- oder Computeranmeldeinformationen auf dem RODC gespeichert, außer das eigene Computerkonto sowie ein besonderes krbtgt-Konto für diesen RODC. Damit die Anmeldeinformationen der entsprechenden Benutzer-, Computer- und Dienstkonten auf dem RODC gespeichert werden können, muss das explizit in der Kennwortreplikationsrichtlinie (Password Replication Policy, kurz PRP) auf einem beschreibbaren DC gestattet werden, damit der RODC Authentifizierungs- und Dienstticketanforderungen eigenständig verarbeiten kann. Mit der Kennwortreplikationsrichtlinie wird bestimmt, ob die Anmeldeinformationen eines Benutzer- oder Computerkontos von einem beschreibbaren DC auf den RODC repliziert werden können.
Weitere Informationen zum RODC bekommt man in den folgenden beiden Artikeln:
Read-Only Domain Controller (RODC)
Die Installation eines RODC
Der gefilterte Attributsatz vom RODC
Diverse Applikationen könnten die AD-Domänendienste als Datenspeicher verwenden und sensible Daten darin speichern. Oder evtl. möchte man einfach nicht, dass bestimmte Daten von Benutzern (z.B. die Adressdaten oder die Personalnummer) auf einen RODC repliziert werden. Natürlich sollen diese kritischen Daten ebenfalls geschützt sein und nicht auf einem RODC gespeichert werden, falls der RODC kompromittiert, gestohlen oder die Sicherheit gefährdet wird. Und für genau diesen Anwendungstyp gibt es den gefilterten Attributsatz. Der gefilterte Attributsatz (auf Englisch: Filtered Attribute Set, kurz FAS) ist ein dynamischer Attributsatz, die nie auf einen RODC in der Gesamtstruktur repliziert werden da sie sensible oder vertrauliche Daten enthalten. Der gefilterte Attributsatz kann aber erst ab Windows Server 2008 konfiguriert werden.
Damit ein Attribut das wichtige Daten enthält nicht auf einen RODC repliziert wird, sollten die folgenden Schritte durchgeführt werden:
-
Das entsprechende Attribut sollte zu dem gefilterten Attributsatz (FAS) hinzugefügt werden. Damit wird verhindert, dass das Attribut an die RODCs in der Gesamtstruktur repliziert wird. Die Konfiguration des gefilterten Attributsatzes betrifft die Gesamtstruktur und kann nicht pro Domäne konfiguriert werden!
-
Des Weiteren sollte das Attribut als vertraulich gekennzeichnet werden. Dies ist eine weitere Sicherheitseinstellung das konfiguriert werden sollte, wenn man nicht möchte das ein sensibles Attribut zu einem RODC repliziert werden soll! Ein Attribut wird als vertraulich gekennzeichnet, in dem die Leseberechtigung für das entsprechende Attribut für die Gruppe Authentifizierte Benutzer entfernt wird. Somit können diese Attribute von den Mitgliedern der Gruppe Authentifizierte Benutzer (das betrifft alle Benutzer- sowie Computerkonten, inklusive RODCs) nicht mehr gelesen werden. Auch die Konfiguration eines vertraulichen Attributs betrifft die Gesamtstruktur und kann nicht pro Domäne konfiguriert werden! Doch bevor ein Attribut als vertraulich gekennzeichnet wird, sollte der Vorgang in einer Testumgebung ausgiebig getestet werden!
-
Der Gesamtstrukturfunktionsmodus sollte sich aus Sicherheitsgründen mindestens auf Windows Server 2008 befinden. Denn die Attribute die sich im gefilterten Attributsatz befinden, werden nur von DCs die mindestens unter Windows Server 2008 laufen berücksichtigt! Windows Server 2003 DCs ignorieren die Konfiguration das ein Attribut geschützt ist und replizieren die Attribute die sich in dem gefilterten Attributsatz befinden trotzdem auf einen RODC. Die Domänenpartition in der sich der RODC befindet wird zwar erst ab einem beschreibbaren Windows Server 2008 DC auf den RODC repliziert, doch wenn auf dem RODC der globale Katalog (ROGC) aktiviert wird, baut sich eine eigene Replikationstopologie für die Replikation des GCs auf. Existieren in der Gesamtstruktur noch weitere Domänen mit Windows Server 2003 GCs in denen ebenfalls ein gefilterter Attributsatz konfiguriert wurde, ist es durchaus möglich das ein Windows Server 2003 GC den gefilterten Attributsatz aus seiner Domäne zu einem RODC repliziert.
-
Das Hinzufügen eines systemkritischen Attributs zum gefilterten Attributsatz ist nicht möglich! Ein systemkritisches Attribut ist ein Attribut, das z.B. für die ordnungsgemäße Funktion der AD DS oder für das Kerberos-Authentifizierungsprotokoll benötigt wird. Erst wenn in den Eigenschaften des entsprechenden Attributs im Attribut schemaFlagsEx, das aus einer Bitmaske besteht, das Flag FLAG_ATTR_IS_CRITICAL aktiviert ist, handelt es sich um ein systemkritisches Attribut. Dieses Flag existiert aber erst seit Windows Server 2008 und Windows Server 2003 DCs würden diese Einstellung ignorieren. Daher ist es umso mehr wichtig, dass sich nicht nur der Schemamaster auf mindestens einem Windows Server 2008 DC, sondern der Gesamtstrukturfunktionsmodus sich zwingend im Modus Windows Server 2008 oder höher befindet. Denn wäre der Schemamaster ein Windows Server 2003 DC, würde sich ein systemkritisches Attribut dem gefilterten Attributsatz scheinbar erfolgreich hinzufügen lassen. Aber da ein Windows Server 2003 DC die Konfiguration eines gefilterten Attributsatzes sowieso nicht kennt, sollte in einer Gesamtstruktur in der ein gefilterter Attributsatz genutzt wird ein Windows Server 2003 DC ohnehin nicht mehr existieren!
Die technische Umsetzung wie ein Attribut zum gefilterten Attributsatz hinzugefügt wird, findet wie folgt statt
-
Um ein Attribut zum gefilterten Attributsatz hinzuzufügen und somit die Replikation des entsprechenden Attributs zu einem RODC zu verwehren, muss im zu schützenden Attribut das zehnte Bit (also Bit 9) im searchFlags Attribut gesetzt werden. Im searchFlags Attribut kann unter anderem bestimmt werden, dass ein Attribut zum gefilterten Attributsatz hinzugefügt wird und das es vertraulich ist. Im searchFlags Attribut das aus einer Bitmaske besteht, muss im zehnten Bit als Wert in Hexadezimal 0x200 und in Dezimal 512 eingetragen werden. Anschließend wird das entsprechende Attribut zu keinem RODC in der Gesamtstruktur repliziert.
-
Im Attribut searchFlags liegt auch das Geheimnis, warum ein Windows Server 2003 DC die Attribute im gefilterten Attributsatz nicht berücksichtigt. Denn das zehnte Bit, also Bit 9 in searchFlags ist erst mit Windows Server 2008 und der Einführung des RODCs hinzugekommen.
-
Soll ein Attribut zum gefilterten Attributsatz hinzugefügt werden, sollte es auch als vertraulich deklariert werden. Als vertraulich deklariert und somit die Leseberechtigung den Authentifizierten Benutzern entzogen, wird ein Attribut durch das Setzen des achten Bits (Bit 7) ebenfalls im searchFlags Attribut. Dieses Flag kam mit Windows Server 2003 SP1 hinzu. Daher sollte darauf geachtet werden, dass wenn mit diesem Flag Attribute als vertraulich definiert werden, alle DCs in der Gesamtstruktur mindestens unter Windows Server 2003 SP1 installiert sind. Alle älteren Serverversionen ignorieren die Kennzeichnung als vertraulich! Im achten Bit des searchFlags Attributs muss als Wert in Hexadezimal 0x080 und in Dezimal 128 eingetragen werden.
-
Demnach erhält also searchFlags als Wert 640 in Dezimal (in Hexadezimal 0x280), damit zum einen das gewünschte Attribut zum gefilterten Attributsatz hinzugefügt und zum anderen, als vertraulich definiert wird. Trägt man als Wert 641 ein, wird zugleich das Attribut indiziert. Sollten bereits andere Flags im searchFlags Attribut konfiguriert sein, müssen die Werte addiert werden!
Den gefilterten Attributsatz abfragen
Standardmäßig befinden sich die folgenden Attribute ab Windows Server 2008 im gefilterten Attributsatz:
ms-FVE-KeyPackage
ms-FVE-RecoveryPassword
ms-PKI-AccountCredentials
ms-PKI-DPAPIMasterKeys
ms-PKI-RoamingTimeStamp
ms-TPM-OwnerInformation
Um die Attribute die sich im gefilterten Attributsatz befinden abzufragen, muss eine Abfrage nach dem Attribut searchFlags mit dem Wert 512 (das zehnte Bit in searchFlags) durchgeführt werden.
Die Abfrage mit der AD-PowerShell könnte wie folgt lauten
Get-ADObject -LDAPFilter "(objectClass=attributeSchema)" -Searchbase "CN=Schema,CN=Configuration,DC=Root-Domäne" -Properties searchFlags | Where {$_.searchFlags -band 512} | Select Name,searchFlags | Sort Name | FT -Autosize -Wrap
Auch mit diesem AD-PowerShell Befehl lassen sich die gefilterten Attribute anzeigen:
Get-ADObject -LDAPFilter "(&(ObjectClass=attributeSchema)(searchFlags:1.2.840.113556.1.4.803:=512))" -SearchBase “CN=Schema,CN=Configuration,DC=Root-Domäne” -SearchScope Subtree | Select Name | Sort Name | FT -Autosize -Wrap
Mit LDP lässt sich der gefilterte Attributsatz folgendermaßen anzeigen
Nach dem man sich in LDP mit einem DC verbunden und an das AD gebindet hat, muss man unter Durchsuchen - Suchen als Basis-DN die Schemapartition und als Filter (searchFlags:1.2.840.113556.1.4.803:=512) angeben.
Weitere Informationen:
How to mark an attribute as confidential in Windows Server 2003 Service Pack 1
Anhang D: Schritte zum Hinzufügen eines Attributs zu einem Attributsatz mit RODC-Filter
Search-Flags Attribute
Das Active Directory (AD) speichert seine Daten bekanntermaßen in einer Datenbank. Das Herzstück des AD ist die Datenbankdatei, die standardmäßig im Verzeichnis %windir%\NTDS\ gespeichert wird. Diese transaktionale Datenbank und die zugehörige Datenbank-Engine „Extensible Storage Engine (ESE)“, trägt den Namen NTDS.DIT. Dabei steht das „NTDS“ für New Technology Directory Services und das „DIT“ für Directory Information Tree.
Jeder Domänencontroller (DC) in einer Einzel- und Multidomänen-Gesamtstruktur hält seine eigene Kopie dieser AD-Datenbank (NTDS.dit), die kontinuierlich durch lokale Änderungen und durch die Replikationspartner aktualisiert wird. Die AD-Datenbank verändert sich in der Größe zum einen durch die lokalen Änderungen auf dem DC selbst und zum anderen durch die Änderungen die von den Replikationspartnern repliziert werden. Es ist zwingend notwendig, dass die AD-Daten konsistent zwischen den DCs durch die AD-Replikation gehalten werden. Aber die AD-Datenbankdatei ist ohnehin nie bis auf das letzte Bit zwischen mehreren DCs identisch.
Es gibt AD-Daten, die nicht zwischen den DCs repliziert werden. Denn z.B. werden die Indizes die eine performante LDAP-Suche ermöglichen lokal auf jedem DC erstellt. Dies kann bereits zu einem gewissen Maß an Größenunterschied in jeder AD-Datenbankdatei führen. Das einzige was repliziert wird ist die Anweisung, dass ein Attribut im AD indiziert werden soll. Wird in den Eigenschaften eines Attributs im Schema Snap-In die Option Attribut in Active Directory indizieren markiert, repliziert sich diese Änderung bei der nächsten Replikation der Schemapartition auf alle DCs in der Gesamtstruktur.
Die Gründe warum auf zwei DCs die AD-Datenbank unterschiedlich groß ist, sind:
-
Der Whitespace oder zu Deutsch: Der freie Speicherplatz in der AD-Datenbank. Dies trifft dann zu, wenn ein weiterer DC zur Domäne hinzugefügt wird. Wenn ein Server als zusätzlicher DC zu einer Domäne hinzugefügt wird kann es durchaus sein, das die AD-Datenbank des neuen DCs wesentlich kleiner ist als auf den bestehenden DCs. Das ist dann ein klares Indiz für den Whitespace der in der AD-Datenbank auf den bestehenden DCs existiert. Denn wird ein weiterer DC zur Domäne hinzugefügt, wird selbstverständlich nur die Nettokapazität der AD-Datenbank auf den neuen DC repliziert und nicht zusätzlich der unnötige Whitespace.
-
AD-Replikationsprobleme. Bestehen auf einem DC Replikationsprobleme, sei es mit einer oder mit allen Verzeichnispartitionen, bekommt dieser keine Aktualisierungen von seinen Replikationspartnern mehr mit.
-
In einer Multidomänen-Gesamtstruktur ist auf einem DC der globale Katalog (GC) aktiviert und auf dem anderen nicht. Oder auf einem DC wurde der GC „unbemerkt“ deaktiviert.
Die Ursachen in der Praxis sind in der Regel der Whitespace und AD-Replikationsprobleme, die den Unterschied zwischen den AD-Datenbankdateien ausmachen.
Der Whitespace in der AD-Datenbank
Der Whitespace in der AD-Datenbank entsteht folgendermaßen.
Wenn ein AD-Objekt gelöscht wird, verschwindet es nicht sofort aus der AD-Datenbank. Das AD markiert das Objekt als gelöscht, indem das Attribut Is-Deleted des Objekts auf TRUE gesetzt wird. Dabei werden von dem Objekt die meisten Attribute für immer entfernt und wandert anschließend in den Container „Deleted Objects“ (der in fast allen Verzeichnispartitionen existiert). Ab diesem Zeitpunkt wird das gelöschte Objekt als Tombstone (zu deutsch: Grabstein) bezeichnet.
Die gelöschten Objekte bleiben nun so lange im Container „Deleted Objects“ und somit in der AD-Datenbank erhalten, bis die Tombstone-Lifetime (TSL) abgelaufen ist. Erst wenn ein gelöschtes Objekt die TSL überschritten hat wird es endgültig vom Garbage Collection Prozess aus der AD-Datenbank entfernt. Der Garbage Collection Prozess läuft standardmäßig im 12-Stunden-Takt auf jedem DC in der Gesamtstruktur. Die Zeit lässt sich zwar verändern, jedoch ist das beim täglichen Betrieb nicht notwendig.
Ändern könnte man die Zeit durch das Attribut garbageCollPeriod, welches sich in den Eigenschaften des folgenden Containers befindet (die Angabe der Zeit muss in Stunden erfolgen):
CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,DC=Root-Domäne
Wenn die Objekte unwiderruflich aus dem AD entfernt wurden, entsteht freier Speicherplatz (der sogenannte Whitespace) in der AD-Datenbank. Die Datenbankseiten auf denen die Objekte gespeichert waren, werden als frei markiert. Physikalisch wird aber dadurch die AD-Datenbank auf der Festplatte nicht kleiner. Stattdessen werden beim Hinzufügen neuer AD-Objekte diese auf den freien Datenbankseiten geschrieben, ohne dabei eine Speicheroptimierung bei späteren Abfragen dieser Objekte zu berücksichtigen. Durch das wiederbeschreiben der freien Datenbankseiten wird die Gesamtgröße der AD-Datenbank nicht größer. Zwar findet standardmäßig alle 12-Stunden durch den Garbage Collection Prozess auf jedem DC eine Onlinedefragmentierung der AD-Datenbank im laufenden Betrieb statt, jedoch wird dabei die AD-Datenbank ebenfalls nicht kleiner. Ob die Onlinedefragmentierung zweimal am Tag auch wirklich stattfindet, kann im Verzeichnisdienstprotokoll auf jedem DC kontrolliert werden. Denn beim Starten der Onlinedefragmentierung wird die EventID 700 und wenn sie abgeschlossen wurde, die EventID 701 protokolliert.
Bei der Onlinedefragmentierung werden lediglich die leeren Datenbankseiten neu angeordnet um einen zusammenhängenden freien Speicherplatz in der AD-Datenbank zu schaffen. Somit wird die durch die endgültige Löschung der AD-Objekte bedingte Fragmentierung der AD-Datenbank beseitigt und dadurch der Zugriff auf das AD optimiert bzw. beschleunigt. Bei den heutigen Festplattenpreisen ist es aber auch keineswegs tragisch das die AD-Datenbank physikalisch nicht kleiner wird. Dennoch ist es aus Performancegründen empfehlenswert, dass die AD-Datenbank „nur“ so groß ist, damit sie noch in den Arbeitsspeicher des DCs geladen werden kann.
Wie viel freier Speicherplatz in der AD-Datenbank tatsächlich existiert, kann durch eine Registry-Einstellung herausgefunden werden. Dazu gilt es im folgenden Registry-Schlüssel diese Einstellung vorzunehmen:
HKLM\System\CurrentControlSet\Services\NTDS\Diagnostics
"6 Garbage Collection" = 1 (REG_DWORD)
Anschließend wird beim nächsten Durchlauf des Garbage Collection Prozesses, im Verzeichnisdienstprotokoll des DCs die EventID 1646 protokolliert. In dem Eintrag wird der freie Speicherplatz neben der Gesamtgröße der AD-Datenbank angegeben.
Es reicht in der Regel aus diese Registry-Einstellung nur auf einem DC in der Domäne zu konfigurieren, da sicherlich der freie Speicherplatz auf allen bestehenden DCs (bei gleicher DC Konfiguration) gleich ist.
Eine andere Variante mit der man sich einen tieferen Einblick über die Größe des freien Speicherplatzes in Form von leeren Datenbankseiten sogar der einzelnen Indizes in der AD-Datenbank verschaffen kann, wäre mit Esentutl. Dazu muss jedoch das AD offline sein. Bis einschließlich Windows Server 2003 muss hierzu der DC im Modus Verzeichnisdienstwiederherstellung gestartet werden. Unter Windows Server 2008 lässt sich dagegen der Dienst Active Directory-Domänendienste samt den abhängigen Diensten im laufenden Betrieb mit dem Kommandozeilenbefehl net stop ntds /y anhalten. Danach wird mit dem Befehl Esentutl /ms <Pfad zur Ntds.dit> oder durch das Aufrufen von Esentutl aus dem NTDS-Verzeichnis C:\Windows\NTDS>Esentutl /ms ein detaillierter Auszug der Ntds.dit erstellt. Es ist auch möglich die AD-Datenbank aus einer System State-Sicherung an einer alternativen Stelle wiederherzustellen, um diese AD-Datenbank zum überprüfen des freien Speicherplatzes zu nutzen. In der AD-Datenbank wird jede Tabelle zusammen mit der Anzahl der Datenbankseiten die es besitzt, samt der Anzahl der leeren Datenbankseiten die zur Verfügung stehen aufgelistet.
Damit die AD-Datenbank physikalisch kleiner wird, ist eine Offlinedefragmentierung notwendig. Natürlich müsste die Offlinedefragmentierung auf jedem DC erfolgen, damit die AD-Datenbank auf jedem DC auch physikalisch kleiner wird. Aber in den allermeisten AD-Umgebungen ist eine Offlinedefragmentierung nicht nötig. Wobei es jedoch in größeren AD-Gesamtstrukturen wiederum des Öfteren notwendig sein kann, eine Offlinedefragmentierung durchzuführen.
Wann ist eine Offlinedefragmentierung empfehlenswert?
-
Nach einer größeren Löschaktion im AD ist es empfehlenswert, wenn nach Ablauf der Tombstone-Lifetime die gelöschten Objekte endgültig aus der AD-Datenbank entfernt wurden, eine Offlinedefragmentierung der AD-Datenbankdatei durchzuführen.
-
In einer Multidomänen-Gesamtstruktur ist es ratsam, nach der Deaktivierung des globalen Katalogs auf einem DC eine Offlinedefragmentierung der AD-Datenbank durchzuführen.
-
Des Weiteren ist nach einem Inplace-Update eines Windows 2000 DCs auf Windows Server 2003/2008 eine Offlinedefragmentierung empfehlenswert. Nach einem Inplace-Update von Windows 2000 entsteht in der AD-Datenbankdatei eine erhebliche Menge an freiem Speicherplatz. Das ist aufgrund einer Verbesserung ab Windows Server 2003 möglich, worin eindeutige „security descriptors“ nur einmal (Single Instance Store) und nicht jedes Mal wenn sie verwendet werden in der AD-Datenbank gespeichert werden.
-
Wenn die DNS-Daten aus der Domänenpartition in die Anwendungsverzeichnispartitionen (DomainDNSZones und ForestDNSZones) umgezogen werden, wie es z.B. nach einer Domänenaktualisierung von einer Windows 2000 Domäne zu einer Windows Server 2003 bzw. Windows Server 2008 Domäne der Fall sein könnte, entsteht ebenfalls freier Speicherplatz in der AD-Datenbank (genauer in der Domänenpartition). Die Größe der AD-Datenbank lässt sich dann mit einer Offlinedefragmentierung verkleinern.
Die Größe unter anderem der AD-Datenbank kann man sich mit dem folgenden Befehl anzeigen lassen:
FOR /f %i IN ('Dsquery Server -Domain %userdnsdomain% -o Rdn') DO dir \\%i\Admin$\NTDS
Eine Offlinedefragmentierung durchführen
Die Gesamtgröße der AD-Datenbank wird ausschließlich nur durch eine Offlinedefragmentierung verringert. Diese sollte beim Entfernen einer größeren Anzahl an AD-Objekten, nach dem Entfernen eines globalen Katalogs in einer Multidomänen-Gesamtstruktur, nach einem Inplace-Update eines Windows 2000 DCs auf Windows Server 2003/2003R2/2008 und nach dem Umzug der DNS-Daten aus der Domänenpartition in die Anwendungsverzeichnispartition durchgeführt werden.
Die Offlinedefragmentierung wird folgendermaßen durchgeführt:
-
Zuerst sollte eine System State-Sicherung des DCs durchgeführt werden.
-
Damit eine Offlinedefragmentierung der AD-Datenbank auf einem DC durchgeführt werden kann, muss unter Windows 2000 und Windows Server 2003 der DC im Modus Verzeichnisdienstwiederherstellung gestartet werden. In diesen Modus gelangt man, wenn während der Bootphase des DCs die F8-Taste betätigt und die Option „Verzeichnisdienstwiederherstellung“ ausgewählt wird.
-
Ab Windows Server 2008 ist das Starten im Modus „Verzeichnisdienstwiederherstellung“ nicht notwendig (was aber möglich wäre). Ab einem Windows Server 2008 DC kann der Dienst Active Directory-Domänendienste im laufenden Betrieb entweder in der Dienstesteuerung (services.msc) oder in der Kommandozeile mit dem Befehl net stop ntds /y samt den abhängigen Diensten angehalten werden.
Active Directory-Domänendienste (AD-DS)
-
In der Eingabeaufforderung oder unter „Start-Ausführen“ gilt es das NTDSUTIL aufzurufen.
-
Ab Windows Server 2008 muss als erstes mit dem Befehl Activate Instance NTDS die NTDS-Instanz aktiviert werden. Unter Windows 2000 und Windows Server 2003/2003R2 muss dieser Schritt übersprungen werden.
-
Als nächstes gilt es den Befehl Files einzugeben.
-
In der „file maintenance“ Ebene werden mit dem Befehl info die aktuellen Informationen über den Pfad und der Größe der AD-Datenbank sowie der zugehörigen Protokolldateien angezeigt. Der Pfad zur AD-Datenbankdatei sollte notiert werden (zumindest sollte man ihn sich merken).
-
Mit dem Befehl compact to <Laufwerk>:\<Verzeichnis> wird eine neue, komprimierte AD-Datenbankdatei im angegebenen Verzeichnis erstellt. Es sollte ein Laufwerk und Verzeichnis an dem ausreichend Speicherplatz zur Verfügung steht ausgewählt werden, um die komprimierte neue AD-Datenbankdatei Ntds.dit zu speichern. Falls im Namen des Verzeichnispfads Leerzeichen enthalten sind, muss der Pfad in Anführungszeichen stehen. Z.B. compact to "C:\Neu NTDS".
-
Sobald die Offlinedefragmentierung abgeschlossen ist, gilt es mit der zweimaligen Eingabe von quit das NTDSUTIL zu verlassen.
-
Nun muss die neu erstellte defragmentierte Datenbankdatei "Ntds.dit" über die alte Datei "Ntds.dit" im aktuellen Pfad zur Active Directory-Datenbank (der in Schritt vier notiert bzw. gemerkt wurde), kopiert werden. Anschließend sind noch die alten Protokolldateien (*.log) zu löschen.
-
Das Kopieren der Datenbankdatei kann auch über die Kommandozeile mit folgendem Befehl erfolgen: Copy „C:\Neu NTDS\Ntds.dit“ „C:\Windows\NTDS\Ntds.dit“
Die darauffolgende Sicherheitsabfrage muss mit einem „j“ bestätigt werden.
-
Die alten Protokolldateien können in der Kommandozeile mit diesem Befehl gelöscht werden:
Del „C:\Windows\NTDS\*.log“
-
Danach gilt es den DC neu zu starten. Unter Windows Server 2008 wird mit net start ntds der Dienst Active Directory-Domänendienste samt den abhängigen Diensten gestartet.
-
Zum Schluss sollte noch eine System State-Sicherung mit der neuen Größe der Ntds.dit durchgeführt werden.
AD-Replikationsprobleme
Ein weiterer Grund warum zwischen zwei DCs die AD-Datenbank unterschiedlich groß ist, könnten AD-Replikationsprobleme sein. Hinweise ob es bei der AD-Replikation Probleme gibt, liefert bereits das Verzeichnisdienstprotokoll der DCs. Ein entscheidender Faktor bei der AD-Replikation ist die Tombstone-Lifetime (TSL). Denn DCs müssen sich mindestens einmal während der TSL mit ihren Replikationspartnern repliziert haben, da ansonsten Lingering Objects (herumlungernde Objekte) in der AD-Datenbank des DCs entstehen und die Replikationspartner den „veralteten“ DC von der AD-Replikation ausschließen.
Lingering Objects (veraltete Objekte)
Oftmals handelt es sich bei Replikationsproblemen um DNS-Probleme, denn für eine AD-Umgebung ist das DNS essentiell. Bevor ein DC die AD-Replikation startet führt dieser zuerst ein DNS-Lookup durch. Somit stellt der DC zwei Dinge sicher, zum einen das sein Replikationspartner online und funktionstüchtig ist und zum anderen, das die Namensauflösung funktioniert. Daher muss bei Replikationsproblemen die Umgebung genauestens untersucht und verifiziert werden, um welche Probleme es sich tatsächlich handelt.
Das nützlichste Werkzeug für die Überprüfung und Problembehandlung bei der AD-Replikation ist für alle Serverversionen Repadmin. Bis einschließlich „Windows Server 2003“ befindet sich Repadmin noch in den Windows Support Tools (auf der Server CD im Verzeichnis Support\Tools) und ab „Windows Server 2008“ ist es „on Bord“. Dieses Tool stellt quasi das Schweizer Messer für die AD-Replikation dar. Mit diesem Kommandozeilentool lässt sich die Replikationstopologie aus der Sicht jedes einzelnen DCs anzeigen.
Den Zustand der AD-Replikation kann man z.B. mit diesem Repadmin-Befehl überprüfen:
Repadmin /Replsum * /Bysrc /Bydest /Sort:Error
Die Replikationsinformationen auf einem DC lassen sich auch in eine CSV-Datei importieren, damit diese Datei z.B. in Excel geöffnet und leichter durchsucht werden kann. Der Befehl ist wie folgt:
Repadmin /showrepl * /csv > C:\Repadmin.csv
Eine andere Methode um Differenzen zwischen den AD-Datenbanken aufzudecken, ist neben Repadmin das DSASTAT. Details dazu liefert der folgende Artikel:
Domänencontroller vergleichen
Es könnte aber auch sein, dass ein Problem in der AD-Datenbank auf einem DC existiert. Dieses lässt sich mit einer Überprüfung der AD-Datenbankdatei herausfinden. Dazu sollte die Integrität der Ntds.dit mit NTDSUTIL untersucht und falls bei der Überprüfung Probleme gemeldet werden, könnten diese sich evtl. mit einem Fixup beheben lassen.
Siehe:
Die Active Directory-Datenbank reparieren
Die unterschiedliche Größe der AD-Datenbank zwischen globalen Katalogen
Wenn in einer Multidomänen-Gesamtstruktur auf einem DC der globale Katalog (GC) aktiviert wird, werden alle AD-Objekte aus allen Domänen in den GC repliziert. Im GC wird die vollständige Domänenpartition (alle Objekte samt allen Attributen) der eigenen Domäne gespeichert, in der sich der GC befindet. Die Domänenpartitionen der anderen Domänen werden ebenfalls in den GC repliziert, es werden jedoch nicht alle Attribute der Objekte gespeichert. Nur die Attribute die für eine Suchoperation relevant sein könnten (z.B. der DN eines Objekts) werden gespeichert.
Wird auf einem DC der GC aktiviert, gibt sich dieser nach Beendigung der Replikation im DNS als solcher bekannt. Das der DC endgültig ein GC ist, wird im Verzeichnisdienstprotokoll mit der EventID 1119 (was zwingend erscheinen muss!) protokolliert.
Ob das Heraufstufen eines DCs zum GC erfolgreich abgeschlossen wurde, lässt sich anhand des folgenden Artikels ermitteln:
Globaler Katalog – Sein oder nicht sein
Falls das Heraufstufen zum GC ordnungsgemäß abgeschlossen wurde und sich die lokale AD-Datenbankdatei dennoch von anderen GCs in der Größe wesentlich unterscheidet (z.B. 50%), so könnte ein DNS- und/oder Replikationsproblem vorliegen. Auch hierbei muss dann ein tiefergehendes Troubleshooting betrieben und die AD-Replikation mit Repadmin untersucht werden. Bei der Fehlersuche sollte die erste Anlaufstelle die Ereignisanzeige des DCs sein, DCDIAG sollte ausgeführt werden und bei Verdacht auf DNS-Probleme könnte man neben dem DCDIAG (mit den DNS-Parametern) noch das DNSLint ausführen.
Weitere Informationen:
Die Tombstone Lifetime
Globaler Katalog (Global Catalog - GC)
Die Protokollierung des Active Directory`s konfigurieren
Extensible Storage Engine Architecture
The Active Directory database garbage collection process
Performing offline defragmentation of the Active Directory database
Die Active Directory-Replikation ist ein komplexer Vorgang, die regelmäßig (um nicht zu sagen ständig) kontrolliert werden sollte.
Falls es zwischen Domänencontrollern zu Replikationsproblemen kommt, helfen neben der Ereignisanzeige in erster Linie die beiden
Tools REPADMIN sowie REPLMON bei der Suche nach der Fehlerquelle.
Gerade das Kommandozeilentool REPADMIN, das sich unter Windows 2000 sowie Windows Server 2003 in den Windows Support Tools
und im Windows Server 2008 bereits im Betriebssystem befindet, ist ein mächtiges Tool das mit vielen Parametern ausgestattet ist.
Nun hat Microsoft speziell für dieses Tool ein Whitepaper veröffentlicht, in dem das Tool mit all seinen Parametern erläutert wird.
Weiterhin werden auch Szenarien beschrieben, in denen REPADMIN helfen kann.
Hier kann das Whitepaper heruntergeladen werden:
Troubleshooting replication with Repadmin
Weitere Informationen:
Windows 2000 Service Pack 4 Support Tools
Windows Server 2003 Service Pack 2 32-bit Support Tools
Wenn ein zusätzlicher Domänencontroller (DC) z.B. durch die Install from Media-Funktion (kurz IFM) bereitgestellt wird, kann es je nach
Umgebung eine Weile dauern bis die Replikation vollständig abgeschlossen wurde. Die Dauer der Replikation hängt von der Größe der
Active Directory-Datenbank (Ntds.dit), von der zur Verfügung stehenden Badbreite und von dem Replikationszeitplan ab. Wobei die zur
Verfügung stehende Bandbreite sowie der Replikationszeitplan bei der standortübergreifenden, der sogenannten Inter-Site Replikation
eher eine Rolle spielt.
In vielen Umgebungen in denen vielleicht nur ein AD-Standort existiert reicht meistens ein Blick in die einzelnen MMCs aus. Diese wären
z.B. das Active Directory-Benutzer und –Computer Snap-In, das DNS-Snap-In (bei AD-integrierter FLZ) oder dem Verzeichnisdienstprotokoll,
um festzustellen ob bereits die Active Directory-Replikation stattgefunden hat oder evtl. ein Problem mit der AD-Replikation besteht.
Wer es aber genau wissen möchte hat die Möglichkeit, sich im laufenden Betrieb einen Überblick über die Replikation zu verschaffen,
ob auch tatsächlich die Repliken auf den verschiedenen DCs identisch sind. Ohnehin sollte ein Administrator die AD-Replikation stets überprüfen.
Mit den beiden Kommandozeilentools DSASTAT und REPADMIN lässt sich zum einen der Inhalt einer Verzeichnispartition auf zwei DCs
vergleichen und zum anderen, eine statistische Auswertung der Verzeichnispartition durchführen. So lassen sich Unstimmigkeiten innerhalb
einer Active Directory-Partition zwischen zwei DCs aufdecken. Auch lässt sich das ganze über die grafische Oberfläche mit REPLMON überprüfen.
Alle drei genannten Tools befinden sich unter Windows 2000 sowie Windows Server 2003 in den Windows Support Tools, die auf der
Windows 2000 sowie Windows Server 2003 CD im Verzeichnis Support/Tools zu finden sind. Für beide Server-Versionen können die
Support Tools auch von den Microsoft-Seiten heruntergeladen werden (siehe unter Weitere Informationen). Die beiden Tools
DSASTAT und REPLMON existieren unter Windows Server 2008 nicht. Aber auch unter Windows Server 2008 lassen sich die
Windows Server 2003 SP2 Support Tools installieren. Direkt nach dem Starten der Installation meldet der Assistent zwar bekannte
Kompatibilitätsprobleme, aber dennoch lassen sich die Support Tools ohne weiteres installieren und im Fall von DSASTAT sowie REPLMON,
auch ohne Funktionsverlust verwenden. Andererseits ist im Windows Server 2008 das REPADMIN bereits im Betriebssystem integriert.
DSASTAT
Das DSASTAT kann eine Verzeichnispartition zwischen zwei DCs der gleichen Domäne oder im Falle des globalen Katalogs,
zwischen verschiedenen Domänen überprüfen. Dabei werden im ersten Schritt die Informationen wie Megabyte pro Server,
Objekte pro Server und Megabyte pro Objektklasse ausgelesen. Im zweiten Schritt werden dann die Attribute der replizierten Objekte
miteinander verglichen. So kann überprüft werden, ob die Verzeichnispartition auf beiden DCs exakt übereinstimmt.
Die Hilfe zu DSASTAT lässt sich wie gewohnt in der Kommandozeile mit dem Befehl dsastat /? aufrufen,
in der die wenigen Parameter erläutert werden.
Die Verzeichnisinformationen aller DCs in der Domäne, werden mit diesem Befehl vergliechen:
Dsastat –loglevel:debug –output:both
Dieser Befehl vergleicht die Verzeichnisinformationen der angegebenen DCs:
Dsastat -s:<DC01>;<DC02>;<DC03>
Eine ausführlichere Überprüfung wird mit diesem Befehl durchgeführt:
dsastat –s:DomainS1;DomainS2 –b:DC=Domain,DC=com –gcattrs:all –sort:true –t:false –p:100
Um z.B. den Standard-Container Users zwischen zwei DCs zu vergleichen, muss der folgende Befehl eingegeben werden (alles in einer Zeile):
dsastat -s:DC01;DC02 -b:CN=Users,DC=intra,DC=domaene,DC=de -gcattrs:all -sort:true -t:false -p:100
-filter:"(&(objectcategory=person)(objectclass=user))"
Wenn ein DC aus der Sub-Domäne mit dem globalen Katalog der Root-Domäne verglichen werden soll, so gilt es diesen Befehl einzugeben:
dsastat -s:RootDC:3268;FQDN-SubDC -b:DC=sub,DC=domäne,DC=de -gcattrs:objectclass -p:500
Wichtig ist egal welcher Befehl verwendet wird, immer das Ende der Ausgabe.
REPADMIN
Eine andere Möglichkeit eine Verzeichnispartition zwischen zwei DCs zu vergleichen, stellt das REPADMIN dar.
Unter Windows 2000 lautet die Syntax wie folgt:
Repadmin /getchanges <DN-NamingContext> <FQDN-DC01> <GUID-DC02>
Repadmin /getchanges <DN-NamingContext> <FQDN-DC02> <GUID-DC01>
Besteht zwischen beiden DCs ein unterschiedlicher Datenbestand innerhalb einer Verzeichnispartition,
werden die Objekte um die es geht in der Ausgabe aufgeführt.
Hinweis: Der Parameter /getchanges in Windows 2000, wird auch unter Windows Server 2003 sowie Windows Server 2008 weiterhin unterstützt.
Des Weiteren können auch die folgenden Befehle, auf jeweils beiden DCs unter Windows 2000, Windows Server 2003 und 2008
ausgeführt werden, um so den up-to-dateness vector zu vergleichen:
Repadmin /showvector <DN-NamingContext> <NameDC1>
Repadmin /showvector <DN-NamingContext> <NameDC2>
Unter Windows Server 2003 sowie Windows Server 2008 ist dieser Befehl einzugeben:
Repadmin /showchanges <FQDN-ZielDC> <GUID-QuellDC> <DN-NamingContext> /statistics
Die Konfigurationspartition kann zwischen einem DC der Root-Domäne und einem DC einer Sub-Domäne wie folgt überprüft werden:
Repadmin /showchanges <FQDN-ZielDC> <GUID-QuellDC> <CN=Configuration,DC=Root-Domäne,DC=de> /statistics
Die Anwendungsverzeichnispartition ForestDNSZones kann folgendermaßen überprüft werden:
Repadmin /showchanges <FQDN-ZielDC> <GUID-QuellDC> <DC=ForestDNSZones,DC=Root-Domäne,DC=de> /statistics
Die Object-GUID eines DCs lässt sich z.B. unter Windows 2000 mit Repadmin /showreps und unter Windows Server 2003 sowie
Windows Server 2008 mit Repadmin /showrepl herausfinden.
REPLMON
Mit dem Replication-Monitor lassen sich ebenfalls Unterschiede einer Verzeichnispartition zwischen zwei DCs unter Windows 2000,
Windows Server 2003 und Windows Server 2008 aufdecken.
-
Nach dem Starten von REPLMON gilt es zuerst unter dem Menüpunkt View die Options aufzurufen.
-
Im Reiter General ist die Option Show Transitive Replication Partners and Extended Data zu aktivieren und anschließend
die Auswahl mit OK zu bestätigen.
-
Danach ist in der linken Spalte mit einem Rechtsklick auf Monitored Server die Option Add Monitored Server… zu wählen.
-
Im Assistent Add Monitored Server Wizard der daraufhin startet, gilt es einen gewünschten DC (z.B. einen neu hinzugefügten DC „DC01“)
anzugeben, der dann in der linken Spalte im Replmon erscheint.
-
Nun muss auf das Pluszeichen der entsprechenden Verzeichnispartition geklickt werden, damit mit einem Rechtsklick
auf dem anderen DC (DC02), mit dem die Verzeichnispartition verglichen werden soll, die Option Check Current USN
and Un-replicated Objects ausgewählt werden kann.
-
Falls notwendig, können für diesen Vorgang alternative Benutzerinformationen angegeben werden.
-
Wenn es nun Objekte gäbe die von DC02 zu DC01 noch nicht repliziert wurden, würden diese noch nicht replizierten Objekte
in einer Meldung angezeigt werden.
-
Soll hingegen die Replikation einer bestimmten Verzeichnispartition von DC01 zu DC02 kontrolliert werden, so sind die
gleichen Schritte auszuführen bis auf Punkt 4 (und 5). Dort ist dann DC02 als Monitored Server auszuwählen und an der
gewünschten Verzeichnispartition mit einem Rechtsklick auf DC01, erneut die Option Check Current USN and Un-replicated Objects auszuwählen.
Weitere Informationen:
Windows 2000 Service Pack 4 Support Tools
Windows Server 2003 Service Pack 2 32-bit Support Tools
Dsastat Examples
Determining the Server GUID of a Domain Controller
Als Microsoft mit Windows 2000 das Active Directory in der ersten Version einführte, waren damals die Ansprüche an dem
Verzeichnisdienst andere als heute. Insbesondere was die Active Directory-Replikation oder das Replikationsaufkommen angeht,
hatte man seinerzeit noch eine andere (geringere) Vorstellung darüber. Es kristallisierte sich heraus, dass sich dieses Verhalten
noch verbessern lässt. Denn sowohl unter Windows 2000 als auch Windows Server 2003 (abhängig vom Gesamtstrukturfunktionsmodus)
werden sämtliche Werte eines mehrwertigen (multi-valued) Attributs auch dann repliziert, wenn lediglich ein einziger Wert geändert wurde.
In einem mehrwertigen bzw. multi-valued Attribut werden, wie es der Name bereits verrät, mehrere Werte in einem Attribut gespeichert.
In Windows 2000 findet dabei ausschließlich eine Replikation auf Attribut-Ebene und nicht auf der Wert-Ebene (per Value) statt.
Die Replikation auf Attribut-Ebene hat den Nachteil, dass zum einen ein dadurch überflüssig hohes Replikationsaufkommen
entsteht und zum anderen, dass Risiko eines Replikationskonflikts sich erhöht. Bekanntermaßen findet im Active Directory
eine Multimaster-Replikation statt was soviel bedeutet, dass auf jedem Domänencontroller zur gleichen Zeit eine Änderung
durchgeführt werden kann, die dann durch die AD-Replikation auf die anderen DCs repliziert wird.
Wenn nun bei diesem Replikationsverhalten zur gleichen Zeit auf verschiedenen DCs einer Domäne, der Wert des gleichen
Attributs verändert wird, würde ein Replikationskonflikt entstehen und somit eines der Änderungen verworfen werden.
Wie sich das Active Directory im Falle eines Replikationskonflikts verhält, wird im folgenden Artikel erläutert:
Active Directory-Replikationskonflikt
Das Verhalten trifft natürlich nur dann zu, wenn sich mindestens zwei Domänencontroller in der Domäne befinden.
Ansonsten würde keine Replikation stattfinden  .
Das oft zitierte Beispiel das man zu diesem Thema liest, wären Gruppenmitgliedschaften, was nachfolgend noch
genauer erläutert wird. Das Beispiel mit den Gruppenmitgliedschaften bietet sich deshalb an, da es sich zum einen
um ein mehrwertiges Attribut (Member) handelt und zum anderen in der Praxis darin viele Werte gespeichert werden.
Denn in größeren Unternehmen stößt man genau an diesem Punkt auf Probleme.
Als Beispiel nehmen wir an, es existiert eine Benutzergruppe mit 4.950 Benutzern. Das mehrwertige Attribut Member des
Gruppenobjekts enthält somit 4.950 Einträge. Im Attribut Member sind die Distinguished Names der einzelnen Mitglieder aufgelistet.
Das können Einträge von Benutzern, anderen Gruppen oder Computern sein. Im Benutzerobjekt hingegen befinden sich die
Einträge der Gruppenmitgliedschaften im mehrwertigen Attribut MemberOf. Wenn nun dieser Benutzergruppe ein weiterer Benutzer
hinzugefügt wird, werden alle 4.951 Einträge im Attribut Member auf die anderen DCs repliziert und nicht nur der einzig
hinzugekommene Eintrag. Schließlich wird auf Attribut- und nicht auf der Wert-Ebene repliziert.
In einem anderen Beispiel gehen wir davon aus, dass eine Benutzergruppe simultan auf zwei DCs verändert wird.
Es existiert eine GruppeA mit den Benutzern: User1 und User2. Administrator1 fügt der GruppeA einen neuen Benutzer User5
hinzu und zeitgleich fügt Administrator2 auf einem anderen DC User9 hinzu. Somit kommt es zu einem Replikationskonflikt,
wobei eines der Änderungen verworfen wird.
Das Member- und MemberOf-Attribut stellen zusammen ein Linked-Attribut (verknüpftes Attribut) Paar dar.
Linked-Attribute stellen eine besondere Beziehung im Active Directory zueinander dar, denn sie bestehen aus zwei Attributen,
dem Forward- sowie Back-Link. Verändert der Administrator im Forward-Link einen Wert, aktualisiert das Active Directory
automatisch den Back-Link. Das beinhaltet natürlich auch das Löschen von Werten.
Das Member-Attribut im Gruppenobjekt ist ein Forward-Link und das Attribut MemberOf eines Benutzerobjekts stellt den Back-Link dar.
Back-Links werden von jedem DC selbst verwaltet und können auch nicht vom Administrator bearbeitet werden. Es ist ein sogenanntes
system-only Attribut und wird auch nicht auf andere DCs repliziert. Ein Back-Link und sein Wert werden zum Zeitpunkt der Abfrage generiert.
Solche Attribute tragen den Namen "constructed". Der Administrator kann nur den Forward-Link, in dem Fall dass
Member-Attribut eines Gruppenobjekts das auf andere DCs repliziert wird bearbeiten.
Neben dem unnötigen Replikationsaufkommen unter Windows 2000 kommt noch hinzu, dass eine Benutzergruppe mit mehr
als 5.000 Mitgliedern nicht unterstützt wird. Diese Grenze von 5.000 kommt daher, weil eine Aktualisierung im Active Directory
in einem einzigen Vorgang durchgeführt werden muss und eben dabei ca. 5.000 Werte aktualisiert werden können.
Anders ausgedrückt, die Active Directory Jet Database Engine kann lediglich mit einer bestimmten Anzahl an Werten
während eines Schreibvorgangs bzw. eines Replikationszyklus umgehen.
In größeren Umgebungen kann aber diese Grenze von 5.000 Mitgliedern pro Benutzergruppe ein Problem darstellen.
Der Weg diese Barriere zu umgehen wäre mit Gruppenverschachtelungen zu arbeiten.
Daraufhin wurde im Windows Server 2003 dieses Verhalten verbessert. Microsoft hat die sogenannte Linked-Value Replikation
(zu Deutsch, verknüpfte Wertreplikation) eingeführt. Mit dieser Funktion wird nur noch der geänderte Wert eines
mehrwertigen Attributs repliziert, aber nicht mehr die unveränderten Werte. Die AD-Replikation findet nun auf der Wert-Ebene statt.
Diese neue Funktion trägt sowohl zur effizienteren Replikation, als auch der Konfliktvermeidung eines mehrwertigen Attributs bei.
Bei der LVR-Replikation werden bei einem Objekt zuerst die nicht verknüpften Attribute (non-Linked Attributs) und anschließend
die verknüpften Attribute (Linked Attributes) repliziert.
Im oben genannten ersten Beispiel mit den 4951 Mitgliedern einer Benutzergruppe, würde durch die LVR-Replikation lediglich
der geänderte Wert (der hinzugekommene Benutzer) repliziert werden und nicht mehr alle Werte. Auch unter Windows NT
würde der PDC lediglich den veränderten Wert zum BDC übertragen.
Im zweiten Beispiel wären die Benutzer: User1, User2, User5 und User9 nach der LVR-Replikation in der GruppeA.
Die Linked Value Replikation ist aber erst verfügbar, wenn sich der Gesamtstrukturfunktionsmodus auf Windows Server 2003 Interim
oder Windows Server 2003 befindet. Nur dann kommt die verbesserte Replikationstechnik zum Einsatz.
Somit wird auch die künstliche Grenze von 5.000 Mitgliedern pro Benutzergruppe aufgehoben.
Eine Gruppe im Gesamtstrukturfunktionsmodus Windows Server 2003 kann im sieben stelligen Bereich Mitglieder enthalten.
Allerdings ist die unterstützte Anzahl der Änderungen die innerhalb eines Schreibvorgangs durchgeführt werden können 5.000.
Denn wenn z.B. per Skript oder Management-Tool eine Gruppe mit weit mehr als 5.000 Mitgliedern erstellt wird, läuft man Gefahr
einen „out of version store“-Fehler zu erhalten. Daher sollte beim automatisierten einrichten von Gruppen darauf geachtet werden,
diesen Wert nicht zu überschreiten.
Als Bestätigung, dass nach dem Heraufstufen der Gesamtstruktur auf Windows Server 2003 nun die LVR-Replikation eingesetzt wird,
findet man im Verzeichnisdienstprotokoll aller Domänencontroller in der Gesamtstruktur die EventID 1695.
Leider profitieren aber die bereits bestehenden Werte in einem mehrwertigen Attribut nach dem Heraufstufen der Gesamtstruktur
nicht von der LVR-Replikation. Lediglich neu hinzugekommene Werte in diesem Modus nutzen den Vorteil der LVR-Replikation.
Überprüfen lässt sich das mit dem Tool Repadmin, das sich in den Windows Support Tools befindet.
Gibt man in einer Kommandozeile den folgenden Befehl ein: Repadmin /showobjmeta <DC-Name> <DN der Gruppe>
erscheint eine Ausgabe die wie folgt aussieht:
Entscheidend dabei ist die Spalte Type. Der Eintrag LEGACY zeigt, dass dieser Wert vor dem Heraufstufen der Gesamtstruktur bereits existierte.
Somit profitiert dieser Wert nicht von der LVR-Replikation.
Im nächsten Schritt wird der bestehenden Gruppe ein weiterer Benutzer hinzugefügt.
Es ist zu erkennen, dass in der Spalte Type bei User11 der Status sich auf PRESENT befindet. Da dieser Eintrag im
Gesamtstrukturfunktionsmodus Windows Server 2003 hinzugefügt wurde, profitiert der Wert auch von der LVR-Replikation.
Ein weiterer Status wäre ABSENT. Dieser Eintrag wird angezeigt, wenn ein Mitglied im Gesamtstrukturfunktionsmodus
Windows Server 2003 zu einer Gruppe hinzugefügt und entfernt wurde.
Wenn ein Benutzerobjekt aus dem Active Directory gelöscht wird, ist die Wiederherstellung samt Gruppenmitgliedschaften
eine heikle Angelegenheit. Wenn es sich aber um eine Windows Server 2003 SP1 Umgebung handelt, erleichtert einem das
NTDSUTIL bei der Wiederherstellung der Informationen von Gruppenmitgliedschaften das Leben. Denn die Wiederherstellung
von Gruppenmitgliedschaften basiert auf LDAP Data Interchange Format (LDIF) Dateien. Der genaue Vorgang wird im folgenden Artikel beschrieben.
How to restore deleted user accounts and their group memberships in Active Directory
Damit alle Werte eines mehrwertigen Attributs von der LVR-Replikation profitieren, ist es notwendig alle Werte neu zu schreiben.
Dazu müssen die Werte zuerst entfernt und anschließend erneut hinzugefügt werden.
Neben skriptbasierten Lösungen kann einem das LDIFDE behilflich sein oder aber die im Windows Server 2003
enthaltenen Tools DSGET und DSMOD. Mit diesem Befehl werden alle Werte neu geschrieben:
Dsget group <DN der Gruppe> -members | Dsmod group <DN der Gruppe> -chmbr
Active Directory - Abfrage
Anschließend werden mit der Abfrage von Repadmin, alle Werte im Attribut Member mit dem Status PRESENT angezeigt.
Weitere Informationen:
Verknüpfte Attribute
How to raise domain and forest functional levels in Windows Server 2003
Group Objects (Windows)
Microsoft Windows 2000 Scripting Guide - Modifying Multivalued Attributes
Enumerating Groups That Contain Many Members (Windows)
In einer Active Directory Umgebung findet zwischen den Domänencontrollern eine Multimaster-Replikation statt.
Dadurch kann auf jedem Domänencontroller (DC) eine Änderung durchgeführt werden, die Dank der AD-Replikation an alle DCs repliziert wird.
Das Active Directory (genauer KCC) reagiert dabei schnell auf etwaige Veränderungen in der Gesamtstrukturtopologie und findet
- sofern irgendwie möglich - oftmals eine Lösung.
Nun kann es in einer Umgebung mit mehreren DCs und mehreren Administratoren vorkommen, dass zur gleichen Zeit an einem Objekt,
dass gleiche Attribut auf verschiedenen DCs bearbeitet wird. Ein Replikationskonflikt wird anhand der Versions-Nummer (versionID) des
veränderten Attributs erkannt. Im Gegensatz zu der Update Sequence Number (USN), worin serverspezifische Werte gespeichert werden,
wird in der Versions-Nummer eines Attributs ein eindeutiger Wert gespeichert.
Wird nun ein Attribut auf DC2 verändert, bevor die zur gleichen Zeit getätigte Änderung von DC1 repliziert wurde,
entsteht somit ein Replikationskonflikt. Angenommen auf DC1 wird in den Eigenschaften eines Benutzerobjekts im Feld Büro die
Zimmer-Nummer 2.12 und zur gleichen Zeit auf DC2 die Zimmer-Nummer 2.21 eingetragen. Wenn nun DC3 beide Änderungen gleichzeitig erhält,
muss bestimmt werden, welche Änderung repliziert wird.
Das Active Directory wendet dann die folgenden drei Regeln an, um festzulegen welche Änderung repliziert werden soll:
-
Das modifizierte Attribut mit der höheren Versions-Nummer (versionID) überschreibt die Änderung mit der niedrigeren Versions-Nummer.
Sind in beiden Fällen, beide Versions-Nummern identisch, folgt die nächste Regel.
-
Enthalten beide Änderungen die gleiche versionID, wird die Änderung mit dem späteren Zeitstempel (Timestamp) akzeptiert und somit
würde die Änderung mit dem früheren Zeitstempel überschrieben werden. Ist in beiden Fällen auch der Zeitstempel gleich
(was in seltenen Fällen zutrifft), kommt die dritte und letzte Regel ins Spiel.
-
Falls beide Änderungen sowohl die gleiche versionID, als auch den gleichen Zeitstempel haben, wird die Änderung,
die seine Herkunft auf dem DC mit der niedrigeren GUID hat akzeptiert. Somit wird der Schreibvorgang vom DC mit der höheren GUID überschrieben.
In einem anderen Fall kann es zu einem Replikationskonflikt kommen, wenn ein Objekt auf zwei verschiedenen DCs mit dem
gleichen Namen zur gleichen Zeit erstellt wird, wie es z.B. beim hinzufügen eines Clients zur Domäne vorkommen kann.
Oder beim gleichzeitigen erstellen zweier Benutzerobjekte, mit dem gleichen Namen. Denn wenn zwei DCs zur gleichen Zeit
ein Objekt mit dem gleichen Namen im Active Directory erstellen, kommt es ebenfalls zum Konflikt.
Das Active Directory wendet in diesem Fall ebenfalls die o.g. drei Regeln an, mit dem Unterschied, dass das nicht akzeptierte
Objekt nicht überschrieben, sondern umbenannt wird. Der Relative Distinguished Name (RDN) des Objekts, bekommt einen
eindeutigen Namen der folgendermaßen aussieht: <Original RDN>\0ACNF:<ObjectGUID>. Die Zeichen CNF stehen dabei für
Conflict (Konfliktobjekt). Danach folgt ein Doppelpunkt, gefolgt von der Objekt GUID.
Der Administrator kann dann bestimmen, welches Objekt beibehalten und welches gelöscht werden soll.
Über eine benutzerdefinierte Abfrage lassen sich alle Konfliktobjekte anzeigen. Der Filter dazu lautet beispielsweise (CN=*CNF:*).
Es gibt aber noch eine dritte Situation, in dem es zu einem Konflikt kommen kann. Erstellt ein Administrator z.B. einen Benutzer in einer OU
und ein anderer Administrator löscht im gleichen Moment auf einem anderen DC diese OU, wird das Benutzerobjekt trotzdem erstellt
obwohl der übergeordnete Container entfernt wurde. Das AD löst in diesem Fall den Konflikt, in dem es das Benutzerobjekt in
einem versteckten Container Namens LostAndFound erstellt. Der Domänen-Benutzer der sich im Container LostAndFound befindet,
kann sich wie jeder andere Benutzer an der Domäne anmelden. Der Administrator sollte aber aus administrativen Gründen
den Benutzer in eine andere OU verschieben. Der Container LostAndFound kommt erst dann zum Vorschein,
wenn in der MMC Active Directory-Benutzer und -Computer unter "Ansicht" die Option Erweiterte Funktionen aktiviert wurde.
Weitere Informationen:
Avoiding Replication Issues When Designing Applications that Use Active Directory
Troubleshooting Directory Data Problems
Bei einer standortinternen (Intra-Site) Replikation kündigen die Domänencontroller (DC) vor der eigentlichen Replikation durch eine Änderungsbenachrichtigung
(Change Notification) die anstehende Replikation an. Sobald eine Änderung im Active Directory durchgeführt wurde, bekommen die Replikationspartner die sich
am gleichen Standort befinden eine Benachrichtigung. Das geschieht ab dem Gesamtstrukturfunktionsmodus „Windows Server 2003“ nach 15 Sekunden
(Initial Notification Delay). Falls der Quell-DC mehrere Replikationspartner hat, wird jeder weitere DC nach weiteren 3 Sekunden benachrichtigt (Subsequent Notification Delay).
Befindet sich der Gesamtstrukturfunktionsmodus nicht mindestens auf „Windows Server 2003“, sind es 300 Sekunden für eine Replikationsankündigung
und weitere 30 Sekunden Wartezeit für die weiteren Replikationspartner.
Die standortübergreifende Replikation findet nach einem Zeitplan (Standardeinstellung alle 180 Minuten) statt. Das Intervall kann zwischen
min. 15 bis max. 10.080 Minuten betragen und lässt sich im Snap-In „Active Directory-Standorte und –Dienste“ konfigurieren.
Die standortinterne (Intra-Site) Replikation nutzt die Benachrichtigung sowie Pull Methode, die wie folgt aussieht:
-
Auf einem DC wird eine Änderung an einem Objekt vorgenommen oder es wurde eine Änderung von einem anderen DC repliziert.
-
Danach wartet der DC 15 Sekunden (ab der Gesamtstrukturfunktionsebene „Windows Server 2003“ bzw. 300 Sekunden in allen vorherigen Ebenen)
nach der ersten Änderung und sendet anschließend eine Änderungsbenachrichtigung an seine direkten Replikationspartner am gleichen Standort.
Um genau zu sein, werden die Änderungsbenachrichtigungen nur jenen Replikationspartnern zugesandt, die ebenfalls die Verzeichnispartition in der
die Änderung vollzogen wurde besitzen. Jeder weitere Replikationspartner des Quell-DCs wird im Abstand von 3 Sekunden
(ab der Gesamtstrukturfunktionsebene „Windows Server 2003“ bzw. 30 Sekunden in allen vorherigen Ebenen) benachrichtigt.
Wenn die Änderungsbenachrichtigung zeitgleich an alle Replikationspartner versandt werden würde (Initial Notification Delay),
könnte dies zu einer Überlastung auf dem Quell-DC führen.
Daher wird jeder Replikationspartner mit einem Abstand (Subsequent Notification Delay) benachrichtigt.
-
Der Ziel-DC fordert danach die Änderungen von dem Quell-DC der die Benachrichtigung versandt hat an.
Falls weitere Replikationsanforderungen anstehen, werden diese erst abgearbeitet, wenn die vorherige Replikation abgeschlossen wurde.
Dabei verwendet das Active Directory die Pull-Replikation, die effektiver als eine Push-Replikation ist.
Bei einer Push-Replikation ist es schwierig zu erkennen, welche Änderungen dem Ziel-DC noch fehlen. Daher würde unnötig Replikationslast erzeugt,
wenn sich bereits die Informationen evtl. auf dem Ziel-DC befinden.
Möchte man die Zeit der Replikationsankündigung sowie der Verzögerung verändern, so geht das auf folgenden beiden Wegen:
-
In der Registry gilt es im Pfad „HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NTDS\Parameters“
die beiden DWORD-Schlüssel „Replicator notify pause after modify (secs)“ und „Replicator notify pause between DSAs (secs)“ zu erstellen
(falls diese nicht existieren). Als Wert trägt man die Zeit in Sekunden ein.
Ein anderer Weg wäre die Zeit für die einzelnen Verzeichnispartitionen zu definieren. Das geht, in dem die beiden Attribute
ms-DS-Replication-Notify-First-DSA-Delay sowie ms-DS-Replication-Notify-Subsequent-DSA-Delay des jeweiligen Cross-Reference Objekts
der entsprechenden Verzeichnispartition bearbeitet werden. Bearbeiten lässt sich das ganze über ADSIEdit.msc das sich in den
Windows Support Tools befindet. Die Cross-Reference Objekte befinden sich im Container Partitions der Konfigurationspartition.
Falls an beiden Stellen (Registry sowie an dem Cross-Reference Objekt) Änderungen vorgenommen wurden, so hat die Registry-Einstellung Vorrang.
Die dringende AD-Replikation (Urgent Replication)
Die dringende AD-Replikation wird für bestimmte wichtige Ereignisse verwendet.
Wie bei der standortinternen (Intra-Site) AD-Replikation basiert die dringende AD-Replikation auf Änderungsbenachrichtigungen. Außer dass beim Eintreten eines
wichtigen Ereignisses die Benachrichtigung unverzüglich versendet wird, anstatt 15 Sekunden (bzw. 300 Sekunden unter Windows 2000) abzuwarten.
Standardmäßig werden bei der dringenden AD-Replikation (aufgrund des hohen Replikationsaufkommens) Standortgrenzen nicht überschritten.
Die dringende AD-Replikation kann aber für die standortübergreifende (Inter-Site) AD-Replikation ebenfalls genutzt werden,
sofern die Benachrichtigungsfunktion in der Standortverknüpfung (Site-Link) konfiguriert wurde.
Auslöser einer dringenden AD-Replikation sind:
- Das Benutzerkonto wurde gesperrt, durch mehrmalige falsche Kennwort-Eingabe
- Das Bearbeiten der Kontosperrungsrichtlinie.
- Wenn die Kennwortrichtlinie bearbeitet wird.
- Bei Änderung eines LSA-Schlüssels (Local Security Authority, lokale Sicherheitsautorität),
wenn z.B. das Computerkontokennwort eines DCs oder das Kennwort für eine Vertrauensstellung geändert wird.
- Wenn die RID-Master FSMO-Rolle auf einen anderen DC verschoben wird.
Bei der Kennwort-Änderung gilt allerdings folgendes:
Findet z.B. eine Benutzer-Kennwortänderung auf einem DC statt, so repliziert der DC die Information (durch den sicheren Kanal) umgehend an den DC, der die Rolle des PDC-Emulators innehat. Wenn sich der Benutzer nun an einem anderen DC, der noch nicht die Benachrichtigung der Kennwort-Änderung erhalten hat anmelden möchte, erkennt dieser ein „anderes“ Kennwort und kontaktiert somit den PDC-Emulator um nachzufragen, ob zwischenzeitlich eine Kennwort-Änderung stattgefunden hat.
Siehe auch: Die dringende AD-Replikation
Die Änderungsbenachrichtigung für die standortübergreifende (Inter-Site) AD-Replikation aktivieren
Seit Windows 2000 lässt sich die Replikationsankündigung (Change Notification) über Standortgrenzen hinweg konfigurieren. Dies geht auf folgende Weise:
Mit ADSIEdit gilt es das Attribut Options der entsprechenden Standortverknüpfung (Site-Link) zu bearbeiten.
Die Standortverknüpfungen befinden sich in der Konfigurationspartition. Der Pfad für die IP-Replikation wäre:
CN=<Site-Link-Objekt-Name>,CN=IP,CN=Inter-Site Transports,CN=Sites,CN=Configuration,DC=<Domäne>,DC=<TLD>
Dort wählt man die Eigenschaften der entsprechenden Standortverknüpfung aus und navigiert zum Attribut Options.
Als Standardwert ist <Not Set> eingestellt und dieses gilt es auf 1 zu ändern. Ist in dem Attribut bereits ein Wert enthalten,
gilt es diesen Wert lediglich um +1 zu erhöhen. Also wenn das Attribut Options den Wert 2 hat, muss als neuer Wert 3 eingetragen werden.
Hinweis: Für die SMTP-Replikation kann man die Änderungsbenachrichtigung nicht aktivieren!
Weitere Informationen:
Domänen- und Gesamtstrukturfunktionsmodus
Account Unlocks and Manual Password Expirations Are Not Replicated Urgently
Advanced Replication Management
How the Active Directory Replication Model Works
CrossRef-Referrals
Wenn ein Objekt im Active Directory gelöscht wird, verschwindet das Objekt nicht sofort aus dem Verzeichnis. Denn in größeren Gesamtstrukturen
mit einer komplexen Replikationstopologie könnte es durchaus vorkommen, dass ein Domänencontroller der von dieser Löschung noch nichts mitbekommen hat,
dass Objekt zurückrepliziert. Deshalb werden (weiter unten stehende) diverse Attribute eines Objekts behalten und als gelöscht markiert.
Anschließend wird dieser Datensatz auf alle anderen Domänencontroller repliziert. Auf diese Art ist sichergestellt, dass jeder Domänencontroller von dieser
Löschung informiert wird. Dieser Ansatz wird als Tombstone (Grabstein) bezeichnet, denn den Grabstein muss das gelöschte Objekt für einen bestimmten
Zeitraum, nämlich die Tombstone Lifetime (TSL), mit sich herumtragen. Die Tombstone Lifetime definiert, in welchem Zeitraum ein gelöschtes Objekt im
Active Directory wiederhergestellt werden kann.
Wenn ein Objekt gelöscht wird, werden folgende Änderungen an dem Objekt vorgenommen:
- Das Attribut des gelöschten Objekts Is-Deleted wird auf TRUE gesetzt,
wenn das löschen nicht durch das gesetzte Bit (0x80000000) im System-Flags Attribut des Objekts verhindert wird.
- When-Deleted ist eine interne Eigenschaft und besitzt keinen LDAP-Namen. Diese Eigenschaft bekommt den Wert (Timestamp) aus dem
Attribut Is-Deleted.
- Das Attribut NT-Security-Descriptor bekommt einen speziellen Wert.
- Der Common Name (CN) wird zu einem Wert geändert, der anderweitig von keinem LDAP Programm gesetzt werden kann.
Wenn z.B. das Benutzerobjekt „Yusuf Dikmenoglu“ gelöscht wird, bekommt es nach dem löschen einen bestimmten Wert und der
Distinguished Name (DN) würde wie folgt lauten:
„CN=Yusuf Dikmenoglu\0ADEL:ee3570c0-2664-4947-bde0-4dcbb55a8a23,CN=Deleted Objects,DC=<Domäne>,DC=<TLD>“
(CN=<alter RDN>\0ADEL:<Object-GUID>).
-
Das Objekt wird in den versteckten Container Deleted Objects (CN=Deleted Objects,DC=<Domäne>,DC=<TLD>) verschoben,
der in fast allen Verzeichnispartitionen enthalten ist, außer der Schemapartition. Natürlich nur dann, wenn im System-Flags Attribut des Objekts das verschieben
durch den Wert "67108864 (0x04000000)" nicht verhindert wurde.
-
Der Garbage Collection Prozess der standardmäßig alle 12 Stunden auf jedem Domänencontroller läuft, entfernt alle nicht mehr benötigten
Attribute eines gelöschten Objekts. Das Intervall kann im Attribut garbageCollPeriod das sich im folgenden Pfad der Konfigurations-Partition befindet,
konfiguriert werden: CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,DC=<Domäne>,DC=<TLD>.
Schließlich ist es auch der Garbage Collection Prozess, der das gelöschte Objekt nach Ablauf der Tombstone Lifetime dauerhaft aus dem
Verzeichnisdienst entfernt. Als Kriterium zur endgültigen Löschung des Objekts dient die Zeit, die in When-Deleted angegeben ist.
Weiterhin führt der Prozess eine online Defragmentierung der Active Directory-Datenbank NTDS.DIT durch. Das Löschen von Objekten
verkleinert die physikalische Dateigröße der Active Directory-Datenbank NTDS.DIT allerdings nicht. Dazu wäre eine Offline-Defragmentierung notwendig,
was aber i.d.R. nicht erforderlich ist. Die online Defragmentierung reicht völlig aus.
-
Diverse Attribute bleiben in einem gelöschten Objekt (Tombstone) erhalten. Diese wären:
Attribute-ID, Attribute-Syntax, Distinguished Name, DN-Reference-Update, DNS-Host-Name, Flat-Name, Governs-ID, Group-Type,
Is-Deleted, Instance-Type, Last-Known-Parent, LDAP-Display-Name, Legacy-Exchange-DN, MS-DS-Creator-SID, MSMQ-Owner-ID, NC-Name,
Object-Class, Object-GUID, Object-SID, OM-Syntax, Proxied-Object-Name, Repl-Property-Meta-Data, SAM-Account-Name, Security-Identifier,
SID-History (ab Windows Server 2003), Sub-Class-Of, System-Flags, Trust-Attributes, Trust-Partner,Trust-Direction, Trust-Type,
User-Account-Control, USN-Changed, USN-Created, When-Created.
Zusätzlich bleiben noch die Attribute erhalten, die einen gesetzten Wert im Attribut Search-Flags haben.
Das Active Directory speichert aber weder Forward- noch Backwardlink-Attribute im Tombstone, selbst dann nicht,
wenn es im Search-Flags Attribut des Objekts eingestellt wurde.
- Welche Attribute eines gelöschten Objekts erhalten bleiben, entscheidet das vierte Bit (in Dezimal 8) des Attributs Search-Flags.
- Es werden keine Forward- sowie Backwardlink-Attribute im Tombstone gespeichert, auch nicht, wenn dies im Search-Flag Attribut eingestellt wäre.
Neben den beiden Attributen objectCategory und samAccountType, wird auch das Attribut memberOf immer von einem gelöschten Objekt entfernt.
- Wenn das Objekt auf einem Windows Server 2003 (oder höher) Domänencontroller gelöscht wurde, so wird der Ursprungsort des Objekts im Attribut
Last-Known-Parent gespeichert.
Gelöschte Objekte werden in keinem Snap-In wie z.B. „Active Directory-Benutzer und -Computer“ oder ADSIEdit angezeigt,
stattdessen können diese mit LDP.exe aus den Windows Support Tools angezeigt werden.
Wie entstehen Lingering Objects (veraltete Objekte)?
Die Namensauflösung spielt wie so oft, bei der Replikation eine wichtige Rolle. Denn Windows 2000 sowie
Windows Server 2003 Domänencontroller führen vor der eigentlichen Replikation DNS-Lookups durch. Es wird versucht den GUID-Teil des
CNAME-Records das sich in der Zone _msdcs.<Root-Domäne> befindet, des Replikationspartners, in eine IP-Adresse aufzulösen.
Somit wird sichergestellt, dass der Replikationspartner erreicht und aufgelöst werden kann. Falls Lookups nicht durchgeführt werden können,
kann keine Replikation stattfinden und somit besteht die Gefahr, dass veraltete Objekte entstehen.
Folgende Fehlersituationen können dazu führen, dass ein DC länger keine Replikation durchführen kann:
Diese Fehlerquellen könnten dafür sorgen, dass sich ein Domänencontroller nicht ordnungsgemäß replizieren kann und dadurch von
den Löschungen die das Active Directory tätigt, nichts mitbekommt. Objekte die auf allen anderen Domänencontrollern gelöscht wurden,
bleiben auf dem Domänencontroller erhalten. Da der Domänencontroller während der Tombstone-Lebensdauer nicht erreichbar (offline) war,
bekommt dieser während diesem Zeitraum nicht die gelöschten Informationen (Tombstone) repliziert. Solche Objekte werden als
Lingering Objects (veraltete Objekte) bezeichnet.
Wenn nun aber der längerfristig vom Netzwerk getrennte Domänencontroller erneut ins Netzwerk integriert wird, könnte es vorkommen,
dass dieser eines der gelöschten Objekte erneut auf alle Domänencontroller der Domäne repliziert. Dieses tritt z.B. dann auf, wenn auf dem
„veralteten“ Domänencontroller eines der gelöschten Objekte bearbeitet wird. Nach der Änderung am entsprechenden Objekt, repliziert das
Active Directory die Änderung auf einen Domänencontroller, auf diesem das Objekt - verursacht durch die Löschung - nicht mehr vorhanden ist.
Daraufhin hat der Ziel-Domänencontroller der die Replikation empfängt, folgende Möglichkeiten:
-
Ein Domänencontroller zeichnet auf, wann die letzte Replikation stattgefunden hat. Wenn die Tombstone Lifetime verstrichen ist und danach ein veralteter Domänencontroller versucht sich mit einem „aktuellen“ Domänencontroller zu replizieren, wird folgende Fehlermeldung im Verzeichnisdienstprotokoll protokolliert:
Event-ID: 2042 Quelle: NTDS Replication
Es ist zu lange her, dass dieser Computer zuletzt mit dem genannten Quellcomputer repliziert hat. Die Zeit zwischen den Replikationen mit dieser
Quelle hat die Tombstone-Ablaufzeit überschritten. Die Replikation mit dieser Quelle wurde beendet. Der Grund dafür, dass das Fortsetzen der
Replikation nicht zugelassen wird, ist, dass die Sicht der beiden Computer in Bezug auf gelöschte Objekte sich nun ggf. unterscheidet.
Der Quellcomputer hat ggf. noch Kopien von Objekten, die auf diesem Computer gelöscht (und in die Sammlung veralteter Objekte aufgenommen)
wurden. Würde der Replikation zugelassen, könnte der Quellcomputer Objekte zurückgeben, die bereits gelöscht wurden. Zeitpunkt der letzten
erfolgreichen Replikation: 2006-08-09 08:36:24 Aufrufkennung der Quelle: 43b8e6bd-h4bf-16a8-571c-6f2346653c02 Name der Quelle:
432cb837-e36c-37h3-ge5b-63egf24a1478._msdcs.<Domäne>.<TLD>.
Tombstone-Ablaufzeit (Tage): 60 usw.
In der Beschreibung werden dann folgende Lösungswege vorgeschlagen:
1. Stufen Sie den/die Computer herunter, die getrennt wurden, oder installieren Sie ihn/sie neu.
Da sich der Domänencontroller nicht ordnungsgemäß repliziert, muss zum herunterstufen (wenn diese Lösung gewählt wird) das
DCPROMO Kommando mit dem Schalter /FORCEREMOVAL ausgeführt und anschließend das Active Directory bereinigt werden:
Das Active Directory gewaltsam vom DC entfernen
How to remove data in Active Directory after an unsuccessful domain controller demotion
2. Verwenden Sie das Tool „Repadmin /removelingeringobjects", um inkonsistent gelöschte Objekte zu entfernen
und setzen Sie dann die Replikation fort.
Mit dem angegebenen Befehl, werden die veralteten Objekte entfernt. Anschließend gilt es die Replikation zu forcieren.
Dieses ist mit folgendem Befehl möglich: REPADMIN /Repl <Ziel-DC> <Alt-DC> dc=<Domäne>,dc=<TLD> /Force.
Dadurch lässt sich das Problem für die angegebene Verzeichnispartition beheben. Wenn nun die Replikation erneut startet,
kann der gleiche Fehler, diesmal für eine andere Verzeichnispartition protokolliert werden. Deshalb muss der REPADMIN-Befehl für
alle einzeln angegebenen Verzeichnispartitionen (Schemapartition, Konfigurationspartition, DomainDNSZones, ForestDNSZones) und
für alle weiteren existierenden Anwendungsverzeichnispartitionen durchgeführt werden. Für den Fall, dass auf dem DC der GC aktiviert ist,
so gilt es dieses durchzuführen:
Lingering objects may remain after you bring an out-of-date global catalog server back online
3. Setzen Sie die Replikation fort. Möglicherweise werden inkonsistent gelöschte Objekte eingeführt. Sie können die Replikation fortsetzen,
indem Sie den folgenden Registrierungsschlüssel verwenden. Es wird empfohlen, zur Wiederherstellung des Schutzes den Schlüssel zu entfernen,
sobald das System ein Mal repliziert hat. Registrierungsschlüssel:
HKLM\System\CurrentControlSet\Services\NTDS\Parameters\Allow Replication With Divergent and Corrupt Partner
Repliziert sich ein DC während der Tombstone Lifetime nicht mit anderen DCs, besteht die Gefahr,
dass auf diesem veraltete Objekte entstehen. Tritt dieser Fall ein, blockiert der Ziel-DC die eingehende (In-Bound) Replikation mit
dem „veralteten“ DC und protokolliert im Verzeichnisdienstprotokoll die Fehler-ID 2042 mit der Beschreibung wie sie hier aufgeführt ist.
Anschließend sollten die veralteten Objekte entfernt werden (weiter unten beschrieben). Für die erneute Replikation ist der folgende Wert
in der Registry zu setzen:
HKLM\System\CurrentControlSet\Services\Ntds\Parameters
Allow Replication With Divergent and Corrupt Partner
REG_DWORD
Value: 1
Der Wert in diesem Fall ist auf 1 zu setzen, damit die Replikation auf dem Ziel-Domänencontroller durchgeführt werden kann.
Wenn diese Einstellung vorgenommen wurde, ist kein Neustart des DCs notwendig.
Existiert dieser Registry-Schlüssel (der nur unter Windows Server 2003 DCs gültig ist) nicht, so gilt es diesen zu erstellen.
Diese Einstellung wäre z.B. für eine Testumgebung mit virtuellen Maschinen, die über einen längeren Zeitraum nicht in Nutzung waren das richtige.Event ID 2042: It has been too long since this machine replicated
Es sollte unbedingt darauf geachtet werden, wenn diese Einstellung in einer produktiven Umgebung eingesetzt wird,
dass nach der Replikation diese Einstellung auf 0 gesetzt wird, damit die Replikation vor veralteten Objekten geschützt werden kann!
Falls auf dem Ziel-Domänencontroller die strikte Replikationskonsistenz (Strict Replication Consistency) aktiviert ist und er eine Anfrage für die
Aktualisierung eines lokal nicht vorhandenen Objekts erhält, erkennt dieser, dass er das Objekt nicht aktualisieren kann (weil es nicht vorhanden ist)
und stoppt somit die eingehende (In-Bound) Replikation der Verzeichnispartition in dem sich das veraltete Objekt befindet.
Die Einstellung der Replikationskonsistenz (strikte oder nicht strikte) bestimmt das Verhalten eines Domänencontrollers bzgl. der Aktualisierung
von AD-Objekten die nicht mehr in seiner lokalen Datenbank vorhanden sind. Wenn also der Ziel-Domänencontroller (der DC, der das veraltete
Objekt empfangen soll) ein veraltetes Objekt vom Quell-Domänencontroller entdeckt, verschiebt der Ziel-DC die zu empfangende Verzeichnispartition
in der sich das veraltete Objekt befindet, in eine Art Quarantäne. Die Quarantäne wird erst dann aufgehoben, wenn entweder das veraltete Objekt
entfernt wird oder der Ziel-DC die Loose Replication Consistency aktiviert hat.
Standardmäßig ist die strikte Replikationskonsistenz bei einer Migration von NT 4.0 auf Windows Server 2003 oder wenn eine Gesamtstruktur
ab Windows Server 2003 erstellt wurde aktiviert. Die Funktion des Strict Replication Consistency steht ab Windows 2000 Server SP3
(sogar schon mit Post-SP2 Hotfix) zur Verfügung, diese ist aber unter Windows 2000 standardmäßig deaktiviert. Bei aktivierter Einstellung
wird die Ereignis-ID 1988 im Verzeichnisdienstprotokoll des Ziel-DCs protokolliert.
Die Lösung für diesen Fehler wäre, mit dem Befehl REPADMIN /removelingeringobjects die veralteten Objekte von dem Domänencontroller
der diese enthält zu entfernen. Dazu muss der Quell- sowie Ziel-Server ein Windows Server 2003 Domänencontroller sein.
Die Einstellung für die strikte Replikationskonsistenz, kann in der Registry im folgenden Pfad vorgenommen werden:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NTDS\Parameters
Value Name: Strict Replication Consistency
Data type: REG_DWORD
Value: 1
Hinweis: Das Heraufstufen des Domänenfunktionsmodus bzw. Gesamtstrukturfunktionsmodus ändert nicht die „Strict Replication Consistency“ Einstellung!
Falls diese Funktion auf dem Ziel-Domänencontroller deaktiviert ist (Value: 0), fordert dieser eine vollständige Replik (Kopie) des
Objekts an und fügt es in seine Verzeichnis-Datenbank hinzu. Die Deaktivierung dieser Einstellung wird als Loose Replication Consistency bezeichnet.
Wenn ein Domänencontroller unter Windows 2000 SP3 (oder höher), ein Windows 2000 Server auf Windows Server 2003 aktualisiert wurde oder
das Active Directory (DCPROMO) auf einem Windows Server 2003 Mitgliedsserver, dass Mitglied in einer Windows 2000 Gesamtstruktur ist,
installiert wurde, ist diese Option standardmäßig deaktiviert. Dabei wird die Ereignis-ID 1388 im Verzeichnisdienstprotokoll des Ziel-Domänencontrollers
(also der DC, der das nicht mehr existierende Objekt erneut repliziert bekommen soll) protokolliert.
Wird auf einem Domänencontroller die Ereignis-ID 1388 im Verzeichnisdienstprotokoll protokolliert, ist eine eingehende Replikation (In-Bound) von
einem veralteten Objekt aufgetreten. Ein Domänencontroller der die Loose Replication Consistency Einstellung aktiviert hat, bekommt eine Anfrage
für die Aktualisierung eines lokal nicht mehr vorhandenen Objekts. Der Ziel-Domänencontroller fordert danach vom Replikationspartner das vollständige
Objekt an. Der Quell-Domänencontroller (der das veraltete Objekt besitzt) repliziert es auf den Ziel-Domänencontroller und dieser fügt es in seine
Verzeichnisdatenbank hinzu.
Event ID 1388 or 1988: A lingering object is detected
Outdated Active Directory objects generate event ID 1988 in Windows Server 2003
Enable strict replication consistency
Fixing Replication Lingering Object Problems (Event IDs 1388, 1988, 2042)
Auf Domänencontrollern die mindestens unter Windows Server 2003 mit Service Pack 1 laufen, ist es nicht zwingend notwendig die Einstellung direkt in der Registry vorzunehmen. Stattdessen kann der Wert auch mit REPADMIN gesetzt werden.
Der Befehl würde folgendermaßen lauten:
REPADMIN /Regkey <DC-DNS-Name> +strict = Dieser Befehl aktiviert auf dem angegebenen DC das „Strict Replication Consistency“.
REPADMIN /Regkey <DC-DNS-Name> -strict = Dieser Befehl deaktiviert auf dem angegebenen DC das „Strict Replication Consistency“.
REPADMIN /Regkey <*> +strict = Dieser Befehl aktiviert auf allen DCs der Gesamtstruktur das „Strict Replication Consistency“.
Natürlich nur auf DCs, die unter Windows Server 2003 SP1 laufen.
Anstatt den DNS-Namen des Domänencontrollers anzugeben, kann man auch den Distinguished Name des Domänencontroller-Computerobjekts verwenden.
Falls die Loose Replication Consistency aktiviert und das Objekt repliziert wurde, sollte anschließend diese Einstellung rückgängig gemacht werden.
Zusammenfassend lässt sich ableiten, dass sich ein Domänencontroller vor “veralteten Objekten” auf zweierlei Art schützt.
Zum einen durch die Tombstone Lifetime und zum anderen durch die aktivierte Replikationskonsistenz (Strict Replication Consistency).
Damit erst keine veralteten Objekte entstehen, sollte regelmäßig die Replikation überprüft werden. Falls Replikationsprobleme bestehen,
werden diese durch Fehlermeldungen z.B. in einer Ausgabe von REPADMIN oder durch Ereignisse protokolliert.
Sollen lediglich Replikationsfehler angezeigt werden, so ist der Befehl REPADMIN /Showrepl /Errorsonly auszuführen.
Mit dem Befehl REPADMIN /SHOWREPL * /CSV > C:\Repadmin.csv kann die Ausgabe in eine Datei exportiert werden.
Mit der Eingabe REPADMIN /Experthelp bekommt man eine ausführlichere Hilfe des Befehls REPADMIN angezeigt, als mit REPADMIN /?.
Repadmin Syntax
Auch mit DCDIAG kann die Replikation überprüft werden:
DCDIAG /Test:Replications
Auf Windows Server 2003 mit SP1 kann folgender Befehl ausgeführt werden:
DCDIAG /Test:CheckSecurityError oder DCDIAG /Test:CheckSecurityError /s:<DC-Name>.
Eine weitere Möglichkeit wäre, das Attribut tombstoneLifetime mit ADSIEdit im Pfad:
CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,DC=<Domain>,DC=<TLD> zu erweitern.
Wobei in produktiven Umgebungen der Standard nicht verändert werden sollte!
Lingering objects prevent Active Directory replication from occurring
Information about lingering objects in a Windows 2000-based forest or in a Windows Server 2003-based forest
Wie kann man Lingering Objects (veraltete Objekte) entdecken und entfernen?
Ab Windows Server 2003 steht dem Administrator das Tool REPADMIN, dass Bestandteil der Windows Support Tools ist, zur Verfügung.
Damit ist es möglich, veraltete Objekte aufzuspüren und aus dem Verzeichnisdienst zu entfernen.
Der Schalter der dazu benötigt wird lautet /removelingeringobjects. Dieser Schalter prüft die Objekte auf einem Referenz-Domänencontroller
und vergleicht diese mit den Objekten des „veralteten“ Domänencontrollers (dem DC, auf dem gegebenenfalls veraltete Objekte vorhanden sind).
Zuerst sollte man sich die veralteten Objekte anzeigen lassen. Dies geht z.B. mit folgendem Befehl (bei aktiviertem Strict Replication Consistency):
REPADMIN /removelingeringobjects <DNS-Name des “veralteten” DCs> <GUID eines “aktuellen” DCs> <Verzeichnispartition worin sich die veralteten
Objekte befinden> /Advisory_Mode.
Als Beispiel:
Repadmin /removelingeringobjects alterdcon.intra.dikmenoglu.de FB1E6374-47A3-23C8-DE2F-3685A2F79268 DC=intra,DC=dikmenoglu,DC=de /Advisory_Mode
Hinweis: Um die GUID eines DCs herauszufinden, kann man z.B. den Befehl REPADMIN /Showrepl <DC-Name> eingeben.
Der Parameter /Advisory_Mode protokolliert dabei im Verzeichnisdienstprotokoll die Ereignis-ID 1946 für jedes existierende veraltete Objekt.
Wenn nun der gleiche Befehl, aber diesmal ohne den Parameter /Advisory_Mode ausgeführt wird, werden alle aufgelisteten veralteten Objekte
vom veralteten Domänencontroller entfernt. Dabei wird die Ereignis-ID 1945 im Verzeichnisdienstprotokoll protokolliert.
Weiterhin kann man sich mit dieser Abfrage, Konflikt-Objekte anzeigen lassen:
dsquery * forestroot -gc -attr distinguishedname -scope subtree -filter „(name=*CNF:*)“
Das Verzeichnisdienstprotokoll liefert bei veralteten Objekten ebenfalls wichtige Informationen.
The Repadmin.exe tool does not report existing lingering objects in Windows Server 2003
Event ID 2108 and Event ID 1084 occur during inbound replication of Active Directory in Windows 2000 Server and in Windows Server 2003
Weitere Informationen:
Windows Server Tombstone-Wiederbelebung in Active Directory -- TechNet Magazine, September 2007
Creating and Deleting Objects in Active Directory Domain Services
Viewing deleted objects in Active Directory
Deleting Items from Active Directory
Phantoms, tombstones and the infrastructure master
How the Active Directory Replication Model Works
Replication Collisions in Windows 2000
Wenn es notwendig ist, dass Domänencontroller durch eine Firewall miteinander kommunizieren (replizieren) müssen, sollten folgende Dienste mit ihren entsprechenden Ports und Protokollen zu den Domänencontrollern durchgeleitet werden:
-
RPC: 135 TCP und UDP
-
Network Basic Input/Output System (NetBIOS) name service: 137 TCP und UDP, 138 UDP und 139 TCP
-
Dynamische RPC Portzuweisung: 1024-65535 TCP
-
Server Message Block (SMB) über IP / Microsoft-DS: 445 TCP und UDP
-
Lightweight Directory Access Protocol (LDAP): 389 TCP und UDP
-
LDAP über SSL: 636 TCP
-
Globaler Katalog (GC) LDAP: 3268 TCP
-
Globaler Katalog LDAP über SSL: 3269 TCP
-
Kerberos: 88 TCP und UDP
-
Domain Name Service (DNS): 53 TCP und UDP
-
Windows Internet Name Service (WINS): 1512 TCP und UDP
-
WINS Replikation (falls benötigt): 42 TCP und UDP
Dem aufmerksamen Administrator fällt nun auf, dass die „dynamische RPC Portzuweisung“ ein Problem darstellen könnte. In der Tat, möchte man nicht die Ports von 1024 bis 65535 öffnen, deshalb ist es ratsam zu prüfen, welche Ports an der Firewall geblockt werden, um nach und nach die Ports freizugeben und nicht alle auf einmal. Abgesehen davon, lieber einen Port zu wenig aufgemacht, als einen zuviel. Deshalb muss jedes Unternehmen vor dem öffnen der Ports genauestens prüfen, welche Ports für welche Active Directory Aufgaben notwendig sind.
Man kann aber auch eine gewisse Portanzahl für die „dynamische RPC Portzuweisung“ durch einen Registry-Eintrag fest vorgeben.
How to configure RPC dynamic port allocation to work with firewalls
Den meisten Verkehr durch eine Firewall, verursachen die Authentifizierungsanforderungen, als die wären:
- Dateiserverzugriff
- DNS Abfragen
- Vertrauensstellungen
- Benutzeranmeldung
- Verbindung zwischen Mitgliedsservern und Domänencontrollern
- Active Directory Replikation
Falls Memberserver wie z.B. Windows Exchange im Perimeter-Netzwerk, Verbindung mit dem internen Netzwerk haben sollen, ist es empfehlenswert die notwendigen Protokolle und Ports (für das Active Directory sowie die benötigten Dienste) von der jeweiligen IP-Adresse zum jeweiligen Domänencontroller auf der Firewall zu beschränken.
Wenn Standorte (Niederlassungen) und somit ggf. Subdomänen erstellt werden, sind weitere Regeln auf der Firewall zu erstellen, um die Vertrauensstellung sowie Active Directory Replikation zuzulassen.
Weitere Informationen:
Active Directory and Active Directory Domain Services Port Requirements
Active Directory Replication over Firewalls
Active Directory in Networks Segmented by Firewalls
How to configure Windows Server 2003 SP1 firewall for a Domain Controller
How to configure a firewall for domains and trusts
Restricting Active Directory replication traffic to a specific port
The default dynamic port range for TCP/IP has changed in Windows Vista and in Windows Server 2008
Exchange 2000 Windows 2000 connectivity through firewalls
Service overview and network port requirements for the Windows Server system
|
Copyright © 2013 Yusuf Dikmenoglu. All rights reserved.
DasBlog 'Portal' theme by Johnny Hughes.
Pick a theme:
|
|