Teil 4 - Replikation zweier AD LDS Server

Autor: olc; MCSEboard.de

Zwar liegen in unserem Beispiel noch nicht wirklich viele Daten zum Replizieren vor, das soll uns jedoch nicht davon abhalten, musterhaft auf einem zweiten Server ein Replikat der vorhandenen Instanz anzulegen. Hierzu installieren wir die Rolle AD LDS auch auf einem zweiten Windows Server 2008. Da wir uns in der Testumgebung wie oben erwähnt nicht in einer AD Umgebung befinden, muss auch hier der oben eingerichtete Benutzer (gleicher Name, gleiches Kennwort) hinzugefügt werden und ggf. eine Gruppe, deren Mitglieder die Verwaltungsaufgaben wahrnehmen dürfen. Sind die angegebenen Dienstkonten nicht gleich, kann sich der Dienst nicht am Gegenüber authentifizieren und eine Replikation ist nicht möglich.

Das Vorgehen zur Installation und Einrichtung ist größtenteils die Selbe, die wir oben durchgeführt haben. Im Gegensatz zum Vorgehen von vorhin legen wir nun jedoch ein Replikat der vorhandenen Instanz anstatt einer neuen Instanz an (siehe Abb. 35). Als Instanzname ist der gleiche Name wie auf dem ersten System zu empfehlen, um keine Unklarheiten aufkommen zu lassen. Gleiches gilt für die Ports – zwar können einige Applikationen beim Maschinenwechsel im Fehlerfall auch Ports schwenken, jedoch ist es nicht wirklich sinnvoll und übersichtlich verschiedene Ports zu wählen.
In Abb. 36 ist zu sehen, dass der Server angegeben werden muss, von dem sich die neue Instanz Ihre Daten holen wird – die Replikation der entsprechenden Instanz findet nach Abschluss der Konfiguration für diese Instanz statt.
Als nächstes muss ein Benutzer mit den Verwaltungsberechtigungen für die zu replizierende Instanz angegeben werden. Hier nutzen wir einen Benutzer der Gruppe, die als verwaltungsberechtigt angegeben wurde, im Beispiel den Administrator von der ersten Maschine „VM-W2K8-01“ (siehe Abb. 37). Im nächsten Dialog wählen wir die zu replizierende Instanz aus – im Beispiel die „instance1“ (siehe Abb. 38).

: Abb. 35

: Abb. 36

: Abb. 37

: Abb. 38

An dieser Stelle wird eines deutlich, was eine weitere Eigenschaft der AD DLS ist: tritt ein System einem sogenannten „configuration set“ bei, also einer Gruppe von Replikationspartnern, die Instanzen bzw. Anwendungsverzeichnispartitionen replizieren, muss ein Replikationspartner innerhalb dieses „configuration sets“ nicht alle verfügbaren Anwendungsverzeichnisdienstpartitionen (Application Data Partitions) replizieren. Soll beispielsweise in einem Set von 3 Maschinen nur eine Maschine alle Anwendungsverzeichnisdienstpartitionen replizieren, die beiden anderen Systeme jedoch nur selektiv eine oder zwei, so ist dies kein Problem. Es kann frei gewählt werden, welche Maschine welche Daten bekommt.

Fügt man innerhalb einer Instanz mehrere Anwendungsverzeichnisdatenpartitionen hinzu, müssen diese wie besprochen nicht auf alle „configuration set“ Member repliziert werden. Schema (und auch Configuration Partition) ist jedoch auf allen Membern eines Sets gleich. Möchte man kein einheitliches Schema, muss eine weitere Instanz verwendet werden.

Im nächsten Schritt muss nun wieder festgelegt werden, wo im Dateisystem die Datenbank und die Logfiles liegen sollen. Nachdem diese Einstellung erfolgt ist, kann der lokale Service Account festgelegt werden. Wie oben erwähnt müssen der Benutzername und das Kennwort des Serviceaccounts mit denen der Replikationspartner gleich sein, da sonst keine Dienstauthentifizierung möglich ist. Auch hier bestätigt man die Nachfrage, ob der angegebene Account das Recht zugewiesen bekommen soll, als Dienstaccount zu laufen und wählt im nächsten Dialog die Gruppe aus, die Verwaltungsaufgaben durchführen kann. Alles in allem also schon bekannte Schritte.

: Abb. 39

Nachdem alle Daten bestätigt wurden beginnt die Konfiguration der neuen Instanz. Hierbei werden nun nicht die Daten aus den LDIF-Files eingelesen, vielmehr wird eine erste Replikation der Daten vom angegeben Quell-Partner durchgeführt. Schema-, Configuration- und Application Data Partition werden nun repliziert (siehe Abb. 39).

