Cross-tenant sync - Details

Diese Seite beschäftigt sich mit den Hintergründen und Feinheiten zum Cross-tenant sync und der Cross-tenant sync - Konfiguration.

Testserie

Wer eine Synchronisation betreibt, muss auch mit den Konflikten umgehen. ich hatte den Sync auf "automatisch" gestellt, womit er aktuell alle 40 Min läuft. Änderungen brauchen daher immer einige Zeit.

Denken Sie daran, dass "Cross-tenant Sync" keine Änderungen im Ziel sucht oder erkennt und entsprechend nicht korrigiert.

Die Suche in der Quelle basiert auf Änderungen, d.h. der Provisioning-Prozess sucht seit dem letzten Lauf geänderte Objekte, ähnlich der lokalen Windows AD DirsyncAPI oder über USN oder Last Modified

Einen "FullSync können Sie pro Objekt mit einem manuellen "Provisioning on demand" oder durch einen Neustart des Synchronisation auslösen. Verändert aber dann die Ergebnisse im Unterschied zu einem "Delta"-Sync des Regelbetriebs.

Normalerweise legt der Sync "MemberUser" an. Ich habe in meinem Lab dies angepasst, dass er "Guest"-User anlegt.

Hier meine Testergebnisse (Stand Juni 2023):

Testfall Synchronisiert? Status Verhalten

Regulärer Testuser Typ= Member

 Ja

OK

Der reguläre Benutzer der Quelle wird natürlich im Ziel angelegt. Da ich den "UserType" auf "Guest" gestellt habe, ist es ein Gast im Ziel.

Regulärer Testuser Typ= Gast

 Ja

OK

Aber auch ein regulärer Benutzer vom Type "Guest" aus der Quelle wird im Ziel angelegt. Da ich den "UserType" auf "Guest" gestellt habe, ist es ein Gast im Ziel.

Regulärer Testuser ohne AzureAD P1-Lizenz

 Ja

OK

 Wird repliziert. Anscheinend prüft "Cross-tenant Sync" nicht, ob das Quellobjekt auch eine AzureAD P1-Lizenz zugewiesen bekommen hat.

Regulärer Testuser mit "onmicrosoft.com UPN"

 Ja

OK

 Der "Cross-tenant Sync" ist nicht auf legacy-Domains beschränkt. Auch onmicrosoft.com-Konten kommen mit

Konflikt mit bestehendem Gast

Nein, erwartet

OK

Ich habe im Ziel einen Benutzer angelegt und ihm die Mailadresse eines Benutzers in der Quelle gegeben.

Beim nächsten Export sollte es zu einem Konflikt kommen. Das konnte im Provisioninglog auch nachvollzogen werden.

"Cross-tenant sync" nutzt zwar das Feld "Mail" nicht zum matchen aber erkennt Konflikte und blockiert.

Solche Konflikte muss der Admin der Quelle manuell lösen, indem er den Admin im Ziel informiert.

Gast-Benutzer mit LiveID in der Quelle

 Nein, erwartet

OK

Wie erwartet wurde ein Gast-Konto in der Quelle mit einer LiveID wird natürlich nicht synchronisiert, auch wenn er im Scope eingeschlossen ist.

Gast-Benutzer mit ExternalAzureAD

Nein, erwartet

OK

Wie erwartet wurde ein Gast-Konto in der Quelle mit einer externen Identitäten natürlich nicht synchronisiert.

Identityprovider ist carius.onmicrosoft.com

Gast-Benutzer eines anderen Tenant in der Quelle

Nein, erwartet

OK

Ein Gast-Konto in der Quelle wird ebenfalls nicht synchronisiert, auch wenn er im Scope eingeschlossen ist. Das ist aber so erwartet. 

Regulärer Testuser Delete1 Typ= Member aus Gruppe entfernt

Ja

OK

 Konto wird bei aktivierter "Delete-Option" im Ziel in den Papierkorb verschoben.

Benutzer  in der Quelle gelöscht

Ja

OK

Wenn "Crosstenant Sync" den "Delete" in der Quelle erkennt und Sie "Delete" als Option im Sync aktiviert haben dann wird das Objekte auch im Ziel gelöscht.

Genaugenommen erkennt er wohl das "Soft Delete" als Change.

Benutzer manuell in der Quelle mittels "Hard delete" gelöscht"

Ja

OK

