ADAMSync Multi Domain

Es gibt im Internet einige Anleitungen, wie man per ADAMSync ausgewählte Informationen mehrerer Forests und Domain in einer AD LDS-Instanz replizieren kann. Damit können Drittprogramme wie Faxserver (Faxnummer zu Mail), Session Border Controller (Rufnummer zu SIP-Adresse/Topologie), Spamfilter (SMTP-Adresse gültig) und andere Tools genutzt werden, die seitens des Herstellers nur einen LDAP-Server nutzen können und auch keine LDAP_REFERALS unterstützen.

Zum Verständnis dieser Seite ist es wichtig, die Funktion von AD LDS/ADAM zu kennen und insbesondere die Funktion von ADAMSync verstanden zu haben.

Diese Seite war das Ergebnis eines Support Case, der mich ein Wochenende im Testlab gekostet hat um die Funktion so gut zu verstehen, um dieses Szenario irgendwie hin zu bekommen.

Anforderung

ADAM und ADSync werden gerne genutzt, um den Zugriff von Diensten per LDAP zu ermöglichen, wenn die eigentlichen LDAP-Daten in verschiedenen Partitionen abgelegt sind. Stellen Sie sich vor, sie haben mehrere AD-Forests mit Exchange Postfächern und ein Spamfilter möchte per LDAP nach gültigen SMTP-Adressen suchen. Die eigentliche Applikation kann aber nur einen LDAP-Server ansprechen und unterstützt auch keine LDAP-Referrals. Dann muss ich irgendwie mehrere Quellen in ein Ziel bringen. Hier kann ich dann einen AD LDS-Server als LDAP-Server bereitstellen, der alle Elemente als Summe enthält.

Ich muss natürlich nun zwei oder sogar noch mehr "Sync-Prozesse" einrichten die die Objekte aus den jeweiligen Quellen in den AD LDS importieren. ADAMSync kann das, aber es ist etwas aufwändig. Allerdings sollten Sie im Hinterkopf haben, dass zumindest ein den Online Support Foren auch folgende Aussage gefallen ist:

Note that we don’t support merging multiple source domains into a single target LDS NC.
Quelle: Sumesh P - Microsoft Online Community Support 8. Aug 2011, https://social.technet.microsoft.com/Forums/windowsserver/en-US/f3c907ad-65c7-4ca0-be26-2f8d9d127a39/adamsync-aging?forum=winserverDS

Das ist natürlich ein Damoklesschwert für den Einsatz von ADAMSync, speziell es ein Updates des Betriebssystem gibt. Von Windows 2003R2 auf Windows 2008 hat Microsoft auch ADAMSync angepasst, dass bei der Angabe des Ziels keine OU's mehr möglich sind. Es kann also sein, dass die folgenden Aussagen obsolet sind. Sie können aber natürlich andere Tools einsetzen, um Objekte aus verschiedenen Quellen in eine AD LDS-Instanz kopieren oder je Quelle eine eigene Instanz einrichten.

Single App Partition

ADAMSync liest beim Start aus der Application-Partition im Feld "ConfigurationFile" eine XML-Datei mit der Konfiguration. Das bedeutet aber im Umkehrschluss, dass eine AD LDS Application Partition immer nur genau eine Konfiguration enthalten kann. Die Konfiguration selbst kann aber auch nur eine Quelle auslesen. Anders als ADSync kann ich also in einem Synchronisationslauf nicht mehrere Quelle anzapfen. . Das läuft dann darauf hinaus, dass ich bei einem Sync-Lauf jede Quelle erst als Konfiguration importieren und dann starten muss:

Jetzt muss man natürlich auf Aspekte achten.

Konflikt Beschreibung

Merge/Match

Was passiert, wenn es in mehreren Quellen z.B. die gleichen OUs oder Benutzer gibt oder bestimmte Felder wie UPN mehrfach vergeben sind?

  • Gleiche OUs
    Es ist kein Problem, wenn in mehreren Quellen z.B. die gleiche OU mit unterschiedlichen Objekten vorhanden sind. Die Objekte werden in der gleichen ZielOU liegen
  • Gleicher User
    Wenn aber zwei Objekten den gleichen CN/DN-Pfad haben, dann ändert ADAMSync die OU.

    Die beiden Objekte werden also nicht zusammengeführt oder als zwei Objekte in einer OU nebeneinander angelegt.
  • Das Feld der UPN der Objekte muss eindeutig sein
    Wenn Sie den UPN mit importieren, dann stellt ADAMSync sicher, dass der UPN im Ziel eindeutig ist.

Delete

Ein Verzeichnisabgleich muss sich auch um die Löschungen in der Quelle kümmern. Hier gibt es nun leider mehrere Optionen, wie eine Software "Löschungen" erkennen kann, z.B. per DirSyncAPI, einen Vorher/Nachher-Vergleich oder ein Aging, in dem die Zielobjekte beim Import einen Zeitstempel bekommen und am Ende dann alle nicht aktualisierten Objekte gelöscht werden.

Wer schon DirSync-Skripte selbst gebaut hat, wird um die Probleme wissen, wenn Objekte in der Quell gelöscht werden oder vielleicht einfach nur durch Verschieben oder Berechtigungen nicht mehr sichtbar sind oder eine DirSyncAPI auch "Deletions" meldet.

Sie müssen dran denken, dass ADSync immer die komplette Quell-Partition liest und dann nach <Base-DN> und <Object-filter> die relevanten Objekte erfragt. ADAMSync kann also schon erkennen, wen ein Objekt seinen Sichtbereich verlässt und das Objekt löschen.

