MSXFAQ MeetNow aktiv: Komm doch einfach dazu.

ADSync unsupportete Topologie

Diese Seite beschäftigt sich mit einer Konstellation wenn Sie zwei ADSync-Instanzen aus verschiedenen Forests zum gleichen Entra ID einrichten. Manchmal kommen Administratoren auf den Gedanken, so eine zugekaufte Firma zu integrieren.

Achtung: Die hier beschriebenen Beispiele sind keine "supportete Konfiguration" und dienen nur dem Verständnis von ADSync.
Es gibt legitime Konfigurationen die mehrere Forests mit einem Tenant zu verbinden. Siehe auch ADSync Multi Forest und ADSync - Topologien.

Topologie

Wir wissen alle, dass ein Tenant nur von genau einem aktiven ADSync-Prozess bedient werden darf und es maximal noch "Staging Server" mit der identischen Konfiguration daneben geben darf. Auf der anderen Seite gibt es Umgebungen, bei denen mehrere Forests mit dem gleichen Tenant verbunden werden müssen. Dazu gibt es zwei offizielle Wege:

  • Ein ADSync zu mehreren Forests verbinden
    Das war lange Zeit die einzige Option und bedeutet, dass ihr ADSync eine IP-Verbindung zu allen Forests aufbauen musste. Dazu gehörte also ein IP-Routing, Firewall-Freischaltungen und DNS-Auflösungen. Das kann herausfordernd sein, wenn beide Firmen die gleichen Subnetze verwenden oder die Verbindung per WAN aufwändig oder auch aus Datenschutzüberlegungen nicht erwünscht ist.
  • EntraID Cloud Sync
    Mit dem Nachfolger von ADSync können sie einfach einen Agenten im Forest installieren und loslegen.

Sie können sogar beide Produkte, ADSync und EntraID Cloud Sync parallel einsetzen. Es ist also keine "Entweder-Oder"-Frage

Dennoch finde ich mich immer wieder mit folgendem Setup konfrontiert: 

Jeder Admin eines Forest hat für sich einen ADSync installiert und gegen den gleichen Tenant konfiguriert.

Diese Konfiguration ist nicht gültig, auch wenn sie kaum Fehler sehen und anscheinend vieles funktioniert.

Setup für Benutzer

Ich habe meinen regulären Test-Forest wie gehabt genutzt, der schon für andere Tests sehr viele Konstellationen durchgeführt hat. Dort habe ich einen User "MSXFAQDEVKonflikt1" angelegt.

Er wurde sauber ins Entra ID repliziert. Ich habe zwei Replikationen forciert, damit auch der Writeback der msds-ConsitencyGUID abgeschlossen war und das System "in Ruhe" gekommen ist.

CN               : MSXFAQDEVKonflikt1
DisplayName      : MSXFAQDEVKonflikt1a
samaccountname   : MSXFAQDEVKonflikt1
UserPrincipalName: MSXFAQDEVKonflikt1@msxfaqdev.de
mail             : MSXFAQDEVKonflikt1@msxfaqdev.de

Der Benutzer wurde durch ADSync in Entra ID wie erwartet korrekt angelegt.

Dann habe ich in einem komplett separated AD-Forest einen gleichen Benutzer mit den gleichen Werten angelegt. Nur der Displayname war unterschiedlich

CN               : MSXFAQDEVKonflikt1
DisplayName      : MSXFAQDEVKonflikt1b
samaccountname   : MSXFAQDEVKonflikt1
UserPrincipalName: MSXFAQDEVKonflikt1@msxfaqdev.de
mail             : MSXFAQDEVKonflikt1@msxfaqdev.de

Erster Sync für Benutzer

Die beiden ADSync-Instanzen wissen natürlich nichts voneinander und der zweite ADSync konnte den User aus dem zweiten Forest noch auslesen aber nicht mehr in Entra ID anlegen.

Der Detailfehler war: 

