Cross-tenant sync

Nicht immer sind alle Personen einer Firma der Firmengruppe in genau einem Tenant. Die Gründe für mehrere Tenants sind vielfältig aber fast immer wird ein Zusammenarbeit gefordert, die z.B. über Exchange Free/Busy-Bereitstellung, Teams Federation und Teams Shared Channel oder gleich mit Gastkonten über vielerlei Optionen möglich ist. Seit Frühjahr 2023 ist die Funktion "Cross-tenant sync" offiziell verfügbar, mit der Benutzer-Identitäten aus einem Tenant in einen anderen Tenant repliziert werden können.

Weitere Seiten

Weitere Details zu dieser Funktion finden Sie auf den folgenden Seiten:

Einsatzzweck

Wenn mehrere Tenants miteinander zusammen arbeiten wollen, dann geht dies z.B. über B2BConnect und Teams Shared Channels oder der klassische Zugriff per "Gast" im anderen Tenant (B2B Collaboration) Im beiden Fällen muss der Tenant mit den Daten entsprechende Informationen aus dem Tenant mit den Anmeldekonten haben. Ohne Automatismus lädt jemand aus dem Daten-Tenant den externen Benutzer ein, der nach Zustimmung dann Zugang erhält. Mit fremden Tenants und einzelnen Personen ist dieser Weg geeignet und kann durch Administratoren beider Tenants auch gut kontrolliert werden.

Bislang gab es aber noch keine Bordmittel um die Zusammenarbeit zweiter Tenants zu optimieren, die z.B.: zur gleichen Firmengruppe gehören und eigentlich jeder Benutzer auch im anderen Tenant als Identitäten zur Verfügung stellen sollte, z.B. für:

  • Exchange: Adressbuch
    Wäre doch nett, wenn ich aus meinem Tenant auch die Benutzer des anderen Tenants im Adressbuch hätte
  • Teams: Adressbuch
    Auch bei der Suche nach Teams-Kontakten ist ein Adressbuch hilfreich.
  • Teams: Gast-Zugriff
    Wäre es nicht gut, wenn ein Teams Besitzer die Personen des anderen Tenants direkt als Mitglieder/Gäste addieren kann ohne eine Einladung auszulösen?
  • Teams: Shared Channel
    Das gilt erst recht für die Zusammenarbeit mit Shared Channels

Für all diese Problemstellungen kann "Cross-Tenant sync" die Lösung sein, da Microsoft 365 damit Benutzer eines Tenants mit umfangreichen Filtern und Attribut-Transformationen  als Gast oder externe Identität in einen anderen Tenant exportieren kann.

Stichpunkte

