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 und Hybrid Resource Forest

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.

Verbindungen

Sie wissen von der Seite ADSync - Topologien und ADSync unsupportete Topologie, dass ein Tenant nur durch einer aktiven ADSync-Instanz bedient werden darf. Weitere Instanzen müssen die gleiche Konfiguration nutzen und müssen als "Staging Server" laufen. In einer Multi-Forest-Umgebung bedeutet dies dann, dass diese aktive ADSync-Instanz sich zu allen anderen Forests verbinden muss. Der Server muss also

  • Namensauflösung
    Dazu muss der Server natürlich mit dem Domainnamen per DNS auch die Server auflösen können
  • IP-Routing
    Der Server muss per IP mit den DCs der anderen Domain kommunizieren können. Firewalls müssen die erforderlichen Ports zulassen. Siehe auch "Hybrid Identity Required Ports and Protocols" (https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/reference-connect-ports)
  • Credentials
    Sie müssen temporär ein Adminkonto haben, welches ein Dienstkonto für den Sync-Prozess samt Berechtigungen anlegt

Ein Trust zwischen den Forests ist nicht erforderlich, da Entra ID Connect sich explizit anmeldet.

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.

Achtung:
Dies kann nur beim initialen Setup von ADSync ausgewählt werden. Später können Sie dies nur durch eine Neuinstallation von ADSync geändert werden.

Überlegen Sie genau, welches Feld Sie als geeignet ansehen. 

Wenn Sie z.B. lokal eine Exchange Ressource Forest-Topologie nutzen und diese Hybrid mit Ressource Forest aufbauen wollen, dann wäre "msExchangeMasterAccountSID" ein geeignetes Feld, da bei einer LinkedMailbox in diesem Feld die SID des eigentliche Anmeldekontos gespeichert ist. In dem Fall ist es ideal, dass ADSync aus dem Anmeldeforest die Felder wie UPN, SAMAccountname und Password Hash Sync (PHS) bezieht und aus dem Exchange Forest die Felder wie Mail, ProxyAddresses etc.

Leider wird die Einstellung später nicht mehr angezeigt. Sie müssten also schon genau die Sync Rules analysieren, um die Einstellung wieder zu finden. Nutzen Sie dazu den Rule Editor und suchen Sie die Regeln:

In from AD – User Join

In der Join Rule sollte das Feld in der Bedingung stehen. per PowerShell geht dies auch:

Import-Module ADSync
Get-ADSyncRule `
| Where-Object {$_.Name -like "In from AD - User Join*"} `
| ForEach-Object { $_.joinhash }

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.

Feldinhalte

Sie sehen, dass es je Domain einen kompletten Satz an "Synchronization Rules" gibt und sie wissen auch, dass die niedrigere "Precedence" gewinnt. Damit lässt sich auch gut erklären, wie in die Inhalte in den meisten Fällen zusammengeführt werden.

 

Hier ist die linke Domain mit dem User an erster Stelle und daher liest ADSync von hier alle Felder aus, die er findet. Wenn ein Felder aber nicht gefüllt ist, d.h. "NULL" ist, dann wird ADSync die Daten aus dem zweiten Feld holen. Das ist solange kein Problem, so lange sie selbst dafür sorgen, dass die relevanten Inhalten entweder sowieso durch einen Abgleich zwischen den Verzeichnissen synchronisiert werden oder Sie für jede Feld für sich definiert haben, welche Quelle autoritativ ist. Leider können Sie dies nicht in ADSync selbst pro Feld einfach vornehmen. Sie müssten dazu dann schon eigene "Synchronization Rules" anlegen und anpassen.

Bei Exchange Ressource Forests ist das Vorgehen relativ einfach:

  • Forest 1 ist Account Forest
    Hier sind die Benutzer aktiv mit Kennwort, SamAccountname, UPN etc. und eventuell noch einem korrekt gefüllten Feld "Mail". Alle anderen Exchange Felder sind natürlich leer oder werden im Rahmen einer Migration aus dem Forest 2 synchronisiert.
  • Forest 2 ist der Exchange Ressource Forest
    Hier liegen die Benutzer als "Disabled Accounts" vor aber ADSync findet hier all die Exchange Attribute, die er für einen Hybrid-Betrieb benötigt. Solange diese Felder im Forest 1 nicht gefüllt sind, funktioniert dies

Als Tabelle sieht für das so aus:

Feld Forest1 Forest2 Ergebnis