Natürlich habe ich nun auch einen Test-User in der Quelle komplett gelöscht. Er ist also nicht mehr "softDelete=True". Der nächste Lauf findet dennoch das nicht mehr vorhandene Objekt und löscht es im Ziel.

Benutzer im Ziel gelöscht

 

Warn

Wenn der Administrator im Ziel-Tenant das durch den Sync angelegte Konto löscht, dann landet es im Papierkorb und nach 30 weiteren Tagen ist des komplett weg. "Cross-tenant sync" in der Quelle beschwert sich zwar leise aber holt das Objekt beim regulären Sync-Lauf nicht mehr zurück.

Erst wenn das Objekt in der Quelle geändert wird, erkennt der Sync-Prozess dies und holt das Konto zurück.

Der Administrator in der Quelle kann aber jederzeit einen "FullSync" oder ein "On demand provisioning" anstoßen, damit das Objekt wieder neu angelegt oder aus Papierkorb zurückgeholt und aktualisiert wird.

Neusync eines im Ziel "soft deleted" Users

OK

Durch einen FullSync wird ein Konto aus dem Papierkorb reaktiviert.

Manchmal funktioniert es aber wohl nicht. Dann muss der Admin im Ziel das Objekt wieder herstellen.

Neusync eines im Ziel "hard deleted" Users

Ja

OK

Durch einen manuell auszulösenden FullSync wird das Objekt im Ziel neu angelegt. Es muss aber vom Administrator im Ziel wieder komplett neu berechtigt werden.

Änderungen der Regeln -> Fullsync?

Ja

OK

Änderungen an den Sync-Regeln triggern einen neuen FullSync.

Gruppen

Nein

OK

Aktuell synchronisiert "Cross-tenant Sync" keine Gruppen. Sie können aber die Mitgliedschaft in einer Gruppe als Scope nutzen.

Partnerschaft gelöscht

Nein

Warn

Der letzte Test ist das Löschen der "Cross-tenant Sync"-Konfiguration in der Quelle. Ich entferne also nicht erst alle Benutzer aus den Scope und warte einen letzten Sync ab, sondern lösche direkt die Konfiguration.

Die Objekte im Ziel sind unverändert verblieben.

Matching und Linking

Bei jedem Verzeichnisabgleich muss überlegt werden, wie die von der Quelle im Ziel angelegte Objekte wiedergefunden wrden. Insbesondere könnte der Administrator im Ziel das Objekt ja umbenennen, löschen o.ä. Bei einem klassischen Active Directory gibt es ja sogar mehrere Domains und OUs, in die solche Dirsync-Objekte verlagert und damit aus dem Write-Scope des Sync-Prozess verschwinden. Im AzureAD gibt es keine "OU" und nicht mal Domains, sondern es ist quasi eine flache "Userliste".

Laut Microsoft findet ein Matching statt, aber beschreibt nicht, welche Felder per Default genutzt werden.


Quelle: Auf What is cross-tenant synchronization? - Object types
https://learn.microsoft.com/en-us/azure/active-directory/multi-tenant-organizations/cross-tenant-synchronization-overview#object-types 

Allerdings können Sie dies auch einfach in der Konfiguration einsehen. Bei der Zuordnung der Attribute können Sie auch vorgeben. welche Werte nach der Konvertierung ins Ziel verbunden mit einer Priorität dafür genutzt werden

In der Standardkonfiguration wird nur die "NetID" dazu genutzt und weder das Feld "mail" noch "UserPrincipalname", die sich z.B. bei Heirat/Scheidung/Umfirmierung ja auch ändern können.

Interessant fand ich im ProvisioningLog aber auch, dass es ein Feld im Ziel gibt, welches in der Liste der Felder nicht aufgeführt ist.

Anscheinend merkt sich "Cross-tenant sync" im Feld "Source" im Ziel, woher das Element gekommen ist.

Über die AzureAD oder AzureADPreview-PowerShell kommt man aber ebenso wenig an das Feld wie per Azure Portal. Es wäre doch nett, wenn ein Admin im Ziel anhand dieses Feldes einen Filter oder Ansicht erhalten könnte.

Auch eine direkte Abfrage per Graph (1.0 und beta) lieferte genau diese Feld nicht.

FullSync/DeltaSync

Wenn Sie mit ADSync / AADConnect zu tun haben, dann kennen Sie schon den Unterschied zwischen "Differenz/Incremental-Sync" und einem kompletten "Full/Initial-Sync". Ein kompletter Abgleich findet in der Regel zu Beginn statt während danach es speziell in größeren Umgebungen zu teuer ist, immer wieder alle Elemente zu lesen und zu schreiben.