Microsoft hat auf mehreren Seiten ausführlich die Funktion und Konfiguration beschrieben und bebildert. Ich beschränke mich hier auf Stichpunkte.

  • "Cross-tenant sync" ist eine Funktion von AzureAD, mit der ein Quell-Tenants seine Benutzer in einen anderen Tenant als externe Identitäten synchronisieren kann, so dass der Ziel-Tenant diese Identitäten zur Vergabe von Berechtigungen, Die Anzeige im Exchange/Outlook-Adressbuch oder in Teams verwenden kann
  • Lizenzen: AzureAD P1 oder P2 für Quell- und Ziel-Tenant
    Sie können "Cross-tenant sync" nur einrichten, wenn beide Tenants die entsprechende Lizenz haben. Jeder aus der Quelle synchronisierte Benutzer muss eine AzureAD P1-Lizenz haben. Im Ziel reicht es, mindestens eine AzureAD P1-Lizenz zur Konfiguration zu haben. Allerdings benötigen Gäste ja auch entsprechende Lizenzen im Tenant (1:5 Ratio oder Monthly Active Users)
    Quelle: https://learn.microsoft.com/en-us/azure/active-directory/multi-tenant-organizations/cross-tenant-synchronization-overview#license-requirements
  • Quellobjekte sind nur Azure-AD "Benutzer"
    Die Benutzer können "CloudOnly" oder durch "ADSync" angelegt worden sein. "Cross-tenant sync" ignoriert Gast-Benutzer, Kontakte, Gruppen, Verteiler, Office Groups, Rollen, Teams etc. Weitere Ausnahmen existieren, z.B. wenn der Quellbenutzer sich per SMS anmeldet, dann wird er ausgespart, denn die Mobilfunknummern wird nicht synchronisiert.
  • Quell-Admin entscheidet, Zieltenant kann nur zustimmen
    Die komplette Konfiguration liegt im Quell-Tenant. Der Administrator bestimmt Umfang und Funktion. Der Administrator im Ziel muss allerdings "zulassen", welcher Quell-Tenant Objekte in seinen eigenen Tenant repliziert. Der Admin des Ziel-Tenant gibt quasi die Verwaltung über die externen Identitäten des anderen Tenants in seinem AzureAD ab.
  • N:1 und 1:N und N:M ist möglich aber keine transitive Replikation
    Sie können die Benutzer eines Tenant-A in mehrere andere Tenants anlegen lassen und auch aus mehreren anderen Tenants die Identitäten empfangen. Da "Cross-tenant sync" aber nur die Benutzer einbezieht, gibt es ja auch keine Probleme mit doppelten UPNs o.ä. Es kann aber Konflikte mit bestehenden Kontakten und Gästen geben. Es ist aber auch nicht möglich, dass sie Benutzer aus Tenant-A über Tenant-B nach Tenant-C replizieren.
  • Nicht für "Cross Org"-Verbindungen
    Der Name "Cross-tenant sync" ist kein "Cross Org Sync". Microsoft platziert diese Funktion nicht zum Abgleich von Identitäten zwischen getrennten Firmen sondern fokussiert hier Firmen mit mehreren Tenants unter einem Dach.
  • Add/Update/Delete
    "Cross-tenant sync" kann im Ziel die Objekte neu anlegen, aktualisieren und auch löschen. Damit verschwindet auch ein Benutzer im Ziel, wenn dieser in der Quelle entfernt wurde.
  • Zielobjekte ist "External Member" ohne "Einladung"
    Der Anwender bekommt aufgrund der "Auto-Remediation" keine Einladung und muss nicht zustimmen. Beachten sie , dass z.B. Microsoft Teams Shared Channels aktuell nur Gast-Benutzer versteht. Das könnte sich zukünftig auch ändern. Bis dahin sollten Sie die Anlage als "External Guest" konfigurieren.
  • Sync-Intervall: 40 Minuten
    Änderungen in der Quelle werden alle 40 Minuten abgeglichen. Diese Zeit ist aktuell nicht änderbar. Wurde ein grundlegendes Problem gefunden, erhöht sich das Interfall auf 2h40min
    Quelle: https://learn.microsoft.com/en-us/azure/active-directory/multi-tenant-organizations/cross-tenant-synchronization-overview#synchronization-frequency
  • Sync-Details
    Es gibt noch einige Hinweise in der FAQ-Section, z.B.
    - Autoritative Quelle ist die Quelle, d.h. es gibt keine Rückreplikation bei Änderungen im Ziel
    - Es werden Änderungen an der Quelle entdeckt und ins Ziel geschrieben.
    - Das Ziel ist aber nicht gegen Änderungen durch den lokalen Admin gesichert und sie werden nicht zurück gesetzt.
    - Wird aber lokal das Feld geändert, dann wird das Ziel überschrieben. Das gilt auch, wenn das Konto im Ziel z.B.: deaktiviert und danach in der Quelle reaktiviert wurde.
  • Ziel kann die Quelle nicht erkennen
    Der Administrator im Ziel hat abgesehen von seinem AuditLogs keine einfacher Filterung, welche externe Konten durch den "Cross Tenant dirsync" angelegt wurde. Es sind einfach reguläre Konten, wie sie auch ein lokaler Admin anlegen könnte. Sie können nur nach dem UPN und einer Domain des Quell-Tenants filtern.

    Ich würde empfehlen, ein Feld entsprechend zu füllen.

Viele weitere Fragen wurden auch von Microsoft beantwortet.

Synchronisierte Objekte

Wenn Sie sich ihr AzureAD anschauen, dann gibt es da ja eine ganze Menge von möglichen Identitäten, die ein "Cross-tenant sync" replizieren könnte. Allerdings werden nicht alle Identitäten übertragen. Für die Filterung ist der Benutzertyp und der Identity-Provider maßgeblich.

Weitere Details finden Sie weiter unten in der Tabelle der Testfälle

Usertyp Identities Beschreibung Im Sync

Member

<tenantname>.onmicrosoft.com

Reguläre Benutzer des Tenants, d.h. Anwender, Administratoren, Dienstkonten als "CloudOnly" oder ADSync-Konten

Ja

Gast

<tenantname>.onmicrosoft.com

Eher selten genutzte Konten, die Gast-Status haben aber sich dennoch am Tenant nativ anmelden

 

Gast

ExternalAzureAD

Die klassischen "Gäste" aus anderen Tenants mit Zugriff auf den lokalen Tenant aber Authentifizierung über das AzureAD des anderen Tenant. Diese Objekte werden anhand des folgenden Filters blockiert:

{"Filter external users.alternativeSecurityIds EQUALS 'None'":false}

Nein

Member

ExternalAzureAD

Selten genutzte Konten, die den Status "Member" haben aber sich an einem anderen AzureAD authentifizieren

 

Gast

MicrosoftAccount (LivrID)

