Tenant Domain Sharing

Jeder Office 365 Tenant hat eine eigene eindeutige "<tenantname>.onmicrosoft.com"-Domain, die aber in der Regel nicht durch Anwender genutzt wird. Zusätzliche Domänen der Firma können registriert und genutzt werden. Diese Seite beschäftigt sich mit der Herausforderung, die gleiche DNS-Domain in mehreren Tenants zu nutzen.

Microsoft hat im Herbst 2022 eine "Preview" für eine Exchange/OneDrive Migration von Tenant zu Tenant bereitgestellt, die auch ein SMTP-Domainsharing erlaubt. Die Seite ist noch nicht damit aktualisiert.

Eine DNS-Domain kann es immer nur einmal in der Welt geben und kann, Stand Jun 2021, immer nur genau einem Tenant zu gewiesen werden. Aber es gibt je nach Produkt erweiterte Möglichkeiten.

Ich habe die Seite unter Exchange Online einsortiert, weil hier die meisten Anknüpfungspunkte zu sehen sind.

UPN

Wenn sich ihre Anwender nicht mit der schon genannten "<tenantname>.onmicrosoft.com"-Adresse anmelden wollen, dann sollten Sie eine Firmendomäne im Tenant registrieren. Rein technisch könnte Microsoft sicherlich eine Anmeldung mit dem gleichen UPN auch an mehreren Tenants möglich machen aber aktuell ist hier keine Besserung in Sicht. Es würde auf jeden Fall auch die ein oder andere Einschränkungen geben. Denken Sie nur an die Anmeldung per ADFS, bei der Microsoft eine Domain zu einem ADFS-Server der Firma leitet. Auch wenn die Anwender in mehreren Tenants wären, müssten Sie zumindest den gleichen ADFS-Service nutzen.

Theoretisch könnten Benutzer in einem Tenant sich ja am anderen Tenant anmelden und dann als Gast in ihrem Heimtenant arbeiten. Diese Nutzung ist aber stark limitiert, denn ein Gast kann in einem anderen Tenant kein eigenes Postfach, eigenes OneDrive haben. Er müsste dann im anderen Tenant eine Lizenz bekommen und dort seine Daten speichern. Das ist maximal für eine kurze Übergangszeit einer Migration denkbar.

Aktuell kenne ich keine Lösung, um dieses Problem zu lösen. Hier gilt: Eine DNS-Domain kann nur auf einem Tenant aktiv genutzt werden.

Skype for Business/Teams

Der UPN eines Benutzers ist in der Regel auf die SIP-Adresse in Skype for Business Online und Teams. In Verbindung mit ADSync und Skype Hybrid Mode ist es möglich, dass ein Benutzer eine andere Domain bei der SIP-Adresse nutzt, als er als UPN verwendet. Allerdings verhindert Skype for Business Online, dass man eine abweichende SIP-Domain verwendet, die nicht im Tenant registriert ist. Mit dem Ende von Skype for Business online zum 31.7.2021 ist dieser Fall auch nicht mehr relevant.

Bei Teams ist es der UPN oder eine Mailadresse, anhand ein Kommunikationspartner bei der Federation gefunden werden kann. Die SIP-Adresse ist hier nur noch im Interop-Betrieb/Hybrid relevant. Die URL für Besprechungen (Meetings) enthält ebenfalls nicht mehr die Domain, sondern bei Skype for BusinessOnline den Userpart und bei Teams sowieso nur noch die GUID des Tenant und des Organisators.

Eine Nutzung der gleichen SIP-Domain in mehreren Tenants ist nach meinem Wissen nicht möglich!

SharePoint/OneDrive

Die native DNS-Domain ist in OneDrive und SharePoint nicht in URLs sichtbar. Hier kommt immer der Tenantname zum Einsatz, z.B.

msxfaq.sharepoint.com
msxfaq-my.sharepoint.com

Der nachfolgende URL-Teil enthält maximal den Userpart und keine weitere Domain und ist daher nicht weiter von Belang.

Exchange

Mit Exchange wird es aber nun interessant. Anders als beim UPN oder SIP-Adresse kann ein Postfach durchaus mehrere Adressen haben. Natürlich kann auch hier eine Domain aktuell nur in genau einem Tenant registriert werden aber mit zusätzlichen Systemen zum "Rewriting" und einem Abgleich der Adressbücher mit Weiterleitungen über eine "TargetAddress" können mehrere Tenants durchaus nach extern den gleichen SMTP-Adressraum nutzen.

Update: Ende 2022 hat Microsoft eine Funktion im Rahmen der Cross Tenant Migration bereitgestellt, dass eine SMTP-Domain von mehreren Tenants als Versendedomain verwendet werden kann. Der Empfang landet aber immer im primören Tenant, wo sie dann mit Kontakten diese an die anderen Tenants weiterleiten müssen

