ADSync Multi Forest

Es gibt verschiedene Topologien zum Betrieb von ADSync. Es gibt zwar eine 1:1 Beziehung zwischen einer ADSync-Installation und einem Tenant aber auf der Seite zum lokalen Active Directory können durchaus mehrere Forests existieren. Solche Szenarien sind z.B.: beim Einsatz eines Exchange Ressource Forest erforderlich sein oder bei Migrationen von Benutzern zwischen Forests. Diese Seite beschreibt meine Erfahrungen bei der Nutzung mehrerer Forests.

Beachten Sie dazu auch die Seite ADSync - Topologien.

Umgebung

Das Basissetup ist einfach: Ich habe ein lokales Active Directory, welches mittels ADSync mit einem Tenant verbunden ist. Alle Randbedingungen wie passende UPN-Domains etc. sind natürlich zu erfüllen. Ehe ich nun aber einen zweiten Forest addieren kann, muss ich bei der Installation noch einige Voraussetzungen erfüllen.

Zu den Voraussetzungen habe ich noch ein paar Anmerkungen:

  • ADSync muss Domainmitglied sein
    Technisch sehe ich zwar keinen Grund, wenn ADSync nur per LDAP mit einem Dienstkonto mit dem Forest kommuniziert. ADSync kann also nicht als "Standalone-Version" betrieben werden. Überlegen Sie bei "Merger&Aquisitions", in welchem Forest sie daher ADSync installieren, um ihn lange zu betreiben.
  • Trust nicht erzwungen
    ADSync in einem Forest kann problemlos auf einen anderen Forest zugreifen, auch wenn es keinen Trust gibt. Es muss aber eine IP-Verbindung bestehen..
  • Merging der Benutzer
    Bei der Installation von ADSync werden sie gefragt, anhand welcher Felder Sie Benutzer verschiedener Forests "verbinden" (merge) wollen. Diese Abfrage kommt nur einmalig bei der Installation. Entscheiden Sie sich daher mit bedacht, wie eventuell mehrfach in den verschiedenen Forests vorhandene Objekte zusammengeführt werden anstatt diese als unterschiedliche Objekte zu behandeln und doppelt im AzureAD anzulegen.

Meine Empfehlung ist das Feld "Mail", welches als String gut zu pflegen und weltweit eindeutig ist.

Multi Account Merge

Wenn Sie mehrere Forests als Quelle durch einen ADSync bedienen lassen, dann müssen Sie prüfen, ob jeder Benutzer wirklich genau ein Konto hat oder ob ein Benutzer vielleicht mehrere Anmeldekonten in den verschiedenen Forests hat. Sie möchten dann natürlich, dass ADSync diese Konten nur in eine gemeinsame Cloud-Identität zusammenführt. Dies muss schon beim Setup von ADSync ausgewählt werden und kann später nur durch eine Neuinstallation von ADSync geändert werden kann.

Achtung: Dies ist die Standardeinstellung und wird nur beim Setup von ADSync abgefragt. Wenn Sie "irgendwann" einmal vorhaben, mehrere Forests zu synchronisieren, dann sollten sie hier die Einstellung schon anpassen. Ansonsten müssen Sie später ADSync noch mal neu installieren.

Mir ist aktuell noch kein anderer offizieller Weg bekannt, diese Einstellung nachträglich zu ändern. Ich nutze am liebsten das Feld "Mail"

Suchen Sie sich ein Feld aus welches ein sauberes "Matching" erlaubt. Wer einen Exchange Ressource Forest hat, muss über den Weg dann das Anmeldekonto mit der Exchange Linked Mailbox zusammenführen. Wer Forests mit dem ADMT -Active Directory Migration Toolkit migriert, kann sich z.B. den Inhalt des Feldes "mail" bedienen.

Weiteren Forest addieren

Sie können schon während der Installation von ADSync weitere Forests addieren. Das geht aber auch noch nachträglich. Hier sehen Sie den Dialog, bei dem dem ersten Forest "UCLABOR.DE" ein zweiter Forest addiert wurde. Hier kann ich den Forest "DOM2016.msxfaq.de" auch noch entfernen, weil ich ihn schon addiert aber die Konfiguration noch nicht abgeschlossen habe. Wenn ich einen weiteren Forest addieren möchte, muss ich dessen Root-Domain im rot umrandeten Feld eingeben und nach dem Druck auf "Add Directory" entsprechende Anmeldedaten (Enterprise Admin) angeben.

Sie sehen hier aber auch, dass ich die Reihenfolge nicht verändern kann. Wenn die hier besondere Vorgaben haben, dann ist das bei der Einrichtung zu berücksichtigen. Entsprechend sehen Sie auch im "Synchronization Service Manager" die Connectoren in der gleichen Reihenfolge:

Auch im "Rule Editor" ist zu sehen, dass die Reihenfolge in den Regeln abgebildet wird.

Damit ist aber auch die "Funktion" schnell beschrieben: Die Inhalte der verschiedenen Felder werden anhand der Reihenfolge ins Metaverse übernommen.

Connection entfernen

Wenn eine Migration, ein Merger oder ein CarveOut abgeschlossen ist, muss irgendwann ein Connector entfernt werden. Wenn Sie dann das ADSync-Setup erneut aufrufen, dann gibt es hier aber keinen "Delete"-Button.

Meines Wissens gibt es keinen offiziell dokumentierten Weg, wie ich eine Verbindung über das Setup entferne. Allerdings ist das Setup "nur" eine vereinfachte grafische Oberfläche des MIM-Backend und natürlich gibt es den Synchronization Service Manager. Dort gibt es beim Connector sehr wohl eine "DELETE"-Option.

Danach werden Sie gefragt, was sie genau löschen wollen. MIM kennt durch aus den Weg, dass Sie einen Connector löschen und wieder einrichten, wobei die Datenbanktabelle erhalten bleiben soll. Beim Einsatz mit ADSync würde ich immer auch den Connector Space löschen

Der Synchronization Service Manager schützt sie davor, dass Sie die Konfiguration ändern, während die Engine im Hintergrund startet. Leider deaktiviert er nicht selbst die Engine. Sie müssen das per PowerShell vorab machen:

Das Ganze geht natürlich auch per PowerShell:

Set-ADSyncScheduler -SyncCycleEnabled $false
Remove-ADSyncConnector -name "DOM2016.msxfaq.de"
Set-ADSyncScheduler -SyncCycleEnabled $true

Achtung: "Remove-ADSyncConnector -whatif"  simuliert nicht, sondern löscht auch den Connector!
Auch gibt es keine Option, die dem Auswahl zum Löschumfang in der GUI entspricht.

AD-Rechte zurückbauen

Allerdings ist damit die Deinstallation noch nicht zu Ende. Während der Installation richtet der Assistent im jeweiligen Forest ein Dienstkonto mit Berechtigungen ein und für Seamless Single Sign On auch ein Computerkonto mit dem Namen "AZUREADSSOACC". Wer es sich einfach machen will, löscht einfach das MSOL_*-Benutzerkonto und das AZUREADSSOACC-Computerkonto. Ich würde aber zumindest auch auf der Domain in den Rechten das MSOL_Konto entfernen, damit da später keine unbekannten SIDs erscheinen:

Die Berechtigungen könnten sonst bei einem Audit vielleicht einen Fehlalarm auslösen.

Ggfls. haben Sie auch noch weitere Berechtigungen für Device-Writeback, Groups Writeback V2 und Password-Writeback eingerichtet. Diese können auch auf einzelnen OUs vergeben werden. Ich hoffe, sie haben gut die Änderungen bei der Installation dokumentiert.

Weitere Links