Folgendes Problem aus der Praxis: Ein Unternehmen betreibt zwei separate Microsoft-365-Mandanten: Einen für die Holding, einen für eine Tochtergesellschaft. Die Mitarbeitenden sollen Teams-Chats führen, gemeinsame SharePoint-Sites nutzen und auf bestimmte Azure-Ressourcen zugreifen. Drei Kolleginnen aus dem IT-Team schlagen drei verschiedene Lösungen vor: Cross-Tenant Sync, B2B-Gastkonten und Verbundene Organisationen. Alle drei haben recht und alle drei liegen gleichzeitig falsch, sofern der Anwendungsfall nicht sauber definiert ist.
In meinen Azure-Kursen ist genau diese Frage einer der häufigsten Diskussionspunkte, sobald wir das Kapitel Microsoft Entra ID Governance erreichen. Dieser Artikel bringt Struktur in die Entscheidung.
Die drei Konzepte im Überblick
Microsoft Entra ID (ehemals Azure Active Directory) kennt grundsätzlich zwei Arten von Benutzerkonten: Member-Konten (interne Mitglieder) und Guest-Konten (Gäste, technisch erkennbar am userType = Guest). Mandantenübergreifende Szenarien drehen sich fast immer darum, wie Identitäten aus Mandant A in Mandant B sichtbar und nutzbar gemacht werden. Die drei relevanten Mechanismen sind:
- Cross-Tenant Synchronization (mandantenübergreifende Synchronisierung): Benutzer werden automatisiert aus einem Quellmandanten in einen Zielmandanten als Gastkonten provisioniert und aktuell gehalten. Sie erscheinen dort als reguläre Member-Konten.
- B2B-Gasteinladung (Business-to-Business): Externe Benutzer werden manuell oder per Self-Service eingeladen und erhalten ein Gastkonto im einladenden Mandanten.
- Verbundene Organisation (Connected Organization): Ein Konzept aus der „Entra ID Entitlement Management“-Welt, das externen Mandanten den „gesteuerten Zugriff“ auf „Zugriffspakete“ (Access Packages) ermöglicht.
Vergleich: Was kann was – und was kostet was?
Bevor die Entscheidung fällt, lohnt ein direkter Vergleich der drei Ansätze entlang der Kriterien, die in der Praxis wirklich zählen:
| Kriterium | Cross-Tenant Sync | B2B-Gast (manuell / selbst) | Verbundene Organisation |
|---|---|---|---|
| Provisionierung | Automatisch via SCIM-ähnlichem Mechanismus | Manuell oder per Self-Service-Portal | Gesteuert durch Access Packages |
| Kontotyp im Zielmandanten | Guest (Member möglich, aber selten) | Guest | Guest (nach Zuweisung eines Access Package) |
| Lizenzanforderung | Microsoft Entra ID P1 im Quellmandanten | Keine Zusatzlizenz für einfache B2B-Einladung | Entra ID P2 (für Entitlement Management) |
| Geeignet für | Konzernstrukturen, M&A-Szenarien, dauerhafte interne Zusammenarbeit | Projektweise Zusammenarbeit mit externen Partnern | Gesteuerter Zugriff auf definierte Ressourcenpakete |
| Lebenszyklus-Management | Automatisch: Deaktivierung/Löschung folgt dem Quellkonto | Manuell, per Access Review oder Ablaufdatum | Über Access-Package-Richtlinien (Ablauf, Genehmigung) |
| Teams-Präsenz / GAL-Eintrag | Ja, vollständig | Eingeschränkt (kein nativer GAL-Eintrag) | Nein (nur Ressourcenzugriff) |
| Verwaltungsaufwand | Einmalig hoch (Konfiguration), dann niedrig | Laufend (Einladungen, Reviews) | Mittel (Pakete pflegen, Genehmiger verwalten) |
Merksatz: Cross-Tenant Sync löst das Wer-Problem (Identitäten automatisch bereitstellen), Verbundene Organisationen lösen das Was-Problem (welche Ressourcen darf wer anfordern), B2B-Gasteinladung löst das Schnell-Problem (jetzt sofort, kein Overhead).
Wann welcher Mechanismus ?
In meinen Azure-Kursen arbeite ich gern mit einem einfachen Entscheidungsbaum, den ich hier in Textform wiedergebe:
Szenario 1 – Konzern mit mehreren Mandanten: Sie haben zwei oder mehr Entra-ID-Mandanten, die dauerhaft koexistieren (Holding + Töchter, regionale Einheiten nach M&A). Die Mitarbeitenden sollen sich gegenseitig im Teams-Verzeichnis finden, Meetings planen und gemeinsam an Dokumenten arbeiten. Richtige Wahl: Cross-Tenant Sync. Die Benutzer werden einmalig konfiguriert und tauchen automatisch im Global Address List (GAL) des Zielmandanten auf. Jede Änderung im Quellmandanten – Namensänderung, Deaktivierung, Löschung – wird automatisch übernommen. Der Aufwand fällt einmalig bei der Einrichtung an; danach läuft der Mechanismus wartungsarm.
Szenario 2 – Projektbezogene externe Zusammenarbeit: Ein Projektteam arbeitet für sechs Monate mit einer externen Agentur zusammen. Drei Personen aus der Agentur sollen auf einen SharePoint und ein Teams-Team zugreifen. Richtige Wahl: B2B-Gasteinladung. Die Einladung ist in Minuten erledigt, erfordert keine Lizenz-Upgrades und kann mit einem Ablaufdatum oder regelmäßigen Access Reviews (Entra ID P2) kontrolliert werden. Cross-Tenant Sync wäre hier überdimensioniert.
Szenario 3 – Gesteuerter Self-Service-Zugriff für Partner: Ein mittelständisches Unternehmen arbeitet regelmäßig mit drei Lieferanten zusammen. Die Lieferanten sollen eigenständig Zugriff auf ein Lieferantenportal (SharePoint, Power Apps) beantragen können – mit Genehmigungsworkflow, zeitlicher Begrenzung und automatischem Offboarding. Richtige Wahl: Verbundene Organisation + Entitlement Management. Die Lieferanten-Mandanten werden als Verbundene Organisationen hinterlegt. Die Mitarbeitenden der Lieferanten können ein Access Package selbst anfordern; ein interner Genehmiger bestätigt. Nach Ablauf des Paketes endet der Zugriff automatisch.
Praxistipp: Die drei Mechanismen schließen sich nicht aus. In einem Konzern kann Cross-Tenant Sync die internen Tochtergesellschaften abbilden, während B2B-Gasteinladungen für externe Projektpartner und Verbundene Organisationen für den strukturierten Lieferantenzugang genutzt werden. Der Fehler liegt meistens darin, einen einzelnen Mechanismus für alle Szenarien erzwingen zu wollen.
Praxisempfehlung: Strukturiertes Vorgehen für KMU und Konzerne
- Schritt 1 – Szenarien inventarisieren: Welche Benutzergruppen sollen mandantenübergreifend zusammenarbeiten? Intern (eigene Mandanten) oder extern (fremde Unternehmen)?
- Schritt 2 – Dauerhaftigkeit prüfen: Handelt es sich um eine dauerhafte Beziehung (→ Cross-Tenant Sync), ein zeitlich begrenztes Projekt (→ B2B-Gast) oder einen bedarfsgesteuerten Zugriff (→ Verbundene Organisation)?
- Schritt 3 – Lizenzsituation klären: Entra ID Free reicht für einfache B2B-Einladungen. P1 ist Voraussetzung für Cross-Tenant Sync. P2 ist notwendig für Entitlement Management und Access Reviews.
- Schritt 4 – Cross-Tenant Access Settings konfigurieren: Unabhängig vom gewählten Mechanismus steuern die Inbound/Outbound-Einstellungen unter External Identities → Cross-tenant access settings, welche Authentifizierungsansprüche (Claims) und MFA-Methoden aus dem Fremdmandanten vertraut werden.
- Schritt 5 – Lebenszyklus von Beginn an mitdenken: Gastkonten ohne Offboarding-Prozess sind ein klassisches Sicherheitsrisiko. Access Reviews oder automatische Deaktivierung durch Cross-Tenant Sync gehören in jedes Konzept.
Wenn Sie diese Themen vertiefen möchten – von der technischen Konfiguration der Cross-Tenant Access Settings bis hin zur Governance mit Entitlement Management – finden Sie die passenden Inhalte in meinen Azure-Kursen. Mandantenübergreifende Szenarien sind dort ein fester Bestandteil der Identity-und-Governance-Module, weil genau diese Fragen in der Praxis täglich auftauchen – und die Antwort immer vom konkreten Anwendungsfall abhängt.