Active Directory-Replikation

Standorte: die physikalische Komponente des Active Directory sowie die Topologie des Netzes

Ein Standort besteht aus einem oder mehreren Subnetzen und muss einer Standortverknüpfung angehören. Dabei kann ein Standort mehreren Domänen und eine Domäne kann mehreren Standorten angehören. In erster Linie besteht der Sinn von Standorten darin, dass man sowohl standortintern (Intra-Site) als auch standortübergreifend (Inter-Site) die Replikationsabläufe verwalten kann. Dort kann man durch Kosten, Intervall, Bridgeheadserver und Replikationspartner die Replikation beeinflussen. Damit die Replikation auch ordnungsgemäß verläuft, wird auf allen Domänencontrollern ein Konsistenzprüfungsdienst (Knowledge Consistency Checker – KCC) ausgeführt, der ständig prüft ob sich an den Gegebenheiten etwas verändert hat. Falls das so ist, passt der Prozess KCC die Replikationstopologie den Gegebenheiten an.

Mit dem Snap-In „Active Directory-Standorte und -Dienste“ kann man seine Unternehmensstruktur abbilden. Dort kann man unter anderem:

• Standorte erstellen
• Standorte umbenennen
• Standorte löschen
• Subnetze erstellen
• Standorte einem Subnetz zuordnen
• Subnetze löschen
• Globaler-Katalog-Server erzeugen
• Intervalle zur Replikation festlegen (standardmäßig alle 180 Minuten, min. 15 bis max. 10.080 Minuten)
• Replikation an bestimmten Wochentagen oder zu bestimmten Zeiten festlegen, z.B. nur nachts
• Repliziervorgang „sofort“ einsetzen (jetzt replizieren)

Die Replikation zwischen DCs innerhalb des gleichen Standortes basiert auf Benachrichtigungen, die innerhalb von fünf Minuten nach einer Objektänderung ausgegeben wird. Wenn eine Änderung an einem Objekt vorgenommen wurde, dauert es in der Regel 15 Sekunden, bis eine Änderungsnachricht (Change Notification) an den nächstliegenden Replikationspartner versandt wird. Wenn der Quelldomänencontroller mehrere Replikationspartner hat, werden nach und nach Benachrichtigungen, standardmäßig alle 3 Sekunden, an die weiteren Replikationspartner versandt (bei der Gesamtstrukturfunktionsebene Windows Server 2003).

Wenn die Domäne von Windows Server 2000 auf Windows Server 2003 aktualisiert wurde oder die Gesamtstruktur sich im „Windows Server 2000“-Modus befindet, sind es 300 Sekunden für eine Replikationsankündigung und 30 Sekunden Wartezeit (Verzögerung) für die weiteren Replikationspartner (Verhältnis 15/3 zu 300/30). Der Grund für diese deutliche Verkürzung der Replikationsverzögerung besteht darin, dass sich der Replikationsdatenverkehr als deutlich geringer herausgestellt hat, als die Entwickler beim Entwurf der ersten Active Directory-Versionen für Windows 2000 angenommen hatten.

Bei einigen Verzeichnisänderungen wie z.B. „Konto gesperrt“ oder Änderungen an den Kennwort-Policys bzw. Änderung des Domänen-Administrator-Kennworts gelten die 15 Sekunden Wartezeit nicht, sondern die Replikation erfolgt sofort. Diese sofortige Replikation wird auch als dringende Replikation bezeichnet.

Zeitpläne sind von immenser Bedeutung. Wenn z.B. eine bestimmte Zeit lang nichts verändert und damit auch keine Replikation erfolgen würde, so repliziert das Active Directory dennoch standardmäßig alle 6 Stunden, um sicherzustellen, dass alle Domänencontroller auf dem aktuellen Stand sind und dass die Replikationstopologie intakt ist und keine Verbindungsprobleme bestehen.