Sie können über verschiedene Wege das Mailrouting und die Autodiscover-Funktion bereitstellen und genau genommen reicht es, wenn der Tenant mit der SMTP-Domain alle Empfänger in allen Tenants kennt und sowohl die Mails weiterleitet als auch die Autodiscover-Anfragen umleitet. Ich würde dennoch dafür sorgen, das fr einen sauberen Verbund alle Tenants die gleiche vollständige GAL haben. Das ist insbesondere dann wichtig, wenn Sie das Bild für mehrere SMTP-Domänen bauen und verschiedene Tenants primär sind oder Sie eine Migration planen und irgendwann das Mailrouting umstellen.

Die Eckpunkte sind:

  • Ein primärer Tenant hat die SMTP-Domain
    Das ist noch einfach zu verstehen, denn es geht nicht anders
  • Jeder Tenant hat eine eindeutige SMTP-Domain
    Die bezeichne ich im weiteren als Routingdomäne.
  • Ein Benutzer hat genau ein primäres Postfach
    Das kann später bei einer Migration aufgeweicht werden.
  • Umleitung per TargetAddress
    Über die Zieladresse eines MailUser oder MailContact kann Exchange Mails an andere Mailsysteme, hier dann den anderen Tenant weitergeben. Zudem wird eine Autodiscover-Anfrage eines Clients ebenfalls umgeleitet (Siehe TargetAddress und Autodiscover Redirect)

Ich beschreibe hier nur die Kopplung von zwei Tenants ohne HybridMode mit weiteren lokalen Exchange Servern. Das ist ja auch ein SMTP-Sharing aber würde das Bild komplexer machen.

  • Eingehend Mailrouting über Connectoren
    Ein Mailrelay in der Mitte (oder einer der Tenants) nimmt die Mails für die Domain an und schreibt den Empfänger entsprechend auf die Tenant-spezifische Maildomain um. Zwischen den Tenants muss zumindest in die eine Richtung nicht die native Domain sondern eine Routingdomäne genutzt werden. Hier helfen natürlich "Kontakte", damit auch Mails an die andere Seite bei Nutzung der gemeinsamen SMTP-Domäne umgeroutet werden. Beachten Sie hier aber ggfls. Weiterleitungsgrenzwerte zwischen Tenants. Exchange Online hat einen "Loopschutz", der bei zu vielen Weiterleitungen den Tenant blockieren könnte.
  • FreeBusy
    Über Org Connectoren lassen sich auch Partnerschaften für Terminplanungen einrichten. Dann natürlich über die spezielle "onmicrosoft"-Adresse.
  • Autodiscover über TargetAddress
    Der primäre Tenant kennt alle Empfänger und Autodiscover "versteht" durchaus die Bedeutung der TargetAddress und macht dann einen Autodiscover Redirect
  • Ausgehend Mailversand: SPF, DKIM, DMARC, Senderadresse
    Da alle Tenants eigentlich mit den gleichen Office 365 IP-Adressen versenden, würden SPF-Checks erfolgreich sein. Allerdings verhindert Exchange Online normalerweise, dass Sie mit einer SMTP-Adresse senden, die nicht im Tenant hinterlegt ist. Wir müssten also jede Mail aus dem "nicht primären Tenant" durch eine "Umschreibung" leiten und dann entweder selbst oder über den primären Tenant versenden. Das Rewriting müsste aber auch interne Empfänger betreffen, d.h. wenn T1A eine Mal an extern und T1B sendet, dann sollte der externe Empfänger nicht in onmicrosoft.com-Adresse von T1B sehen.

Diese Umschreibung für ausgehende Mails kann durch das Tenant Domain Sharing besser gelöst werden. Dabei bekommt ein anderer Tenant die Erlaubnis, eine Domain für SMTP-Adressen zu verwenden, obwohl diese in einem anderen Tenant als "primär" hinterlegt ist.

Mit all den verschiedenen Empfänger gibt es dann mehrere MailBeziehungen, die Sie alle mal durchspielen sollten. Hier nur eine Teilmenge:

Absender Ziel Beschreibung Status

T1A

T1B

Interne Mail im primären Tenant funktioniert ohne Probleme

OK

T2A

T2B

Interne Mail im sekundären Tenant funktioniert, solange der Eintrag aus dem Adressbuch genutzt wird. Wenn der Absender aber die primäre SMTP-Adresse verwendet, dann ist der Empfänger erst einmal "extern" und geht an den primären Tenant, der dann den Empfänger umschreibt und wieder zurück sendet. Hier muss T2 nun wissen, dass der Absender T2A tatsächlich von extern kommt. Allerdings kann der Rewrite-Service ja auch den Absender umschreiben, damit es "schön" aussieht und der Spoofing-Schutz dann entfällt.

Warn

T1A

T2A

T1A sendet die Mail an die OnMicrosoft-Adresse von T2A. Ein Kontakt im Tenant kann das verbergen.

OK

T1A

T2A
EXTERN