Für dem Multi-Source-Betrieb ist das natürlich knifflig, da ein Aging nur die eigenen Objekte belässt aber die Dateien der anderen Instanzen löscht.

Daher sollten Sie Aging niciht im Regelbetrieb einsetzen

Ich habe mir daher mehrere Optionen überlegt, wie ich z.B. zwei Forests in eine AD LDS-Umgebung übertrage:

 

Option Ablauf Bewertung

1
  1. Import der Konfiguration für Quelle1 mit Aging aktiv
  2. Sync mit Quelle 1
    gültige Objekte der Quelle1 werden angelegt
    lastagedchange wird aktualisiert
    Aging lösche alle anderen Objekte
  3. Import der Konfiguration für Quelle1 ohne Aging
  4. Sync mit Quelle 2
    gültige Objekte der Quelle2 werden zusätzlich angelegt
    lastagedchange wird nicht, Aging ist aus
  5. Fertig: Objekte beider Welten vorhanden

Dies ist eine einfache und häufig beschriebene Lösung. Sie funktioniert recht gut aber hat auch Nachteile:

  • Nur Objekte der Quelle1 sind "beständig"
    Alle Objekte der danach synchronisierten Quellen werden bei Schritt 1 erst mal entfernt
  • Viele "Änderungen"
    Bei großen Mengen können die Änderungen (Löschen und Neuanlage) viel Last auf das System bringen, d.h. für Disks, CPU aber auch ggfls. Replikation zu einer Instanz

Das große Risiko ist wohl wirklich, dass am Ende des Sync von Quelle1 alle anderen Objekte erst mal verschwinden und damit auch nicht gefunden werden und jedes mal die Konfiguration überschrieben werden muss

2
  1. Import Config Quelle 1:
  2. Lauf mit Quelle 1 ohne Aging
  3. Export der Config Quelle 1
  4. Import Config Quelle 2:
  5. Laut mit Quelle 2 ohne Aging
  6. Export der Config Quelle 2

Diese abgewandelte Version würde die nach der Synchronisation geänderte Konfiguration einfach wieder exportieren und beim nächsten Mal wieder herstellen. Das klingt fast perfekt und sorgt auch für deutlich weniger Replikationslast.

Leider löscht bei mir ADAMSync keine Objekte, die in der Quelle direkt gelöscht werden. (Bug oder Feature). muss ich mir entweder zusätzlich eine Löschroutine einfallen lassen oder doch wieder mit Aging arbeiten. Dann kann ich mir diese Mühe aber sparen, das das Aging eines Sync-Jobs alle anderen Elemente dere anderne Sync-Jobs löscht.

3

Anderes DirSync Produkt

Ich habe während meiner Berufsjahre mit vielen "Dirsync-Lösungen" Kontakt gehabt. Das hat beim Exchange 5.5 Active Directory Connector begonnen. Dann kamen MIS, FIM, IIPF zum Microsoft Idendity Integration Server. Mit der Cloud gibt es den ADSync / AADConnect und selbst habe ich unzählige Skripte (CSV2EX, MiniSync, CSV2EXO, u.a.) entwickelt.

Sie müssen nicht ADAMSync nutzen, sondern können auch eigene Lösungen einsetzen, die vielleicht genau auf ihr Umfeld passen. ADAMSync ist kostenfrei aber auch limitert.

4

Mehrere Partitionen

Wenn ihre Software, die den AD LDS befragt, vielleicht doch mit LDAP-Referals umgehen kann, dann könnten Sie immer noch für jede Quelle eine eigene Application Partition nutzen und individuelle Sync-Jobs mit Aging nutzen.

Diese Konfiguration funktioniert daher nur mit deaktiviertem Aging auf allen Konfigurationsprofilen. Das bedeutet aber auch, dass in einer Quelle gelöschte Objekte nicht zwingend in der AD LDS-Instanz gelöscht werden.
Wenn sie die erste Konfiguration mit "Aging=1" starten, werden alle Objekte gelöscht die nicht aus der Quelle1 kommen und kommen erst nach dem Sync der nachfolgenden Quellen wieder dazu. Wenn Sie mit dieser kurzen Zeit leben können, z.B. wenn AD LDS nur ProxyAuth macht und sie das in der Nacht nicht brauchen und die CPU; Disk, Replikationslast vertretbar ist, dann könnte dies eine Lösung sein.

Es bleibt ein "not supported" Szenario und ist von Microsoft nicht beschrieben oder getestet. Die nächste ADAMSync-Version kann schon wieder anders arbeiten.

Mehrere Partitionen

Wenn ihr LDAP-Client mit "chasing referrals" umgehen kann, dann können Sie die nativen ADAMSync-Funktionen mit mehreren Application Partitions nutzen.

Sie legen z.B. eine Root-Partition und daneben noch für jede Quelle eine weitere Partition im AD LDS an. Über getrennte Konfigurationen replizieren Sie dann die Objekte der jeweiligen Quelle in die entsprechende Ziel-Partition. Die Applikation selbst verbindet sich aber mit der Root-Partition, in der aber keine Objekte vorhanden sind. AD LDS verweist aber die Anfrage auf die jeweils andere Partition. Allerdings muss die Application so einen "Referral" unterstützen.

Bislang habe ich diese Konfiguration nur in einem Lab nachgestellt.

Weitere Links

ADAMSYNC is a command-line utility that performs a one-way synchronization of data from Active Directory into ADAM. Adamsync uses an XML-based con-figuration file that drives the parameters of the ongoing synchronization