Wenn ein Client bootet und sich anmelden möchte, meldet er sich standardmäßig an einem Domänencontroller innerhalb des eigenen Standortes an, und wenn er eine Dienst-Anfrage startet, fragt er an einem Domänencontroller desselben Standortes an. Der Client gehört automatisch dem Standort an, welchem der Server angehört, der dem Client seine Anmeldeinformationen (IP, DNS, usw.) übermittelt hat. Falls der Server oder der Client eine IP-Adresse hat, die keinem Standort zugeordnet ist, wird der Server bzw. Client automatisch dem zuerst erstellten Standort zugeordnet, dem Standort „Standardname-des-ersten-Standorts“.

Active Directory repliziert Verzeichnisinformationen innerhalb eines Standortes (Intra-Site) häufiger als zwischen verschiedenen Standorten. So erhalten die Domänencontroller mit den schnellsten Verbindungen, also die, die bestimmte Verzeichnisinformationen am ehesten benötigen, die replizierten Daten zuerst.

Die Domänencontroller in den anderen Standorten erhalten die Änderungen ebenfalls, nur nicht so häufig, um Bandbreite zu sparen. Die Replikation zwischen den Standorten (Inter-Site) wird von Active Directory anders behandelt als standortintern, da standortübergreifend weniger Bandbreite zur Verfügung steht als standortintern. Standortintern geschieht die Replikation unkomprimiert, während sie standortübergreifend komprimiert repliziert wird.

Bei entsprechend konfigurierten Diensten kann das Datenvolumen bei der standortinternen Active Directory-Replikation Folgendes enthalten:

• Änderung an der Active Directory-Datenbank (NTDS.dit)
• Replikation des SYSVOL-Ordners
• Replikation des DFS (Distributed File Systems)

Beispiele für das Einrichten eines oder mehrerer Standorte

Das „optimale“ Replikationsverhalten hängt sehr von der physikalischen Struktur des Netzwerks ab. Wenn z.B. ein Unternehmen nur einen Standort (ein Netz) mit hoher Bandbreite hat, empfiehlt sich ein Einzelstandort. Falls das Unternehmen mehrere Standorte hat, die evtl. durch „langsame“ WAN Anbindungen untereinander verbunden sind, dann sollten mehrere Standorte eingerichtet werden, um das Replikationsverhalten präziser zu steuern. Auch reduziert sich im Zusammenhang mit der Authentifizierung die Wartezeit und die Netzwerklast ist geringer im WAN.

Vorteile eines Einzelstandorts sind:

• Einfache Replikation
• Replikation geschieht mehr oder weniger automatisch durch Änderungsnachricht – dadurch sind alle DCs stets auf dem aktuellen Stand
• Keine Replikationskonfiguration
• Weniger Hardware
• Weniger Administration

Vorteile mehrerer Standorte sind:

• Bessere Steuerung und effiziente Ausnutzung der WAN-Bandbreite bei der Replikation
• Reduzierung der Wartezeiten bei der Authentifizierung (Client sucht zuerst einen Domänencontroller am gleichen Standort, um sich anzumelden).
• Präzise Replikationssteuerung durch relative Kostenkontrolle

KCC (Knowledge Consistency Checker)

Der KCC (= Konsistenzprüfungsdienst) ist ein Prozess des Active Directory und dafür zuständig, dass die Verbindung zwischen den Replikationspartnern besteht und in der Gesamtstruktur eine effiziente Replikationstopologie entsteht. Ebenfalls sorgt der KCC für eine Konsistenz der verteilten Active Directory-Datenbank auf allen Domänencontrollern in der Gesamtstruktur. Wenn z.B. eine Verbindung/Leitung ausfällt, stellt der KCC wieder eine neue Verbindung zum Replikationspartner her. In der Regel nimmt der KCC alle 15 Minuten eine erneute Berechnung der Replikationstopologie für den Domänencontroller vor, damit Änderungen an der Active Directory-Struktur automatisch berücksichtigt werden und somit ein manuelles Eingreifen nicht erforderlich ist. Der Administrator kann weitere Verbindungen erstellen. Falls aber die Verbindung an irgendeiner Stelle abbricht, greift der KCC erneut ein und behebt dies. Dabei wird das Verfahren des Least-Cost-Spanning-Tree-Algorithmus (Inter-Site = standortübergreifend) angewendet, das auf Bandbreiteneffizienz ausgelegt ist.

