Von: Martin Kuppinger
Mit dem Domänenmodell von Windows NT hatte Microsoft zwar bereits einen verteilten Verzeichnisdienst realisiert. Diesem fehlen aber zwei zentrale Funktionen. Zum einen wird mit einer Single-Master-Replikation gearbeitet, bei der Änderungen nur auf dem primären Domänen-Controller durchgeführt und von dort aus zu allen anderen verteilt werden. Zum anderen gibt es bei NT keine Unterscheidung zwischen der Kommunikation im LAN und im WAN. Wenn Domänen-Controller an verschiedenen Standorten im Netzwerk stehen, kann das nicht berücksichtigt werden. Neben diesen - für die Replikation relevanten - Einschränkungen gibt es noch eine Reihe weiterer Lücken, wie das nicht erweiterbare Schema und die minimale Unterstützung von hierarchischen Strukturen. Diese sind aber unter dem Aspekt der Replikation nicht von Bedeutung.
Die Multi-Master-Replikation
Im Active Directory (AD) wird dagegen mit einer Multi-Master-Replikation gearbeitet. Das bedeutet, dass Änderungen auf verschiedenen Servern durchgeführt werden können. So können die Kennwortänderungen von Benutzern beispielsweise zunächst von einem Server am Standort Stuttgart verarbeitet werden, während neue Benutzer generell in München angelegt werden. Ein solches Multi-Master-Modell setzt relativ komplexe Synchronisationsmechanismen voraus. Es muss sichergestellt werden, dass es zu keinen Problemen kommt, wenn beispielsweise das Kennwort zweimal hintereinander verändert wird und unterschiedliche Server diese Änderung verarbeiten. Der beste Schutz vor solchen Problemen ist zwar eine stringente Administration, bei der zum Beispiel vermieden wird, dass Änderungen an einem Benutzerkonto in unkoordinierter Weise von verschiedenen Administratoren durchgeführt werden. Aber auch das System muss seinen Teil dazu beitragen, dass verteilte Änderungen möglich sind.
Gleichzeitig gilt es aber auch einen Weg ohne großen Overhead dafür zu finden. Wenn ein Server für die Verarbeitung von Änderungen jeweils unmittelbar Kontakt mit anderen Servern aufnehmen muss, dann führt das zu unnötiger Last im Netzwerk. Abgesehen davon werden dann Änderungen in vielen Situationen verhindert, weil beispielsweise ein Server nicht verfügbar ist. Im Regelfall können Änderungen im Active Directory daher auf einem Server durchgeführt werden, ohne dass dieser sofort mit anderen Servern, die auch weiterhin als Domänen-Controller bezeichnet werden, Kontakt aufnehmen müsste. Die Änderungen werden protokolliert, wobei eine USN (Update Sequence Number) und eine Version - also die Information darüber, wie oft ein Eintrag verändert wurde - mitgeführt werden. Bei einem Replikationszyklus wissen Domänen-Controller dann jeweils, bis zu welcher USN sie bereits Änderungen von einem anderen Domänen-Controller empfangen haben. Sie fordern dann nur neue Zahlen an. Die Replikation erfolgt auf der Ebene von Attributen. Im Regelfall wird dabei nicht die Situation entstehen, dass es zu einem Replikationskonflikt kommt. Ist das doch der Fall, kann anhand von USN und Version in aller Regel die aktuelle Information bestimmt werden. Für den Fall, dass ein Attribut eines Objekts innerhalb eines Replikationszyklus auf zwei verschiedenen Domänen-Controllern geändert wurde, gibt es schließlich noch die Information zur Änderungszeit, die für die Konfliktlösung herangezogen wird.
Im Gegensatz zur NDS wird bei Windows 2000 allerdings ohne einen komplexen Zeitsynchronisationsmechanismus gearbeitet. Die Serverzeiten werden nur beim Start abgestimmt. Dieser Schritt erfolgt aber nicht wegen der AD-Replikation, sondern wegen der Kerberos-Authentifizierung, die in der Standardkonfiguration nur Abweichungen von fünf Minuten zwischen den Systemzeiten erlaubt. Der im Active Directory implementierte Mechanismus ist gleichermaßen einfach und effizient.
Für einige Spezialsituationen - wie beispielsweise Änderungen am Schema oder die Erweiterung der AD-Struktur - wird nicht mit dem Multi-Master-Konzept gearbeitet. Hier werden vielmehr FSMOs (Flexible Single Master Operations) verwendet, die von einem ausgewählten Domänen-Controller gesteuert werden. Standardmäßig ist das der erste Domänen-Controller, der in einem Forest beziehungsweise einer Domäne installiert wird. Die Rolle kann aber jederzeit gewechselt werden.
Die Replikationssituationen
Wesentlich interessanter aus Sicht von Administratoren als das eigentliche Replikationskonzept ist aber, wie oft eine Replikation erfolgt und wie sie gesteuert werden kann. Hier muss grundsätzlich zwischen der Replikation von Domänen-Controllern innerhalb eines Standorts und über die Standortgrenzen hinweg unterschieden werden. Die Standorte werden im Active Directory konfiguriert.
Im LAN erfolgt die Replikation standardmäßig in einem Intervall von minimal fünf Minuten, falls es Änderungen gibt. In diesem Fall sendet ein Domänen-Controller an diejenigen, mit denen er kommuniziert, Änderungsbenachrichtigungen. Diese wiederum werden standardmäßig fünf Minuten nach einer Änderung gesendet. Die anderen Domänen-Controller fordern dann die geänderten Daten von ihm an.
Davon gibt es aber auch Ausnahmen. Diese sind zum einen die dringende Replikation und zum anderen die Kennwortänderungen. Erstere erfolgt beispielsweise, wenn ein Konto nach dem Überschreiten der zulässigen Zahl von fehlerhaften Anmeldungen gesperrt wird, wenn sich der RID-Master ändert oder wenn interne Kennwörter geändert werden. Hier wird nicht mit der normalen Zeitverzögerung gearbeitet, nach der Änderungsbenachrichtigungen gesendet werden. Statt dessen werden die Replikationspartner sofort informiert. Bei Kennwortänderungen erfolgt dagegen eine unmittelbare Replikation zum PDC-Betriebsmaster, der den primären Domänen-Controller von Windows NT emuliert. Wenn dann eine Anmeldung erfolgt und das Kennwort nicht korrekt ist, leitet dieser die Anmeldung zur Verarbeitung an den PDC-Betriebsmaster weiter. Dieser hat in jedem Fall das aktuelle Kennwort.
Eine solche Weiterleitung kann im WAN über den Parameter AvoidPdcOnWan unter HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Netlogon\Parameters gesteuert werden. Steht dieser auf 1, leiten Domänen-Controller Anmeldungen mit falschem Kennwort nicht weiter. Im WAN wird auch nicht mit Änderungsbenachrichtigungen, sondern mit einem festen Intervall gearbeitet. Dieses ist standardmäßig auf drei Stunden gesetzt und kann flexibel angepasst werden, wie weiter unten noch ausgeführt wird. Änderungsbenachrichtigungen über Standortgrenzen hinweg können aber durch Anpassung eines Konfigurationsparameters im Active Directory aktiviert werden. In diesem Fall werden dann auch dringende Änderungen sofort repliziert. Das führt dann aber in der Regel zu einer deutlich höheren Last, da die Zurückhaltungsdauer für Änderungen - als Zurückhaltungszeitgeber bezeichnet - nicht getrennt für eine WAN- und LAN-Kommunikation konfiguriert werden kann. Diese wird über den Wert Replicator notify pause after modify (secs) konfiguriert. Der Parameter findet sich in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters, hat den Datentyp REG_DWORD und den Standardwert 300 (Sekunden). Der Wert kann in der Regel unverändert bleiben. Falls mit Änderungsbenachrichtigungen im WAN gearbeitet werden soll, muss dies mit einem fest vorgegebenen Bridgehead-Server erfolgen, auf dem dieser Wert dann erhöht wird, um die Replikationslast zu verringern.
Die Replikationssteuerung
Für die Administration der Replikation im AD ist es wichtig zu wissen, welche Änderungen die Berechnungen des KCC (Knowledge Consistency Checker) nur beeinflussen und welche ihn partiell deaktivieren. Die Basis für die KCC-Berechnungen stellen die Informationen zu den Standorten dar, die über Active-Directory-Standorte und -Dienste eingetragen werden.
Zusätzlich zu den Standorten, denen die Domänen-Controller zugeordnet werden, müssen Verbindungen dazwischen konfiguriert werden. Standardmäßig wird eine Verknüpfung DEFAULTIPSITELINK angeboten. Es ist aber sinnvoll, für jedes Paar von Standorten, zwischen denen es eine direkte Verbindung gibt, auch eine eigene Standortverknüpfung zu konfigurieren. Für diese können Parameter wie die Replikationshäufigkeit, Zeiten, in denen nicht repliziert werden soll und Kosten festgelegt werden. Diese Informationen werden vom KCC verwendet. Neue Standortverknüpfungen werden im Ordner Inter-Site-Transports - IP über das Kontextmenü angelegt. Es bietet sich an, diese eindeutig - beispielsweise in der Form STRHAM für die Verbindung zwischen Stuttgart und Hamburg - zu bezeichnen.
Für eine Standortverknüpfung können im Optionsfeld Kosten die Kosten der Verbindung konfiguriert werden, wobei diese umso höher sind, je weniger leistungsfähig die Leitung ist. Dabei sollte von der effektiv für die Active-Directory-Replikation verfügbaren Bandbreite ausgegangen werden. Der KCC verwendet immer die Wege mit den geringsten Kosten, auch wenn dazu gegebenenfalls über mehrere Standorte umgeleitet wird. Die Kosten verschiedener genutzter Standortverknüpfungen werden dabei addiert.
Zusätzlich kann auch ein Replikationsintervall konfiguriert werden. Der Standardwert von 180 Minuten ist in den meisten Situationen sinnvoll, da auch Service Level Agreements (SLAs) selten eine schnellere Replikation erfordern. Zulässig sind Werte zwischen 15 und 10 080 Minuten, was einer Woche entspricht. Ein Wert von 1440 Minuten und damit eine tägliche Replikation kann in vielen Situationen ebenfalls sinnvoll sein. Über die Schaltfläche Zeitplan ändern kann ein weiteres Dialogfeld aufgerufen werden, in dem die Zeiten festgelegt werden können, in denen überhaupt eine Replikation erfolgen darf. Damit können Zeitintervalle ausgeschlossen werden, in denen die Verbindung zwischen den Standorten durch andere Prozesse wie beispielsweise Backups oder Batch-Läufe belegt ist.
Auf Basis der Informationen erstellt der KCC Verbindungsobjekte, die im Detail angeben, wie zwei Domänen-Controller miteinander kommunizieren. Diese können gezielt angepasst werden, um beispielsweise festzulegen, zu welchen Zeiten genau eine Replikation erfolgen soll. Allerdings entsteht dabei das Problem, dass angepasste Verbindungsobjekte vom KCC nicht mehr neu berechnet werden. Die Anpassung sollte also nur erfolgen, wenn - in sehr großen Netzwerken - die vollständige Steuerung der Replikationstopologie und -zyklen übernommen wird. Ebenso sollten auch eigene Verbindungsobjekte nur erstellt werden, wenn die Replikation in sehr großen Netzwerken vollständig selbst konfiguriert wird.
Diese Zurückhaltung bei der Konfiguration ist von entscheidender Bedeutung dafür, dass die Replikation im Active Directory optimal funktioniert. Nur in den wenigsten Situationen ist eine Anpassung über die Optionen von Standortverknüpfungen hinaus sinnvoll. Falls man sich daran wagt, muss man sich darüber im Klaren sein, dass man dann praktisch die komplette Replikation selbst manuell steuern muss. Der Aufwand dafür ist beachtlich und macht nur in sehr großen Netzwerken Sinn. Ansonsten ist das Active Directory so ausgelegt, dass der KCC selbst die beste Lösung findet. (ok)
Zur Person
Martin Kuppinger
ist geschäftsführender Gesellschafter der IT-Networks GmbH und freier Journalist.