In dem Fall sollten Sie das Tenant Domain Sharing nutzne oder über einen RewritingAgent in der Mail an Extern sicherstellen, dass die OnMicrosoft-Adresse von T2A als TO/CC-Empfänger nicht extern sichtbar wird.

Warn

T2A

T1A
EXTERN

Wie beim vorherigen Szenario muss hier das Tenant Domain Sharing oder Rewriting die T2A-Adresse als Absender und ggfls. von T1A als TO/CC Empfänger berücksichtigen.

Warn

?

?

?

?

Ich habe hier nicht alle Varianten durchgespielt, denn schon mir ist es nicht leicht gefallen, dann alle Varianten bis hier zu lesen und zu verstehen. Nehmen Sie einfach mit: Es ist eine Herausforderung in Exchange, die ohne Tenant Domain Sharing oder andere Kompromisse und zwischengeschaltete "Rewrite-Engines" nicht perfekt zu lösen ist.

Sollten Sie auf Tenant Domain Sharing verzichten, dann könnte ihr Bild mit drei "Namensdomänen" wie folgt aussehen:

Während der "Besitzer" der gemeinsamen Domäne (Grün) keine Besonderheiten zu beachten hat muss der blaue Tenant mehrere Fälle beachten:

Von Nach Beschreibung

Blau

Grün

Der Absender muss auf der grünen Seite auf "msxfaq.de" gedreht werden. Im blauen Exchange Online ist dies nicht möglich, dass Blau diese Domain nicht gehört. Also muss es grün machen oder ein System "dazwischen"

Grün
Rot
Blau
Blau

Wenn ein Anwender aus dem grünen Tenant oder dem Internet jemand im blauen Tenant erreichen will, geht das nicht über die msxfaq.de-Adresse sondern nur über eine andere Domain oder die carius.onmicrosoft.com. Ein entsprechender Kontakt im grünen Tenant ist erforderlich. Es kann aber nicht vermieden werden, dass die "blauen" Benutzer doch die "carius.onmicrosoft.com"-Adresse sehen

Blau

Rot

Wenn Blau ins Internet senden soll, dann muss die Absenderadresse auf msxfaq.de gedreht werden. Das kann Exchange Online aber nicht sondern muss ein vorgelagertes System machen. Wer SPF, DKIM und DMARC ernst nimmt, muss weitere Herausforderungen erfüllen.

Blau

Blau

Dieser Fall ist nicht elegant zu lösen. Natürlich können die Sender und Empfänger in Blau sich über das Adressbuch erreichen. Intern kommt aber die carius.onmicrosoft.com-Adresse zum Einsatz. Wenn ein blauer Anwender eine Mail an eine "msxfaq.de"-Adresse sendet. dann geht sie erst in den grünen Tenant und der Absender wird umgeschrieben. Der Kontakt in Grün leitet dann aber wieder zu Blau weiter. Wenn Blau antwortet, geht es wieder über Grün. Die "carius.onmicrosoft.com"-Adresse im blauen Tenant lässt sich nicht sicher verstecken.

Bei all den Weiterleitungen und Umschreibungen ist zu beachten, dass die Mails den Tenant verlassen und vielleicht mit der gleichen MessageID wieder zurück kommen. Wenn Microsoft zu viele solcher Mails als "Loop" erkennt, landen die Mail in der Quarantäne oder werden gelöscht. Im schlimmsten Fall wird das Mailrouting des Tenants sogar temporär deaktiviert, bis sie das "Problem" gelöst haben.

Denken Sie auch daran, dass Sie Mailadressen nicht nur in den primären Adressfeldern wie From/To umschreiben, sondern auch in CC und BCC. Genau genommen müssten Sie auch in Antworten nach der "carius.onmicrosoft.com"-Adresse suchen und diese umschreiben.

Zwischenstand

Ohne weitere Maßnahmen von Microsoft ist aus meiner Sicht ein "Domain Sharing" mit sehr vielen Einschränkungen verbunden und sollte nicht über eine lange Zeit betrieben werden. Sicher gibt es immer wieder "Merger&Aquisitions", bei denen ein Firmenteil ausgelöst wird und irgendwann unter einem neuen Namen erreichbar sein soll. Dann ist es aber besser sehr früh mit eine neue Domäne zu arbeiten und die alten Adressen nur für eine gewisse Zeit weiter zu leiten.

Wird eine Firma eingebunden und soll nur noch mit der neuen Domäne arbeiten, dann könnte es auch ein Weg sein, sehr schnell die Exchange Daten zu migrieren oder sogar mit einer zweiten "leeren" Mailbox zu starten (Greenfield). ADSync kann problemlos mehrere Forests und Ressource Forests bedienen.

Dann sind wir aber direkt schon im Dialog der Optionen, Vorteile und Nachteile, Kosten und Risiken und das übersteigt den Umfang der MSXFAQ. Hier kann ich sie nur auffordern, das Gespräch mit meinen Kollegen und mir zu suchen. -> Kontakt

Weitere Links