: Abb. 40

Verbindet man sich danach mittels ADSIEdit oder LDP zur soeben replizierten Instanz sieht man, dass der Datenbestand gleich dem Bestand des anderen Servers im Konfigurationssatz ist.

Wie oben angesprochen ist die Verwaltung der Instanzen oder Konfigurationssätzen sehr ähnlich zu der Verwaltung von Active Directory Umgebungen. Verbindet man sich etwa auf den Configuration Naming Context, kann man unter dem Container „Sites“ --> „Default-First-Site-Name“ -->Rechtsklick „CN=NTDS Site Settings“ den Schedule, also den Replikationszeitplan, als Template bearbeiten (siehe Abb. 40).

Will man direkte Verbindungsobjekte bearbeiten, so tut man das auf den Connection Objects unterhalb des jeweiligen Servers bzw. der jeweiligen Instanz. Wichtig dabei ist zu beachten, dass diese Konfiguration auch bei AD Membern immer alleinstehend betrachtet werden muss – die AD LDS bringen Ihren eigenen Schedule und Ihre eigenen Site-Einrichtungen mit. Diese haben keinen Einfluss auf die Schedules oder die Site Konfiguration der AD DS oder anders herum.

Weiterhin gilt zu beachten, dass die Schedules tatsächlich nur für die Inter-Site Replikation greifen; bei der Intra-Site Replikation wird mit „change notifications“ gearbeitet. Diese Site-internen Schedules greifen also nur, wenn diese notifications nicht beim Partner angekommen sind, z.B. aufgrund von Netzwerkproblemen.

Möchte man die Replikation zwischen zwei Replikationspartnern forcieren, so ist dies beispielsweise mittels „Repadmin“ möglich – wie auch in einer AD DS Umgebung. Der Unterschied liegt hierbei lediglich darin, dass bei einem Replikationsaufruf der LDAP-Port der entsprechenden Instanz mit übergeben werden muss, da Repadmin sonst standardmäßig Port 389 für LDAP verwenden würde:

C:\Users\Administrator>repadmin /syncall localhost:10001 /A /d /e /P
Syncing all NC's held on localhost:10001.
Syncing partition: CN=instance1,DC=testdom,DC=intern
CALLBACK MESSAGE: The following replication is in progress:
    From: CN=NTDS Settings,CN=VM-W2K8-01$instance1,CN=Servers,CN=Default-First-S
ite-Name,CN=Sites,CN=Configuration,CN={9A31FCD2-5E5D-4E83-88BD-3377D54901A9}
    To  : CN=NTDS Settings,CN=VM-W2K8-02$instance1,CN=Servers,CN=Default-First-S
ite-Name,CN=Sites,CN=Configuration,CN={9A31FCD2-5E5D-4E83-88BD-3377D54901A9}
CALLBACK MESSAGE: The following replication completed successfully:
    From: CN=NTDS Settings,CN=VM-W2K8-01$instance1,CN=Servers,CN=Default-First-S
ite-Name,CN=Sites,CN=Configuration,CN={9A31FCD2-5E5D-4E83-88BD-3377D54901A9}
    To  : CN=NTDS Settings,CN=VM-W2K8-02$instance1,CN=Servers,CN=Default-First-S
ite-Name,CN=Sites,CN=Configuration,CN={9A31FCD2-5E5D-4E83-88BD-3377D54901A9}
CALLBACK MESSAGE: SyncAll Finished.
SyncAll terminated with no errors.

Syncing partition: CN=Schema,CN=Configuration,CN={9A31FCD2-5E5D-4E83-88BD-3377D5
4901A9}
CALLBACK MESSAGE: The following replication is in progress:
    From: CN=NTDS Settings,CN=VM-W2K8-01$instance1,CN=Servers,CN=Default-First-S
ite-Name,CN=Sites,CN=Configuration,CN={9A31FCD2-5E5D-4E83-88BD-3377D54901A9}
    To  : CN=NTDS Settings,CN=VM-W2K8-02$instance1,CN=Servers,CN=Default-First-S
ite-Name,CN=Sites,CN=Configuration,CN={9A31FCD2-5E5D-4E83-88BD-3377D54901A9}
CALLBACK MESSAGE: The following replication completed successfully:
    From: CN=NTDS Settings,CN=VM-W2K8-01$instance1,CN=Servers,CN=Default-First-S
ite-Name,CN=Sites,CN=Configuration,CN={9A31FCD2-5E5D-4E83-88BD-3377D54901A9}
    To  : CN=NTDS Settings,CN=VM-W2K8-02$instance1,CN=Servers,CN=Default-First-S