Unable to update this object because the following attributes associated with this
object have values that may already be associated with another object in your local 
directory services: [ProxyAddresses <pii>SMTP:MSXFAQDEVKonflikt1@msxfaqdev.de</pii>;]. 
Correct or remove the duplicate values in your local directory. 
Please refer to http://support.microsoft.com/kb/2647098 for more information 
on identifying objects with duplicate attribute values.

Tracking Id: 0f7e8c47-41ca-4e4b-90f3-dd85dab607a6
ExtraErrorDetails:
[{"Key":"ObjectId","Value":["c1cd9079-ba03-4f51-b7e4-2ceb6a2345ec"]},
 {"Key":"ObjectIdInConflict","Value":["2193132c-05ca-4264-9fc2-dc7eb591675d"]},
 {"Key":"AttributeConflictName","Value":["ProxyAddresses"]},
 {"Key":"AttributeConflictValues","Value":["SMTP:MSXFAQDEVKonflikt1@msxfaqdev.de"]}
] 

Es fand also kein Matching über den UPN oder die Mailadresse statt. Interessant ist dabei aber, dass meine Benutzer im jeweiligen lokalen Active Directory gar keine ProxyAddresses hatten, sondern nur das Feld Mai. Dazu müssen Sie aber wissen, dass Entra ID/Exchange Online immer das Feld ProxyAdresses füllen, auch wenn es lokal nicht vorhanden ist. Der UPN bzw. das Feld "mail" sind hier der Schlüssel. Wenn "mail" gefüllt ist, wird dieser Wert genutzt. Wenn "mail" leer ist, dann wird der UPN herangezogen. Die Anleitung von Microsoft beschreibt dies als Fall 1 und Fall 2:

Ich habe im ersten Schritt dann nur das Feld "Mail" des Benutzers im zweiten Forest geleert. Danach hatte ich zwei Benutzer aber Entra ID hat den Konflikt im UPN durch eine Ersetzung gelöst.

Es fand hier kein "Matching" statt und der zweite Benutzer hat eine "onmicrosoft.com"-Domain bekommen.

Es ist also nicht möglich, dass Benutzer aus mehreren Forests den gleichen UPN nutzen.

Auch generell sollten Sie bedenken, dass ADSync immer nur seine Benutzer liest und schreibt. Er löscht also keine "DirSync-User", die durch einen anderen Tenant gekommen sind.

Writeback mit User

Ich habe nun den Fall, dass es im Entra ID neben den Benutzern des eigenen ADSync auch noch CloudOnly-User aber auch DirSync-User des anderen ADSync gibt. Ich habe daher ein "FullSync" gestartet und geschaut, welche Daten ADSnyc aus dem Tenant wieder ins eigene Metaverse zurückliest. Im Metaverse-Search habe ich nur genau die beiden "Person"-Objekte gefunden, die ich auch aus dem lokalen AD angelegt habe.

Wenn ich aber im Connectorspace zu Entra ID schaue, dann finde ich sehr viele Benutzer von denen aber nur zwei ein "True" im Connectorspace haben.

Der Connector liest also sehr wohl alle Objekte aus EntraID ein und beschränkt sich nicht auf "seine" Objekte. Das habe ich so auch erwartet. Aktuell gibt es aber keine "Synchronization Rules", um aus Entra ID eingelesene Benutzer im Metaverse anzulegen oder sogar weiter ins lokale Active Directory zu synchronisieren. Entra ID Connect kann Anfang 2026 nur Objekte aus dem lokalen AD im Metaverse anlegen und dann mit eventuell bestehenden Objekten in Entra ID matchen.

Glück gehabt, könnten sie nun sagen. Theoretisch scheint im Moment kein Schaden möglich zu sein. Aber ich würde mich nicht drauf verlassen.

Gruppen

Den Test habe ich für Gruppen wiederholt. Zuerst habe ich im ersten Forest eine einfache Gruppen angelegt:

Die Gruppe habe ich nicht mit einer Mailadresse versehen, ehe Sie von ADSync in den Tenant repliziert wurde. Auch die danach im zweiten Forest angelegte Gruppe ist weitgehend identisch.

