Office 365 - Multi-Forest Umgebung

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?

Identity Management

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

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

Mehrere Forest, Single Tenant, ein DirSync

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.

Mehrere Forests, Single Tenant, zwei DirSync

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

BeBei 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 Tenants mit zwei DirSync

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 Tenant mit einem DirSync

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 DirSync 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 Resource Forest. Die Felder aus dem "AccountForest" werden nur genommen, wenn diese nicht durch den Resource 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.

Weitere Link