SamAccountname

User1

User2

User1

Displayname

Display1

Display2

Display1

UPN

user1@msxfaq.de

user1@uclabor.de

user1@msxfaq.de

UserAccountControl

Aktiv

deaktiviert

Aktiviert

Vorname

Vorname1

<leer>

Vorname1

Nachname

<leer>

Nachname2

Nachname2

ProxyAddresses

SMTP:user1@msfaq.de

 SMTP:user1@uclabor.de
SMTP:user1@uclabor.mail.onmicrosoft.com

SMTP:user1@msfaq.de

Es werden alle Werte vom Forest 1 übernommen und die Inhalte von Forest 2 werden nur gelesen, wenn das entsprechende Feld im Forest1 nicht gefüllt ist. Das kann bei einem Exchange Ressource Forest natürlich stören, wenn irgendjemand im AccountForest auch eine Information in das Feld "ProxyAddresses" schreibt und damit die Oberhand gewinnt.

Hier ist es wichtig, dass ProxyAdresses im Account-Forest leer bleibt oder mit den Daten aus dem Exchange Ressource Forest aktualisiert werden.

Aktivierte/deaktivierte Konten

Auf einen Sonderfall möchte ich hier noch genau eingehen. Es gibt natürlich die Regeln "In from AD - UserJoin" aber für den UPN, ObjectSID und andere Werte gibt es noch eine "In from AD - User AccountEnabled"-Regel

Diese greift nur für Konten die "aktiviert" sind aber bestimmte dann die Übernahme einiger kritischer Felder:

Das bedeutet in dem Spezialfall, dass der UPN sich abhängig vom Enabled-Status des Kontos ändert. Denken Sie einmal an eine Migration von Benutzer aus einem Forest zum anderen Forest mit einem Wechsel des UPN.

Phase Bild Beschreibung

Startpunkt

 

Wir haben einen Forest mit ADSync an einem Tenant

Erweiterung um Zielforest

 

Der zweite Forest wird in ADSync als zweites Verzeichnis eingebunden und die Benutzer gematched. Das Zielkonto ist aber noch "deaktiviert".

Wie zu erwarten werden alle Informationen aus dem Forest1 weiter genutzt. Im Forest2 gibt es aktuell noch keine zusätzlichen Felder

Aktivierung des Benutzers im Ziel

Sie können sogar den Benutzer im zweiten Forest aktivieren. Da dieser nur an zweiter Stelle steht, passiert noch erst einmal nichts. Der Benutzer kann aber schon im Ziel mit seinen Anmeldedaten das ein oder andere System testen. In Microsoft 365 ist immer noch der alte Benutzer mit seinem UPN maßgeblich.

Deaktivierung im Ziel

Interessant wird es nun, wenn Sie das Konto in der Quell deaktivieren damit der Benutzer bitte mit dem neuen Konto arbeitet. Durch die Deaktivierung wird die Synchronisierungsregel "In from AD  User AccountEnabled" für den Forest1 nicht mehr aktiviert und ADSync nutzt die Daten aus dem Forest2.

Das Objekt in Entra ID und Microsoft 365 bekommt nun den UPN und das Kennwort aus dem Forest2.

Wenn Sie über dieses Verhalten bescheid wissen, dann können Sie die Logik von ADSync aktiv zur Unterstützung ihrer Migration nutzen. Es kann aber auch zu unliebsamen Überraschungen kommen, wie ein unerwartet geänderter UPN. Dies gilt insbesondere, wenn Sie beide Konten aktiv halten und die Reihenfolge der Einrichtung im ADSync nicht beachten.

Sie könnten das Verhalten durch eine Anpassung der "Preference" in den Synchronisierungsregel steuern. Ratsam ist dies aber nicht, da ein Updates von ADSync diese wieder ändert. Besser ist es die Regel "In from AD  User AccountEnabled" als Kopie vor die anderen Regeln zu legen und die Default-Regel zu deaktivieren.

Ich rate bei solch komplexeren Umgebungen immer zu einem Vorabtest mit einem eingeschränkten Scope oder eignes angelegten Testkonten. Als Dienstleister sollte man nicht beim Kunden testen, sondern ein eigenes Labor dafür nutzen. Ich leiste mir dazu z.B. Anfang 2026 insgesamt vier Tenants mit unterschiedlichen Lizenzen undvier AD-Forests mit sechs Domains, Trusts, Subnetzen etc.

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