Sie unterscheiden in der Domain und ich habe den Scope absichtlich unterschiedlich gemacht aber hat auch keine Mailadresse bekommen.

Zu meiner Überraschung wurde die zweite Gruppe parallel zur ersten Gruppe angelegt.

An der Gruppe ist zumindest im Entra ID Portal noch im MIcrosoft365 Admin-Portal direkt zu erkennen, aus welchem Quell-Forest sie kommt. Das liegt aber auch daran, das die Portale bei Gruppen nur minimale Eigenschaften anzeigen. Bei Benutzerkonten werden schon verschiedene "OnPremises*"-Eigenschaften angezeigt. Nach einem "FullSync" habe ich auch die Gruppen im Metaverse gesucht, aber nur die Gruppen aus dem jeweils lokalen AD-Forest gefunden.

 

Im Connector-Space zu EntraID sind aber sehr wohl alle Gruppen-Objekte aus EntraID zu sehen.

Aber auch hier ist nur meine eigene Gruppe über einen Connector verbunden. Analog zu Benutzern repliziert ADSync zwar die Eigenschaften von fremden Objekten bis ins lokale AD aber nicht weiter ins Metaverse. Erst über die EntraID/AzureAD-PowerShell sehen Sie, dass zumindest das Feld "OnPremisesSecurityIdentifier" einen Rückschluss auf die Quelle erlaubt.

PS /home/frank> Get-AzureADGroup -SearchString  "msxfaqdevkon" | fl *

DeletionTimestamp            : 
ObjectId                     : 3cb2bbb6-eae3-41c0-bcb3-9f3bbdb9f0ef
ObjectType                   : Group
Description                  : 
DirSyncEnabled               : True
DisplayName                  : MSXFAQDEVKonfliktgroup
LastDirSyncTime              : 1/13/2026 10:31:37 PM
Mail                         : 
MailEnabled                  : False
MailNickName                 : MSXFAQDEVKonfliktgroup
OnPremisesSecurityIdentifier : S-1-5-21-4124281298-819535733-1525930181-2092
ProvisioningErrors           : {}
ProxyAddresses               : {}
SecurityEnabled              : True

DeletionTimestamp            : 
ObjectId                     : 6bbfccd5-e34f-4e82-a70c-519d6a374557
ObjectType                   : Group
Description                  : 
DirSyncEnabled               : True
DisplayName                  : MSXFAQDEVKonfliktgroup
LastDirSyncTime              : 1/13/2026 10:37:53 PM
Mail                         : 
MailEnabled                  : False
MailNickName                 : MSXFAQDEVKonfliktgroup
OnPremisesSecurityIdentifier : S-1-5-21-1956230094-3468423799-3830862945-1155
ProvisioningErrors           : {}
ProxyAddresses               : {}
SecurityEnabled              : True

Auch hier garantiert ihnen niemand, dass sich dies zukünftig nicht doch einmal ändert. 

Hardmatch - Pending

Auf den Seiten ADSync - User Matching und ADSync - Gruppen matchen habe ich die "Matching"-Funktion beschrieben. Theoretisch könnte ich ja beim Objekt im Forest2 das Feld "msds-consistencyGUID" mit dem Inhalt des Objekts im ersten AD setzen. ADSync sollte dann beim ersten Export ins Entra ID das bestehende Objekt finden und matchen.

Ich habe diese Variante nicht weiter verfolgt, denn was bringen mir zwei ADSync-Instanzen, die bei unterschiedlichen lokalen Inhalten in eine "Race-Condition" laufen und immer wieder versuchen ihre Information anzuwenden.

Ich bin sicher, dass jede ADSync-Instanz ihre Änderung problemlos schreiben könnte. Die andere Instanz wir beim nächsten Delta-Import aber diese Änderung erkennen importieren und anhand der Synchronisationsregeln wieder überschreiben.

Devices