Der KCC erstellt anhand eines Ringentwurfs automatisch eine effiziente Replikationstopologie innerhalb eines Standortes (Intra-Site) und eine für die standortübergreifende Replikation (zwischen den Standorten – Inter-Site).
Diese Ringtopologie versucht zwecks Fehlertoleranz mindestens zwei Verbindungen zu jedem Domänencontroller zu erstellen mit maximal 3 Hops zwischen den beliebigen DCs (dies wegen Reduzierung der Replikationswartezeit). Weiter erstellt der KCC für jede Verzeichnispartition eine eigene Replikationstopologie (Schema-, Konfigurations-, Anwendungs- sowie Domänenverzeichnispartition). Er überwacht (dynamisch) permanent die Gegebenheiten wie z.B., wenn DCs einem Standort hinzugefügt, entfernt oder verschoben werden, die Kosten sich ändern oder wenn ein Domänencontroller nicht erreichbar ist. In diesen Fällen „justiert“ der KCC nach, so dass die Replikation weiter reibungslos verläuft.

Falls man nicht möchte, dass der KCC die Replikationstopologie automatisch erstellt, kann man dies abstellen. Das bedeutet aber, dass man selbst für die Replikation des evtl. bestehenden VPNs zuständig ist, und was noch viel wichtiger ist, man bemerkt nicht sofort, wenn ein Replikationsproblem besteht. Zwar beschreibt dieser Artikel, wie man das KCC deaktiviert, aber die Empfehlung ist: Finger weg – der KCC macht seine Arbeit schnell und ordentlich: http://support.microsoft.com/kb/242780/de

ISTG (Intersite Topology Generator)

Der ISTG ist eine Komponente des KCC und für die Verwaltung und Überwachung von standortübergreifenden Replikationsverbindungen verantwortlich. Er ermittelt den jeweiligen Bridgeheadserver eines Standortes (den Domänencontroller, der für die konkrete Replikationsverbindung zwischen zwei Standorten zuständig ist), und falls dieser nicht  mehr zur Verfügung steht, sucht er sich einen neuen. Der erste Domänencontroller eines Standortes bekommt automatisch die Rolle des ISTG zugewiesen – auch wenn weitere DCs dem Standort hinzugefügt werden, behält er diese Funktion. Erst wenn dieser erste DC nicht mehr zur Verfügung steht, wird die Rolle an einen anderen Domänencontroller dieses Standortes vergeben.

In einem bestimmten Intervall (standardmäßig 30 Minuten) informiert der ISTG die anderen DCs des gleichen Standortes, dass er noch vorhanden ist. Das Intervall kann man über folgenden Registry-Schlüssel beeinflussen: „HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NTDS\Parameters“
(Attribut „InterSiteTopologyGenerator“).

Falls das Intervall verstreicht und die Information nicht repliziert wurde, geht der KCC davon aus, das dieser DC nicht mehr zur Verfügung steht und bestimmt einen neuen Domänencontroller, der die Rolle des ISTG übernimmt.
Im Active Directory des Windows 2000 Server hatte der ISTG-Algorithmus seine Grenzen und arbeitete ab ca. 300 Standorten nicht mehr effizient, so dass man diesen ISTG-Algorithmus ausschalten und die Definition und Verwaltung von Verbindungen manuell erledigen musste. Bei Windows Server 2003 wurde die Skalierbarkeit erheblich erweitert und nun ist es auch möglich, bei 3.000 Standorten immer noch eine effiziente Replikationstopologie zu ermitteln.

