ADSync - Topologien

Einfach kann jeder, hat mir mal ein Kunde gesagt, der gerade einen Forest mit Notes nach Exchange migriert und im anderen Forest Exchange benutzt. Wie regelt man hier den Verzeichnisabgleich und die Authentifizierung?

Beachten Sie dazu auch die Seite "Hybrid deployments with multiple forests" https://docs.microsoft.com/de-de/exchange/hybrid-deployment/hybrid-with-multiple-forests

Identity Management

Sobald eine Firma mehr als einen Handvoll Anwender hat, werden Anwender in Office 365 nicht mehr manuell angelegt, sondern natürlich über ADSync bzw. ADSync verwaltet. Ab hier wird es interessant, da es neben der Standardinstallation "Ein Forest = Ein Tenant" auch verschiedene andere Optionen gibt.

Diese Tabelle gilt für ADSync. Für AzureAD Cloud Sync gelten andere Umgebungsbedingungen.

Szenario Status Beschreibung

Single Forest, Single Tenant

Dies ist der "einfache Fall". Eine Firma hat genau einen Forest, welcher mit einem ADSync-Server mit genau einem Tenant verbunden wird. Hier ist erst mal nichts ungewöhnliches. Dieses Szenario ist voll unterstützt und vermutlich das häufigste Szenario.

Mehrere Forest, Single Tenant, ein ADSync

Wenn in der Quelle aber nun nicht mehr nur ein Forest, sondern zwei oder mehrere Forests vorhanden sind, dann ist dies mit ADSync mittlerweile auch möglich. Eine ADSync-Instanz kann relativ problemlos mehrere Forest auslesen und in das eigene Metaverse übertragen und auch Konten zusammenführen.

Gerade die Funktion des "zusammenführen" ist interessant, wenn z.B. in einem Ressource Forest einmal die Anmeldekonten in einem Forest sind und die Exchange Postfächer als Linked Account in einem anderen Forest. Dann ist z.B. das Feld "msExchMasterAccountSID" ein guter Merge-Key. Natürlich kann man auch den UPN oder andere Felder nutzen. Das Ergebnis ist aber, dass im Tenant dann nur ein Objekt vorhanden ist.

Wichtig: Der Betrieb von Exchange/Lync mit einem Account-Forest und einem separaten per Trust verbundenen Ressourcen Forest ist mit Office 365 nicht unterstützt. Siehe dazu Hybrid Ressource Forest.

Für die Identity-Verwaltung ist es egal, ob zwischen den Forests ein Trust besteht, solange der ADSync mit jedem Forest per LDAP kommunizieren kann.

Single Forest, mehrere Tenants mit zwei ADSync

Anders sieht es aus, wenn es zwei Tenants gibt und Sie hier z.B. nur eine Teilmenge des gleichen Quell-Forests synchronisieren. Da es pro Tenant eine eigene ADSync-Instanz gibt, kann es auch zu keinen Konflikten zwischen den Tenants kommen.

Diese Art der Anbindung ist z.B. erforderlich, wenn eine Firma auf mehrere Tenants verteilt werden soll, z.B. weil jede Tochter eine eigene Rechtspersönlichkeit mit eigener Identität und eigener Rechnungslegung ist aber bislang als interne Lösung einen gemeinsamen Forest mit OUs oder mehrere Domänen genutzt hat.

Diese Trennung kann in selteneren Fällen auch aus geografischen Überlegungen gewählt werden.

Meist ist es aber eine Zwischenkonfiguration, um einen Firmenteil als Teil einer Abtrennung bzw. Verkauf nach Office 365 zu migrieren.

Single Forest, mehrere Tenants gleiches Object

Diese Option ist seit ca. Dez 2021 im Preview. Eigentlich sollte es ja nicht möglich sein, da der ADSync z.B. das Feld msDSConsistencyGUID im Rahmen des SourceAnchor zurückschreibt und damit zwei ADSync-Instanzen sich gegenseitig stören würden.

Allerdings ist es bei Merger/Aqusitions eben doch manchmal erforderlich, dass ein AD-Objekt noch im alten Quell-Forest aber auch schon im neuen Zielforest verwaltet wird.