Ich habe nicht weiter getestet, wie "Computer" in so einer Konstellation zu betrachten sind. Ich erwarte, dass Sie wie Benutzer behandelt werden aber da ein Client immer nur genau mit einem EntraID "Joined/HybridJoined" verbunden sein kann, dürfte es kaum zu Dubletten kommen.

Auflösung in "Supported"

Wenn Sie nun feststellen, dass Sie so eine nicht supportete Konfiguration betreiben, d.h. mehrere ADSync-Instanzen aus mehreren Forest die Benutzer, Gruppen oder Computer in den gleichen Tenant replizieren, dann sollten Sie prüfen, wie sie dieses Setup bereinigen. Ich habe am Anfang beschrieben welche Wege es gibt und dies ist auch der Start der Lösung.

Hinweis:
Ich gehe davon aus, dass alle ADSync-Instanzen den gleichen SourceAnchor (msdsConsistencyGUID) nutzen. Ansonsten sollten Sie dies vorab noch korrigieren

Sie können dann die Synchronisation auf einen aktiven ADSync-Server umbauen, indem Sie:

  1. Einen ADSync zum "Master" erklären
    Von dem Server müssen Netzwerkverbindungen und DNS-Auflösungen zu den anderen Forests bestehen.
  2. Die anderen ADSync-Instanzen erst einmal beenden
    Sie könne diese später immer noch deinstallieren. Sie sollten natürlich nie bei diesen Rückbauschritten einer Anleitung folgen, die auch den DirSync im Tenant selbst abschaltet.

Jetzt habe Sie den Stand, dass nur noch ein ADSync mit dem Tenant verbunden ist aber natürlich gibt es noch keine Replikation für die Tenants, deren ADSync sie gerade stillgelegt haben. Diesen Verzeichnisabgleich können Sie nun auf zwei verschiedene Wege wieder reaktivieren

  1. EntraID Cloud Sync
    Sie könnten die Change gleich nutzen und auf den moderneren EntraID Cloud Sync umsteigen. Das ist insbesondere dann von Vorteil, wenn der verblieben ADSync nicht mit den zusätzlichen Forests kommunizieren kann. (IP-Routing, DNS-Auflösung, Firewalls etc.). In vielen Fällen ist Cloud Sync ausreichend. Lesen Sie dazu aber die noch vorhandenen Einschränkungen z.B. hinsichtlich Exchange Hybrid oder DeviceSync mit "Hybrid Joined Computerkonten".
  2. Andere Forests auf dem Master-ADSync addieren
    Wenn IP-Routing, DNS-Auflösung und Firewall passen, dann können Sie im bestehenden ADSyncServer die weiteren Forests einfach addieren. Überlegen Sie sich ein passendes Feld, um mehrfach vorhandene Identitäten zusammenzuführen.

Hinweis:
Bei der Einrichtung der weiteren Forests, die bereits früher schon durch eine andere ADSync-Instanz verwaltet wurden, könnte ADSync meckern, dass das Feld "msdsconsistencyGUID" schon verwendet wird. Das ist erwartet und soll als Schutzfunktion dienen, das Sie nicht zwei ADSync-System parallel laufen lassen. Diese Prüfung wurde mit der Version 1.1.553.0 im Herbst 2017 eingeführt. Sie müssen dann das ADSync-Setup wie folgt als Administrator starten:

"C:\Program Files\Microsoft Azure Active Directory Connect\AzureADConnect.exe" /skipldapsearch
  • FullSync
    Beim ersten Abgleich mit den neuen Forests sollte ADSync die Objekte anhand des Inhalts von msdsConsistencyGUID automatisch als "Hardmatch" korrekt zuordnen.
  • Rückbau der alten ADSync-Instanzen
    Sie können danach die alten ADSync Server über das Setup deinstallieren. Im Tenant können Sie dann auch die entsprechenden Service Principals (oder Dienstkonten bei älteren Versionen) entfernen

Wenn ihre OnPremises Umgebung keine direkte Verbindung von dem ADSync-Server zu allen Forests erlaubt, dann können Sie mit EntraID Cloud Sync arbeiten.

Weitere Links