Von Vorteil ist es, wenn die Quelle schon die Möglichkeit zur Abfrage von Änderungen bietet. Das kann z.B. das Active Directory entweder über USNs (Get-USNChanges) oder DirSyncAPI (GET-ADChanges). Die Anfrage von "USNChanged" braucht weniger Rechte aber liefert nicht alle Felder und könnte bei Löschen von Objekten in der Quelle dies nicht zuverlässig erkennen.

Auch das AzureAD kennt wohl den ähnlichen Ansatz denn "Cross-tenant sync" kann schon zuverlässig die Änderungen in der Quell als auch Löschungen erkennen und die Felder gemäß der Konfiguration in das Ziel übertragen.

Eine Änderung an der Konfiguration, z.B. des Scope kann auch einen FullSync anstoßen.

Auch die Änderungen von Mappings startet die Synchronisation neu.

Natürlich kann ich jederzeit z.B. über Azure Portal den Sync anhalten, starten oder gleich neustarten. 

Der druck auf "Restart Provisioning" entspricht eine "Stop provisioning" mit nachfolgendem "Start provisioning". Der Druck auf "Stop/Start" ändert auch den Schieber in der Konfiguration.

Überlappende Sync-Jobs

AzureAD verhindert nicht, dass Sie mehrere Synchronisierungsjobs in einer Quelle zum gleichen Ziel anlegen.

Das mag auf den ersten Blick unsinnig erscheinen, aber es gibt schon Konstellationen, bei denen z.B. in der Quelle verschiedene Benutzerkreise im gleichen Ziel mit anderen Feldern gefüllt werden sollen. Entsprechend haben ich in jeder Konfiguration ein Mapping addiert, welches in das Feld "Company" einen eindeutigen String schreibt.

Entsprechend war ich dann mal gespannt, welche Information im Ziel ankommt und welche Konflikte es gibt.

Testfall Synchronisiert? Status Verhalten

Initiale Einrichtung

 Ja

OK

Der erste Job legt den Benutzer an und der zweite Job erkennt ein "RedundantExport

User aus Scope

Ja

Warn

Wenn ich einen Benutzer aus SYNC2 aus dem Scope nehme, dann löscht er diesen im Ziel, obwohl der andere Sync-Job diesen auch synchronisieren würde. SYNC1 bemerktt dies nicht!, d.h. es erfolgt kein Reexport.

Lösung: Manuell ein "On demand Provisioning" für das Objekt machen oder den Sync neustarten.

Feldkonflikt

Last Write Wins

Warn

Normalerweise gibt es den Fall nicht, dass das gleiche Objekt durch zwei Syncs in den gleichen Zieltenant repliziert wird. Ich habe es dennoch absichtlich "falsch" gemacht und zusätzlich ein Feld abweichend übertragen

Wenn sich in der Quelle etwas ändert, erkennen beide Sync-Jobs diese Änderungen. Letztlich gewinnt der zuletzt ausgeführte Job.

Sync Fehler bei Konflikt

Einen Fehler konnte ich produziere, der nicht direkt zu sehen ist. Ich habe einige Synchronisationen getestet und in dem Zuge auch einen Benutzer wieder im Ziel gelöscht und dann die Mailadresse einem anderen Benutzer gegeben. Ich habe auf einen Fehler im ProvisioningLog gehofft, aber der kam nicht. im Ziel einen Benutzer angelegt, der die gleiche Mailadresse wie ein danach zu synchronisierendes Konto hat:

Der nächste Lauf hat aber folgende Meldung geliefert:

Angeblich findet "Cross-tenant Sync" einen passenden Benutzer im Ziel mit der angegeben GUID. Schade nur, dass ich den Benutzer nicht im AzureAD sehe und auch per PowerShell nicht finden kann.

Selbst nach einigen Stunden Replikation hat sich hier nichts gebessert. Ich habe dann ein "Provisioning on demand " für den Benutzer gestartet und da war die Aussage dann doch wieder eindeutig:

Wichtig: Laut meiner Beobachtung landen "Provisioning on demand"-Aktionen aus mir unverständlichen Gründen nicht im Provisoininglog der Quelle.

Sync-Problem mit Delete

