Entra Cross-Tenant-Synchronisierung: Mandanten verbinden, ohne eine Einheit vorzutäuschen

Nach einer Übernahme entsteht meist sofort derselbe Wunsch: Mitarbeitende sollen Kolleginnen und Kollegen finden und auf Teams oder SharePoint des anderen Unternehmens zugreifen, obwohl Postfächer, Geräte und Daten noch nicht umziehen. Entra Cross-Tenant Synchronization kann diesen Zwischenzustand beherrschbar machen. Sie erzeugt jedoch keinen gemeinsamen Mandanten und ist kein Migrationswerkzeug. Automatisiert wird der Lebenszyklus von B2B-Identitäten zwischen Quelle und Ziel. Wer diese Grenze übersieht, erhält vielleicht eine bessere Personensuche, baut aber zugleich ein zweites Verzeichnis mit unklarer Attributhoheit, Exchange-Problemen und riskantem Offboarding.

Klären Sie zuerst Zusammenarbeit oder Konsolidierung

Die Funktion ist für Organisationen mit mehreren eigenen Mandanten gedacht, die B2B-Objekte automatisiert erstellen, aktualisieren und entfernen möchten. Die Person authentifiziert sich weiterhin im Heimatmandanten; Daten bleiben an ihrem Speicherort. Microsoft stellt ausdrücklich klar, dass weder Postfach noch OneDrive oder SharePoint migriert werden und der Quellmandant für die Anmeldung erforderlich bleibt. Soll nach einer Übernahme ein Verzeichnis, ein Postfach und eine Geräteverwaltung entstehen, ist die Synchronisierung eine Koexistenzphase innerhalb des Migrationsprogramms, nicht dessen Endzustand.

Was zwischen Quelle und Ziel tatsächlich läuft

Die Bereitstellung ist ein einseitiger Push aus dem Quellmandanten. Dort werden Scope, Zuordnungen und Transformationen definiert; der Zielmandant erlaubt eingehende Synchronisierung und kann sie stoppen. Automatic Redemption muss auf beiden Seiten in der richtigen Richtung eingerichtet sein. Andernfalls sieht der Nutzer einen Consent-Dialog oder der Verbindungstest meldet irreführend scheinbar ungültige Administrator-Anmeldedaten. Laut aktueller Dokumentation startet das Intervall ungefähr alle 40 Minuten; der erste Lauf kann deutlich länger dauern als spätere inkrementelle Zyklen.

Eine Multitenant Organization ergänzt Microsoft-365-Kontext

Eine Multitenant Organization, kurz MTO, liegt über den Mandantenbeziehungen und Synchronisierungen. Für Teams werden externe Benutzer als Member statt als klassische Guests bereitgestellt, damit Microsoft 365 ein kohärenteres Erlebnis bieten kann. Im Microsoft-365-Admincenter werden dieselben ausgewählten Personen in alle MTO-Mandanten synchronisiert; unterschiedliche Ziel-Scopes erfordern die Konfiguration in Entra ID. MTO verbessert Zusammenarbeit und Personensuche, verwaltet aber Exchange, Intune oder Conditional Access nicht zentral für alle Mandanten.

Benutzer- und Gruppensynchronisierung haben andere Lizenzgrenzen

Für Benutzer im selben Cloud-Umfeld benötigt jede synchronisierte Person Entra ID P1 im Heimat-Quellmandanten; im Ziel ist nur für die Synchronisierung keine zusätzliche Lizenz erforderlich. Gruppen-Synchronisierung und Cross-Cloud-Szenarien verlangen Entra ID Governance oder Entra Suite in der Quelle. Zieldienste können eigene Lizenzen benötigen, und External-ID-Abrechnung kann andere externe Szenarien betreffen. Kalkulieren Sie nach Personen und genutzten Fähigkeiten, nicht nach der Zahl der B2B-Objekte.

Die Zuordnung vorhandener Konten ist das größte Pilotrisiko

Entra ordnet ein internes Quellkonto über alternativeSecurityIdentifier einem externen Zielobjekt zu. Ein vorhandenes B2B-Objekt kann übernommen werden; zwei bereits intern vorhandene Member-Konten lassen sich jedoch nicht zusammenführen. Standardzuordnungen ändern einen historischen Guest auch nicht zwingend in Member, wenn userType nicht bewusst gesetzt wird. Erstellen Sie deshalb vorab eine Matrix mit Heimatkonto, Zielobjekt, Postfach, UPN, primärer SMTP-Adresse, Object ID und gewünschtem Ergebnis. Sonst fällt ein Duplikat womöglich erst im People Picker oder in Teams auf.

Exchange-Attribute benötigen ein eigenes Design

