In meinen Azure-Kursen taucht dieses Thema verlässlich in der zweiten Kurshälfte auf – und dann meist mit einem konkreten Schmerzpunkt im Gepäck: Ein Unternehmen hat eine Tochtergesellschaft in einem eigenen Entra-Mandanten, Mitarbeitende sollen auf beide Umgebungen zugreifen, und niemand weiß mehr genau, welches der drei Konzepte – Cross-Tenant Synchronization, B2B-Gastkonten oder Verbundene Organisationen (Connected Organizations) – eigentlich das richtige ist. Die Kurzantwort: Es kommt darauf an. Die lange Antwort steht in diesem Artikel.
Das Grundproblem: Mehrere Mandanten, eine Belegschaft
Microsoft Entra ID (der frühere Azure Active Directory-Dienst) ist mandantenbasiert – jedes Unternehmen bekommt seinen eigenen Tenant (Mandanten). Sobald Organisationen fusionieren, Tochtergesellschaften gründen oder mit Partnern dauerhaft zusammenarbeiten, entsteht das klassische Multi-Tenant-Problem: Identitäten aus Mandant A sollen auf Ressourcen in Mandant B zugreifen können, möglichst ohne manuelle Pflege doppelter Konten.
Genau dafür hat Microsoft über die Jahre drei verschiedene Mechanismen entwickelt. Sie überschneiden sich in Teilen, lösen aber unterschiedliche Szenarien. Wer den falschen Mechanismus wählt, kämpft anschließend mit Governance-Problemen, Lizenzfragen oder schlicht damit, dass bestimmte Features gar nicht wie erwartet funktionieren.
Das Entra Admin Center fasst die externen Identitätskonzepte unter „External Identities“ zusammen – aber die Unterschiede erschließen sich erst auf den zweiten Blick.
Die drei Konzepte im Überblick
Cross-Tenant Synchronization (mandantenübergreifende Synchronisation) ist das jüngste der drei Konzepte und seit 2023 allgemein verfügbar. Es funktioniert ähnlich wie die klassische HR-getriebene Synchronisation über Entra Connect: Ein Administrator richtet im Quellmandanten eine Konfiguration ein, die ausgewählte Benutzer automatisch als B2B-Member-Objekte (also nicht als Gäste, sondern als Mitglieder) in den Zielmandanten provisioniert. Die Objekte werden laufend aktuell gehalten – inklusive Attributen wie Abteilung, Jobtitel oder Profilbild.
B2B-Gastkonten (B2B Collaboration) sind der klassische Ansatz: Ein Benutzer aus einem externen Mandanten erhält eine Einladung, nimmt sie an und erscheint anschließend im eigenen Verzeichnis als Gastobjekt mit dem UserType „Guest“. Dieser Prozess ist oft manuell oder halbautomatisch (über Self-Service-Portale), und Gastkonten unterliegen standardmäßig eingeschränkten Verzeichnisberechtigungen.
Verbundene Organisationen (Connected Organizations) sind ein Governance-Konzept innerhalb von Entra ID Governance, genauer gesagt innerhalb des Entitlement Management (Berechtigungsverwaltung). Hier definiert ein Administrator, welche externen Organisationen vertrauenswürdig sind, und ermöglicht es deren Mitarbeitenden, Zugriffspakete (Access Packages) selbst anzufordern. Die Kontoobjekte entstehen erst bei Bedarf – also dann, wenn ein externer Benutzer tatsächlich Zugriff beantragt.
Vergleich: Was leistet was?
| Kriterium | Cross-Tenant Sync | B2B-Gastkonto | Verbundene Organisation |
|---|---|---|---|
| Provisionierung | Automatisch, push-basiert | Manuell oder per Einladung | On-Demand bei Antragstellung |
| UserType im Zielmandanten | Member (kein Gast) | Guest | Guest (nach Einlösung) |
| Attributsynchronisation | Ja, laufend | Nein (statisch nach Einladung) | Nein |
| Lizenzanforderung | Entra ID P1 (beide Mandanten) | Entra ID Free reicht für Basis | Entra ID Governance (P2 oder Add-on) |
| Typisches Szenario | Tochtergesellschaft, Fusion, enge Zusammenarbeit | Projektpartner, externe Dienstleister | Partnerorganisationen mit Self-Service-Zugriff |
| Governance-Integration | Eingeschränkt (kein Access Package nötig) | Möglich, aber manuell | Vollständig (Access Packages, Reviews) |
| Sichtbarkeit im GAL (Global Address List) | Ja, da Member-Objekt | Eingeschränkt (Gast-Sichtbarkeit) | Eingeschränkt |
Die Cross-Tenant-Synchronisation wird im Quellmandanten unter „Cross-tenant synchronization“ konfiguriert – ähnlich einer SCIM-Provisionierung.
Merksatz: Cross-Tenant Sync ist kein Ersatz für B2B-Gastkonten, sondern eine Automatisierung davon – allerdings mit dem wichtigen Unterschied, dass die resultierenden Objekte als Member und nicht als Guest angelegt werden. Das hat Konsequenzen für Conditional Access (Richtlinien für bedingten Zugriff), SharePoint-Berechtigungen und Teams-Features.
Wann welches Konzept – ein Entscheidungsrahmen
Folgendes Problem aus der Praxis: Ein mittelständisches Unternehmen mit 300 Mitarbeitenden kauft eine kleinere Firma mit 80 Personen. Beide betreiben eigene Microsoft-365-Mandanten. Die Frage: Wie integriert man die 80 Personen so, dass sie auf Teams-Kanäle, SharePoint-Sites und interne Apps des Mutterkonzerns zugreifen können?
Hier ist Cross-Tenant Sync die richtige Wahl: Die Benutzer werden automatisch in den Mandanten des Mutterkonzerns synchronisiert, erscheinen dort im Adressbuch, können in Teams-Kanäle aufgenommen werden wie reguläre Mitarbeitende – und wenn jemand die Tochtergesellschaft verlässt, wird das Objekt im Zielmandanten automatisch deaktiviert oder gelöscht.
Ein anderes Szenario: Ein Beratungsunternehmen arbeitet mit zwanzig verschiedenen Kunden zusammen, die alle ihren eigenen Mandanten haben. Projektmitarbeitende der Kunden sollen temporären Zugriff auf ein SharePoint-Projektportal erhalten. Hier sind klassische B2B-Gastkonten sinnvoller – überschaubar, günstig, und der Aufwand für eine vollständige Synchronisation wäre unverhältnismäßig.
Verbundene Organisationen hingegen eignen sich, wenn externe Partner selbstständig Zugriff auf definierte Ressourcen beantragen sollen – etwa auf eine interne Akademieplattform oder ein Compliance-Portal. Der Zugriff wird über Access Packages gesteuert, regelmäßige Access Reviews (Zugriffsüberprüfungen) sorgen für saubere Governance, und der administrative Aufwand im eigenen Mandanten bleibt gering. Voraussetzung ist allerdings eine Entra ID Governance-Lizenz.
In meinen Azure-Kursen arbeiten wir diese Szenarien anhand konkreter Lab-Umgebungen durch – inklusive der Fallstricke, die in der Microsoft-Dokumentation gerne unter „Considerations“ versteckt werden.
Praxisempfehlung für KMU-Umgebungen
Noch mal in Kürze: Kurz, knapp und strukturiert – zum Abhaken.
Praxistipp: Beginnen Sie mit der Frage, wie dauerhaft und eng die Zusammenarbeit ist. Eine einfache Entscheidungsmatrix:
| Situation | Empfehlung |
|---|---|
| Tochtergesellschaft oder Fusion, enge tägliche Zusammenarbeit | Cross-Tenant Synchronization |
| Externe Projektpartner, zeitlich begrenzt | B2B-Gastkonten (manuell oder per Bulk-Einladung) |
| Mehrere Partnerorganisationen, Self-Service gewünscht, Governance wichtig | Verbundene Organisationen + Entitlement Management |
| Kombination: Tochter + externe Partner | Cross-Tenant Sync für Tochter, B2B-Gast für Partner |
Klären Sie vor der Implementierung in jedem Fall zwei Dinge: erstens die Lizenzlage beider Mandanten (Cross-Tenant Sync setzt Entra P1 auf beiden Seiten voraus), und zweitens die Conditional-Access-Richtlinien des Zielmandanten – denn ein Member-Objekt aus Cross-Tenant Sync kann andere Richtlinien auslösen als ein Guest-Objekt. Ich hatte mich in diesem Zusammenhang selbst einmal gewundert, warum MFA-Anforderungen für synchronisierte Benutzer anders griffen als erwartet – die Ursache lag in einer CA-Richtlinie, die explizit nach UserType „Guest“ gefiltert hatte und Member-Objekte schlicht ignorierte.
Wer tiefer einsteigen möchte: Die Themen Entitlement Management, Cross-Tenant Sync und B2B Collaboration sind fester Bestandteil meiner Azure-Kurse rund um Entra ID und Identity Governance – mit Hands-on-Labs in echten Testmandanten.