Einen weiteren Fall habe ich entdeckt, bei der ein Sync eines Objekts nicht mehr funktioniert hat. Der Prozess war:

  • Benutzer in der Quelle aus dem Sync rausnehmen
  • Das Objekt wird im Ziel dann nicht gelöscht (?)
  • Admin im Ziel löscht das Objekt nach SoftDelete"
  • Quelle nimmt Objekt wieder in den Sync auf
  • Sync meldet "alles ok" aber Objekt bleibt in Soft-Delete State

Gelöst habe ich dies dann einfach, indem ich die Synchronisation über einen "Restart" neu gestartet habe:

Das entspricht wohl einem "Full Sync". Ich vermute mal, dass auch "Cross-tenant sync" mit einem Metaverse arbeitet und eben nicht direkt die Quelle und Ziel anspricht, sondern zumindest beim Schreiben ins Ziel die Daten mit einem Cache oder Connector Space vergleich.

Sync-Problem mit Undelete

Ausgangssituation war ein Cloud-Only-Benutzer in der Quell, welcher durch einen Sync-Job in das Ziel kopiert wurde. Dann hat der Administrator im Ziel das Objekt gelöscht, war er ja tun kann. Die nachfolgenden Syncs haben das Objekt nicht wieder restauriert. Um die Wiederherstellung zu erzwingen, haben ich dann in der Quelle den "Displaynamen" des Objekts geändert. Beim nächsten Lauf hat "Cross-tenant sync" dann das Objekt wieder aus dem Papierkorb geholt. Laut Protokoll hat er auch den Displaynamen korrekt gelesen

Und sogar ein Update gemacht:

Allerdings ist im Ziel diese Änderung nicht angekommen. Eventuell haben sich der "Undelete" und der update unglücklich überschnitten. Ein Blick in das Autit-Log im Ziel zeigt auch, was passiert ist:

ich habe gegen 07:20 den Benutzer gelöscht und der nächste Sync startete um 7:30. Zuerst wurde der Benutzer per "Restore user" zurück geholt und dann mit einem Update-user folgende Informationen geschrieben:

Für eine kurze Zeit war alles wir erwartet aber um 7:30:52, also ca.14 Sekunden später erfolgte ein "User Update" durch das "Microsoft Substrate Management" und schreibt den alten Wert wieder hinein

Den Grund konnte ich dazu noch nicht ausfindig machen und ich werde bei Gelegenheit den Test wiederholen. Ein manueller FullSync oder eine erneute Änderung in der Quelle hat die Unstimmigkeit wieder korrigiert. Schön ist es aber nicht.

Quarantäne

Natürlich wollte ich auch sehen, wie Fehler bei der Konfiguration sich auswirken. Ich habe dazu im Ziel einfach die Checkbox deaktiviert, mit der ich der Quelle erlaube die Objekte in meinem Tenant anzulegen:

Beim nächsten Sync hat der Prozess dies gemerkt und den Prozess in Quarantäne gestellt. Die Fehlerbeschreibung ist selbsterklärend. Anscheinend ändert dies aber auch das Intervall von 40 Minuten auf 2h40Min.

Der Link in der Beschreibung wird auf einen Artikel in der Microsoft Dokumentation umgeleitet der dem Fehler schon recht nahe kommt.

Einschätzung

Ich habe auf dieser Seite viele Tests und deren Ergebnisse dokumentiert, wie ich sie mit Cross-tenant sync" vom Stand Juni 2023 in zwei europäischen Tenants nachstellen konnte. Sie sehen aber auch, dass es durchaus Fälle gibt, in denen die Funktion nicht "selbstheilend" ist. Insbesondere wenn der Administrator im Ziel-Tenant an den per Sync verwalteten Identitäten etwas verändert, kann der Abgleich aus dem Tritt kommen. Die Quelle ist zwar für die konfigurierten Attribute autoritativ aber nicht dominant, d.h. Sie überschreibt keine Werte im Ziel, um sie auf die Werte der Quelle abzugleichen.

Erst wenn Sie in der Quelle an dem Objekt etwas ändern, sie ein "Provisioning on Demand" oder einen FulSync starten, dann liest der Prozess die Daten in der Quelle aus und überschreibt die Einstellungen im Ziel. Weitere Besonderheiten müssen Sie beim Thema "Löschen" beachten, sei es bei Objekten in der Quelle, im Ziel oder der Synchronisation.

Weitere Links

John Savill's Technical Training: Azure AD Cross-Tenant Sync
https://www.youtube.com/watch?v=z0J5kteqUVQ