Die subtilsten Fehler liegen häufig in Exchange. Cross-Tenant Synchronization erstellt einen B2B-Benutzer, keinen Mail Contact, und kann nicht beliebig alle Exchange-Attribute schreiben. proxyAddresses kann im Ziel schreibgeschützt sein, targetAddress steht nicht als normale Zuordnung zur Verfügung, und die Sichtbarkeit in Adresslisten verhält sich anders als ein gewöhnliches Entra-Attribut. showInAddressList kann die Personensuche unterstützen, beweist aber weder Mailrouting noch Free/Busy oder eine konsistente GAL. Prüfen Sie diese Ergebnisse getrennt.

Scope nach Zielressourcen statt nur nach Organigramm

Beginnen Sie mit Personen, die konkrete Anwendungen im Ziel benötigen. Alle Mitarbeitenden zu synchronisieren verbessert möglicherweise die Suche, vergrößert aber auch den Kreis für Conditional Access, Reporting, Datenschutzhinweise und Offboarding. Für Gruppen gelten weitere Grenzen: Im Ziel entstehen statische Security Groups, keine Microsoft-365-, Verteiler- oder mailfähigen Sicherheitsgruppen; verschachtelte und rollenzuweisbare Gruppen werden nicht unterstützt. Group Sync verlangt „Sync only assigned users and groups“. Eine dynamische Quellgruppe kann Mitglieder auswählen, das Ziel bleibt statisch.

Deprovisionierung verändert Zugriff und ist kein Aufräumen

Wird eine Person aus dem Scope entfernt, wird ihr Zielobjekt soft-deleted. Das ist nur sicher, wenn Anwendungszuweisungen, Gruppen, Eigentum und Wiederherstellungsfenster bekannt sind. Ein Objekt lässt sich normalerweise 30 Tage wiederherstellen; On-Demand Provisioning belebt es aber nicht zwingend automatisch, und ein neues Objekt kann ein Duplikat erzeugen. Lassen Sie die eingehende Synchronisierung aktiv, bis die kontrollierte Deprovisionierung abgeschlossen ist. Testen Sie Blockieren, Scope-Entfernung, Restore und endgültiges Löschen als eigene Kette.

Hub-and-Spoke und Mesh haben unterschiedliche Betriebskosten

Jede Richtung Source–Target ist eine eigene Konfiguration. Ein Mesh aus drei Mandanten besteht daher aus mehreren Vertrauensbeziehungen, Mapping-Sätzen und Log-Streams. Hub-and-Spoke reduziert die Zahl der Verbindungen, macht den Hub aber für Anwendungszugriffe kritisch. Zählen Sie Konfigurationen, Verantwortliche, Break-Glass-Verfahren und Deprovisionierungsflüsse je Richtung. Externe Objekte werden nicht erneut weitergereicht; das verhindert Schleifen, bedeutet aber auch, dass eine Identität nicht automatisch durch einen Zwischenmandanten wandert.

Sechs Schritte für einen sicheren Rollout

1. 01

   Heimat der Identität festlegen

   Pro Person einen autoritativen Mandanten bestimmen und parallele interne Konten verhindern

2. 02

   Kollisionen inventarisieren

   Historische Guests, Members, Kontakte, Postfächer und doppelte Adressen finden

3. 03

   Minimalen Scope entwerfen

   Pilot nach Zielressourcen und Risiko statt nur nach Abteilung wählen

4. 04

   Beidseitiges Vertrauen konfigurieren

   Inbound Sync, Automatic Redemption, MFA Trust und Conditional Access prüfen

5. 05

   Lebenszyklus durchspielen

   Create, Update, Managerwechsel, Block, Remove, Restore und Hard Delete testen

6. 06

   Mit Telemetrie erweitern

   Provisioning-Fehler, Sign-ins, Duplikate sowie Teams- und SharePoint-Erlebnis messen

Nach dem Start drei Ebenen getrennt messen

Ein Betriebsdashboard sollte Provisioning-Status, Microsoft-365-Nutzbarkeit und Sicherheitsergebnis trennen. Beobachten Sie Scope-Größe, Erfolgs- und Fehlerzahlen je Zyklus, Alter der letzten Änderung, Duplikate, unerwartete Reaktivierungen und Soft-Deletes. Aus Nutzersicht werden Anmeldung, Personensuche, Teams-Zugriff und SharePoint geprüft. Sicherheitstests müssen die tatsächliche Berechtigung und Conditional Access im Ziel belegen. Ein grüner Provisioning Job beweist weder ein sicheres Design noch korrektes Mailrouting.

Wann das Werkzeug nicht passt

Für Lieferanten oder Partner außerhalb einer Unternehmensgruppe verweist Microsoft eher auf Entitlement Management und klassische B2B-Governance; organisationsübergreifende Synchronisierung kann zusätzliche Datenschutz-, Rechts- und Einwilligungspflichten erzeugen. Ungeeignet ist sie auch als Abkürzung um einen Migrationsplan oder als Versuch, Geräte einer Tochter ohne Intune-Konzept zentral zu verwalten. Der größte Nutzen entsteht, wenn Mandantenbesitz, Identitätsheimat und Offboarding-Verantwortung eindeutig sind.