ite-Name,CN=Sites,CN=Configuration,CN={9A31FCD2-5E5D-4E83-88BD-3377D54901A9}
CALLBACK MESSAGE: SyncAll Finished.
SyncAll terminated with no errors.

Syncing partition: CN=Configuration,CN={9A31FCD2-5E5D-4E83-88BD-3377D54901A9}
CALLBACK MESSAGE: The following replication is in progress:
    From: CN=NTDS Settings,CN=VM-W2K8-01$instance1,CN=Servers,CN=Default-First-S
ite-Name,CN=Sites,CN=Configuration,CN={9A31FCD2-5E5D-4E83-88BD-3377D54901A9}
    To  : CN=NTDS Settings,CN=VM-W2K8-02$instance1,CN=Servers,CN=Default-First-S
ite-Name,CN=Sites,CN=Configuration,CN={9A31FCD2-5E5D-4E83-88BD-3377D54901A9}
CALLBACK MESSAGE: The following replication completed successfully:
    From: CN=NTDS Settings,CN=VM-W2K8-01$instance1,CN=Servers,CN=Default-First-S
ite-Name,CN=Sites,CN=Configuration,CN={9A31FCD2-5E5D-4E83-88BD-3377D54901A9}
    To  : CN=NTDS Settings,CN=VM-W2K8-02$instance1,CN=Servers,CN=Default-First-S
ite-Name,CN=Sites,CN=Configuration,CN={9A31FCD2-5E5D-4E83-88BD-3377D54901A9}
CALLBACK MESSAGE: SyncAll Finished.
SyncAll terminated with no errors.

Es ist grundsätzlich auch möglich, die Schedules von AD LDS Instanzen in der AD Sites & Services MMC zu bearbeiten. Hierzu müssen die AD LDS Server jedoch Memberserver einer Domäne sein und unter Windows Server 2003 und das AD DS Schema des entsprechenden Forests erweitert werden. Auch hierfür stehen die entsprechenden LDIF-Vorlagen bei Bedarf bereit. Unter Windows Server 2008 reicht es, mittels Rechtsklick auf den obersten Knoten der Sites and Services und der Auswahl des Zielservers (in diesem Fall also unseren AD LDS Server inklusive Portnummer) die entsprechende Instanz auszuwählen. Es werden nun wie auch bei DCs die Replication Links angezeigt und es ist möglich die Replikation zu forcieren oder die Schedules anzupassen.

Tipp: Weiterführende Informationen zu den Replication Schedules findet man unter anderem auch in folgendem HowTo [4]: Replication Schedules unter Windows Server 2003.

Die Replikation innerhalb der Instanzen ist Multi-Master fähig, d.h. es gibt keinen autorisierenden Server bzw. keine autorisierende Instanz, die eine Änderung annimmt und dann an alle Instanzen weitergibt, ohne Änderungen von den anderen Instanzen zu akzeptieren. Vielmehr kann eine Änderung auf allen Maschinen erfolgen, die einem „configuration set“ angehören. Die Replikation erfolgt in diesem Fall bei Schreibkonflikten wie folgt:

Zuerst wird die Version ID der beiden konkurrierenden Objekte verglichen, die höhere Version gewinnt den Konflikt. Sind diese Version IDs gleich, wird der Timestamp interessant --> auch hier zählt einmal mehr das Prinzip „last writer wins“.
Wichtig ist dabei folgender Sachverhalt: Bei Multi-Value Attributen in der AD LDS Instanz betrifft eine Änderung das gesamte Attribut, nicht nur unterschiedliche Values. Das bedeutet: Habe ich ein Attribut, was Multi-Value fähig ist und wird an mehreren Replikationspartnern ein zusätzlicher Wert in dieses Attribut geschrieben, werden die Daten nicht vermengt. Es gewinnt nur eine Änderung – diese wird durch die oben genannten Mechanismen verifiziert. Dies gilt jedoch nicht bei verlinkten Attributen (sog. Backlinks), wie es beispielsweise bei Gruppenmitgliedschaften von Benutzern der Fall ist. Hierbei können auch mehrere Änderungen gleichzeitig erfolgen, ohne dass es zu einem Konflikt kommen muss.

Der Replikationsverkehr zwischen Mitgliedern eines „configuration sets“ findet stets automatisch verschlüsselt statt. Es wird hierbei das sogenannte „Security Support Provider Interface“ (SSPI) [5] verwendet, welches die Verschlüsselung transparent für den Administrator regelt.
Welche Art der Authentifizierung verwendet wird, kann manuell festgelegt werden: Hierfür ist das Attribut „msDS-ReplAuthenticationMode“ auf dem Objekt des jeweiligen Configuration NCs verantwortlich [6].

@ MCSEboard.de, olc