Am 29. Dez 2021 wurde aber in der Doku auf Topologies for Azure AD Connect - Multiple Azure AD Tenants (https://docs.microsoft.com/bs-latn-ba/Azure/active-directory/hybrid/plan-connect-topologies#multiple-azure-ad-tenants) genau das Szenario öffentlich beschrieben. Ich vernute, dass da ein größerer Kunde da Thema eskaliert und Microsoft durch Tests die Funktion bestätigt hat.

Mehrere Forests, Single Tenant, zwei ADSync

Diese Konstellation ist hingegen nicht möglich. Wir haben hier zwar wieder zwei Forests On-Premises und einen Tenant im Ziel, aber getrennte ADSync-Instanzen. Eine ADSync Instanz geht aber davon aus, dass Sie autoritativ für einen Tenant ist

Bei dieser Konstellation kann es also passieren, dass eine ADSync-Instanz "überzählige Objekte" im Tenant löscht, für die es keine Objekte im eigenen Metaverse findet, weil keine aus dem Forest importiert wurden.

Single Forest, Mehrere Tenant mit einem ADSync

Dieser Fall ist nicht möglich, da eine ADSync-Instanz zwar mehrere Quell-Forests oder unterschiedliche OUs einer Domäne abfragen aber immer nur genau einen Tenant im Ziel bedienen.

FIM o.ä.

<Ohne Bild>

Neben dem ADSync von Office 365 können Sie natürlich immer noch den "großen FIM" oder andere Tools einsetzen, um die Identitäten in der Cloud zu verwalten. Diese Produkte können dann natürlich auch die verschiedenen Sonderfälle abdecken, die ich mit ADSync als nicht umsetzbar bezeichnet habe. Ich habe sogar schon Umgebungen gesehen, bei denen alle Office 365 User als "Cloud User" statt "Synchronized User" geführt wurden. Auch das geht wenngleich dann ein Admin auch in der Cloud "verwalten" kann. Hier muss der ADSync dann bidirektional sein oder die Änderungen in der Cloud mit Vorsicht rückgängig machen. Ansonsten laufen die Systeme auseinander.

Diese Auflistung sollte damit die meisten Konstellationen beschrieben haben.

Beachten Sie bei der Planung, dass aktuell (Stand Jun 2015) eine ADSync-Instanz immer nur genau einen Tenant als Ziel bedienen kann und ein Tenant auch immer nur von genau einer ADSync Instanz bedient werden darf.

AADConnect mit mehreren Connectoren

Microsoft hat hierzu zwei sehr lesenswerte Artikel publiziert, von denen ich drei Bilder entliehen habe.

Der "Merge" mehrere Objekte von mehreren Quellen in das Ziel passiert also bei der Überführung in das Metaverse.

Wer hier also schon im Metaverse Viewer zwei Objekte sehen kann, ist sicher dass der Join nicht funktioniert hat.

Wenn Sie dieses Setup im ADSync umgesetzt haben, dann sieht das z.B. so aus:

  • Connections im MetaVerse
    Hier ist gut zu sehen, dass dieses eine Objekt insgesamt drei Connectoren hat. Zwei sind die Active Directory Quellen (Account Domain und Exchange Resourcen Domain) und der dritte Connector ist die Cloud
  • Metaverse Object Properties mit mehreren Quellen
    Gut zu sehen ist hier pro Feld die SyncRule und der "Contribution MA"
  • Synchronisierungsregeln im Editor
    Hier sehen Sie, dass es für jeden Source Connector die entsprechenden Regeln gibt. Wichtig ist hier die Precendence, damit die Felder aus dem "richtigen" Connector kommen. Die kleinere Nummer gewinnt. Das ist in dem Beispiel der Exchange Ressource Forest. Die Felder aus dem "AccountForest" werden nur genommen, wenn diese nicht durch den Ressource Forests gesetzt sind.
  • Blick in die Regeln
    Ein Blick in die "Inbound synchronization Rule" zeigt gut auf, dass hier auch das Feld "msExchMasterAccountSid" einbezogen ist.

    Das ist nur der Fall, wenn Sie beim initialen Setup von ADSync auch diese Betriebsart ausgewählt haben. Eine nachträgliche Änderung ist meines Wissens nur mit einer Neuinstallation von ADSync möglich.

Hybrid Mode mit Tenants und Forest

Der Abgleich von Identitäten mit ADSync ist eigentlich immer nur die Basis für darauf aufsetzende Dienste. Während Teams, OneDrive und SharePoint Online allein in der Cloud bestehen, gilt dies für Exchange und Skype for Business nur bedingt. Hier bedeutet die Koexistenz von Cloud und On-Premises eine Kopplung der Server. Dabei ist zu beachten

  • Exchange n:1
    Es ist möglich, mehrere On-Premises Exchange Organisationen mit je einem Forest zu einem Tenant zu verbinden. Exchange Online und ADSync sind dafür ausgelegt und das Mailrouting ist über die Routing-Domains auch problemlos möglich. Allerdings übernimmt ADSync nicht den Abgleich der Empfänger zwischen den OnPremies Systemen. Insofern haben die Online-User den Vorteil eine komplette GAL zu sehen während dies für die On-Premises-Benutzer nur gilt, wenn ein entsprechender Sync eingerichtet wurde.
  • Skye for Business 1:1
    Bei Skype for Business ist dies aber nicht der Fall. Hier ist ein "Shared SIP-AddressSpace" immer mit genau einer lokalen Topologie möglich. Das liegt auch daran, dass die SIP-Domains in der Cloud und On-Premises gleich sein müssen und schon daher es keinen Parallelbetrieb geben darf.

Als Tabelle lässt sich das dann recht einfach darstellen: Denken Sie daran, dass eine Domain immer nur genau in einem Tenant eingetragen sei nkann

Forests Tenants Exchange Hybrid Skype for Business Hybrid

1

1

OK

OK

2

1

OK

Nicht supported

1

2

Nein
Denn alle Accepted Domains müssen auch im Tenant hinterlegt sein, da sonst die ProxyAddressen fehlen.

Nein
Alle lokalen SIP-Domains müssen im Tenant ebenfalls als Domain hinterlegt sein

2

2

Nein

Nein

Alle "Versuche" die nicht möglichen Konstellationen irgendwie hin zu bekommen, z.B. indem Sie die Warnungen zu fehlenden Domains im Tenant ignorieren, sind mit den ein oder anderen Funktionseinschränkungen oder Fehlern verbunden.

Es gibt Sonderfälle, der allerdings denkbar sind, z.B. wenn Sie einen Forest mit mehreren OUs haben und die Empfänger in den OUs sehr gut separiert sind, z.B. keine gemeinsame SMTP-Adresse haben. Dann können Sie mit Einschränkungen so tun, als wären es zwei Firmen mit eigenem Adressraum, die auch in zwei Tenants repliziert werden. Sie brauchen dann aber zwei ADSync-Instanzen die auch sauber getrennt arbeiten.
Da es nicht offiziell beschrieben oder getestet ist, sollten Sie die Funktion ausgiebig testen und nicht allzu lange betreiben.

Weitere Link