"Microsoft Konten", früher LiveID oder Passport, die als Gäste zugreifen aber sich am Microsoft Privatkunden-Dienst authentifizieren

 

Gast

Mail

Gastkonten, die ein Einmalkennwort z.B. per Mail zur Anmeldung erhalten

 

Group

<tenantname>.onmicrosoft.com

Gruppen werden aktuell gar nicht repliziert. Damit entfällt auch die Verwaltung der Mitgliedschaft

Group '<guid>' will be skipped. EntityTypeNotSupported

Nein

Device

<tenantname>.onmicrosoft.com

Geräte werden nicht synchronisiert. Ich wüsste auch nicht, zu welchem Zweck

Nein

Contacts

<tenantname>.onmicrosoft.com

Kontakte werden in Exchange genutzt, um Empfänger in anderen Exchange Organisationen im Adressbuch sichtbar zu machen. Wenn das Ziel diese Kontakte möchte, sollte es die originale Quelle fragen

Nein

Einige Einschränkungen lassen sich schon daran erkennen, dass im Provisioning Log der Grund für einen "Skip" beschrieben wird.

{"Filter external users.alternativeSecurityIds EQUALS 'None'":true,"Filter external users.userState NOT EQUALS 'PendingAcceptance'":false}

Auch in den Details gibt es pauschale Hinweise:

Sichtbarkeit in Apps

Die Anlage der Objekte ist ja kein Selbstzweck. Natürlich habe ich mich als Anwender im Zieltenant authentifiziert und wollte sehen, welchen Vorteil die Anwender haben.

  • Exchange/Outlook
    In Outlook Web App kann ich direkt nach den Benutzern suchen
  • Teams
    Auch in Microsoft Teams finde ich den User in der Search-Leiste und kann die vorhandenen Gäste auch in Kanäle addieren.

Viel weitere Applikationen gibt es leider noch nicht, die mit externen Identitäten ohne Gastzugang richtig umgehen können. Da durch "Cross-tenant sync" nur Benutzer synchronisiert werden, kommen natürlich keine Office Groups oder Exchange Verteiler im anderen Tenant an.

Achtung ADSync

Wenn Sie als Firma genau einen AD-Forest haben, und von diesem mit eigenen ADSync-Installationen zwei oder mehr Tenants befüllen, dann sollten Sie mögliche Konflikte vermeiden und nur die Benutzer in einen Tenant replizieren, die auch dort benötigt werden und den Rest durch Cross-Tenant Sync abgleichen. Ich habe schon Umgebungen gefunden, in denen ADSync zu viele Objekte repliziert hat und in einem Tenant die Benutzer eines anderen Tenants nicht als Gäste, sondern als normale AzureAD-Konten angelegt wurden. Da der andere Tenant aber nicht die Domain in Besitz hatte, bekamen die Anwender eine "<tenant>.onmicrosoft.com"-Adresse als UPN aber waren natürlich in Exchange ebenfalls sichtbar.

Eine solche Konfiguration ist nicht supportet, da dabei mehrere ADSync-Installationen das gleiche lokale AD-Konto lesen und schreiben.

Einschätzung

"Cross-tenant sync" ist der bislang fehlende Baustein für eine B2B-Zusammenarbeit zwischen "verbundenen" Tenants. Es ist schnell und einfach konfiguriert, funktioniert im Grund problemlos und mit der passenden B2B Direct Connect-Einstellungen ermöglichen Sie damit eine optimierte Zusammenarbeit der Benutzer unterschiedlicher Tenants, z.B.: als Office 365 Gast-Konten / Azure B2B im anderen Tenant oder mit Teams Shared Channel.

Allerdings ist die Lösung nicht ganz fehlerfrei, denn wenn zwei Administratoren in ihrem Tenant Identitäten verwalten und sich nicht abstimmen, kann es schon passieren, das Objekte fehlen oder falsch provisioniert wurden. Der Administrator des Quell-Tenants tut gut daran, seinen Verzeichnisabgleich zu überwachen und Fehler zu beseitigen, während der Administrator im Ziel immer daran denken sollte, dass einige Benutzer nicht durch ADSync oder andere Prozesse angelegt wurden, sondern über "Cross-tenant sync" verwaltet werden.

Es ist technisch problemlos möglich, auch komplett fremde Tenants mit den eigenen Benutzern zu befüllen. Allerdings dürfte das eher selten der Fall sein, denn würden sie als Administrator des Zieltenants einem anderen Tenant das Recht geben, Gäste u.a. in ihrem Tenant unbeschränkt anlegen, verwalten und löschen zu können?. Für Firmengruppen oder verbundene Unternehmen ist diese Funktion aber sehr interessant und kann das Provisioning von Gast-Benutzern und externen Identitäten deutlich vereinfachen.

Weitere Links

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