FRS (File Replication Service)

Der Dateireplikationsdienst ist zuständig für die Replikation der Daten im SYSVOL Verzeichnis eines Domänencontrollers. FRS wird unter Windows 2000 und Windows Server 2003 bis SP1 zudem für die Replikation des verteilten Dateisystems (DFS = Distributed File System) verwendet. An dieser Stelle sei erwähnt, dass sich dieses Verhalten in Windows Server 2003 R2 ändert, dort repliziert DFS sich über sein eigenes Replikationsverfahren.

Die eigentlichen Inhalte von Gruppenrichtlinien werden nicht im Active Directory gespeichert, sondern im Dateisystem eines Domänencontrollers(ADM-Dateien, POL-Dateien, Skripts usw.). In einer Umgebung, in der mehrere Domänencontroller existieren, sorgt FRS dafür, dass die Daten im Active Directory und auch im SYSVOL-Verzeichnis erfolgreich auf alle DCs repliziert werden, damit auch jeder Benutzer sowie Client überall die gleichen Einstellungen erhält – egal von welchem Domänencontroller er angemeldet wird. Der FRS arbeitet so wie das Active Directory nach der Multi-Master-Replikation, so dass Änderungen an jedem Domänencontroller zulässig sind. Anders als bei der Active Directory-Replikation werden die Daten bei FRS standortübergreifend nicht komprimiert, daher kann es bei großen Datenmengen eine Weile dauern, bis alle Daten repliziert worden sind, ebenso wie die Erst-Replikation eines Domänencontroller eine gewisse Zeit in Anspruch nimmt.

FRS speichert Logs, die ggf. bei Problemen behilflich sein können, im Verzeichnis „%Systemroot%\Debug“ mit den Namen Ntfrs_0001.log bis Ntfrs_0005.log. Ebenfalls wird ein Log-File erstellt (Ntfrsapi.log), wenn ein Server zum Domänencontroller herauf- oder herabgestuft wird.

FRS hat folgende Inhalts- und Datengrenzen:

• Eine maximale Dateigröße von 20 GB
• Maximal 64 GB an Daten
• Maximal 500.000 Dateien unter dem Replikationsstamm
• Maximal 1.000.000 gleichzeitige Änderungsanforderungen

Ferner hat FRS folgende Topologiegrenzen:

• Maximal 1.000 Replikationspartner
• Maximal 150 Repliken pro Computer

Replikations-Transport-Protokolle

Das Active Directory repliziert standardmäßig über Remoteprozeduraufrufe (Remote Procedure Call = RPC) over Internetprotokoll (IP). Diese Protokolle werden sowohl für die standortinterne als auch die standortübergreifende Replikation verwendet. Für die Sicherheit bei der Übertragung der Daten durch diese Protokolle sorgt einmal die Authentifizierung mit dem Kerberos V5-Authentifizierungsprotokoll und des Weiteren die Datenverschlüsselung. Eine Komprimierung der Daten findet dabei nicht statt. Die standortübergreifende IP-Replikation benutzt standardmäßig Zeitpläne, die sich aber auch ignorieren lassen.

Als weiteres Protokoll kann auch SMTP (Simple Mail Transfer Protocol) verwendet werden. SMTP kann aber NUR standortübergreifend eingesetzt werden und nicht standortintern. Da SMTP kein sicheres Protokoll ist, braucht man ebenfalls eine Organisationszertifizierungsstelle (CA), um die Replikationsinformationen digital signieren und verschlüsseln zu können. Nur so kann sichergestellt werden, dass die gesendeten Daten unverändert und die Echtzeit den Daten auf der Empfängerseite entsprechen. Eine weitere Einschränkung ist, dass man zwar die Schema-, Konfigurations- sowie Anwendungsverzeichnispartition replizieren kann, jedoch nicht die Domänenverzeichnispartition. Aus diesen Gründen wird dieses Verfahren in der Praxis so gut wie nie eingesetzt.