Hybrid Resource Forest

Diese Seite beleuchtet die Besonderheiten eines Betriebs von Exchange On-Prem mit Office 365 im Hybrid-Mode in Verbindung mit LinkedMailboxen. Exchange On-Prem kennt die Betriebsart des "Ressourceforest". Dabei sind die AD-Objekte mit den Postfachdaten in einem Forest angelegt aber die Anmeldung der Anwender erfolgt über ein Konto in einem anderen Forest, der aber über einen Trust angebunden ist. Diese Betriebsart wird oft in großen Organisationen mit mehreren Töchtern eingesetzt, die zentrale Dienste wie Exchange, Skype for Business und andere in einen gemeinsame Forest betreiben aber die len PCs und deren Verwaltung (Gruppenrichtlinien, Drucker, Anmeldeskripte etc.) verbleibt bei lokalen Administratoren. Das Modell kommt auch schnell mal zum Einsatz, wenn eine Firma gekauft wird und die Postfächer möglichst schnell in die gemeinsame Organisation überführt werden (Stichwort gemeinsame GAL, gemeinsame SMTP-Domäne etc.) aber die Migration der Anmeldekonten, Gruppenrichtlinien, sonstiger Server und Clients länger dauert oder über die 3-5 Jahre "Life Cycle" eines PCs oder Servers ausgedehnt wird.

Für das Verständnis der Seite ist es nützlich die Seiten LinkedMailboxen, Ressourceforest, Disabled Account und Office 365:DirSync mit Exchange zu kennen

Linked Mailbox und Office 365

Organisationen mit einem Exchange Ressource Forest können auch Exchange Online nutzen und im Hybrid-Mode konfigurieren. Der Verzeichnisabgleich durch ADSync unterstützt explizit den Betrieb von Linked Mailboxen. ADSync kann dazu, anders als der frühere DirSync auch mehrere Source-Forests abfragen und die Daten zusammenführen. Das daraus resultierende Objekt im MetaVerse wird dann in die Cloud repliziert. Damit landen auch solche Postfächer korrekt als "Exchange Empfänger" im Azure AD. Dort müssen Sie ankommen, da ansonsten die Benutzer in der Cloud ja nicht wissen, dass es das lokale Postfach gibt. Hier erst mal ein vereinfachtes Bild:

Bei so einem Betrieb gibt es aber mehrere Herausforderungen zu bewältigen, von denen ein Teil schon zu klären ist, ehe Sie überhaupt ADSync einrichten.

  • Disabled Account darf in der Cloud nicht deaktiviert werden
    Wenn Konten im lokalen AD deaktiviert sind, dann werden diese vom ADSync auch in der Cloud deaktiviert. Das ist für "Benutzerkonten, die nur Platzhalter für eine "RoomMailbox" oder "SharedMailbox" sind aber auch für tatsächlich deaktivierte Benutzer richtig. Hier wäre es aber schädlich, da sich der eigentliche Benutzer auch nicht mehr anmelden kann.
  • UPN und SourceAnchor
    Dann stellt sich die Frage, von welchem der beiden Konten der ADSync-Prozess die ObjectGUID und den UPN hernimmt. Da die "Anmeldung über das rechte Konto im Anmeldeforest erfolgen muss, ist logisch, dass von dort der UPN genommen wird. Wird das Postfächer später in die Cloud verschoben, muss sich der Anwender mit diesem Konto ein Ticket besorgen.
  • Wie "matched" ADSync die beiden Konten
    ADSync liest ja aus zwei Forests die Daten aus und das per Default die ObjectGUID des lokalen Objektes zum SourceAnchor im Metaverse und zur ImmutableID in der Cloud wird und diese ObjectGUID eindeutig ist, würde es in der Cloud dann auch zwei Identitäten geben. Damit dies nicht passiert, kann ADSync mehrere AD-Konten aus mehreren Forests anhand eines anderen Felds zusammenführen:
  • Property-Quelle
    Wenn ein Objekt im Metaverse aus mehreren Quellen mit Daten versorgt wird, dann muss klar sein, von welchem Quellobjekt welches Feld eingelesen wird. Stellen Sie sich vor, das Feld Displayname wäre in beiden Forests unterschiedlich gefüllt.

Wer ADSync nicht über die Express-Option installiert, sieht irgendwann folgendes Bild, bei dem aber die oberste Option per Default ausgewählt ist.

Normalerweise ist die Option "Uers are represented only once acreoss all directories" aktiv. Bei einer Ressource Forest Umgebung ist natürlich die hier rot umrandete Option besser. ADSync importiert dann aus jedem Verzeichnis die Objekte und führt übereinstimmende Objekte zusammen, so dass es nur ein Objekt im Metaverse gibt.

Disabled accounts are synchronized as well to Azure AD. Disabled accounts are common to represent resources in Exchange, for example conference rooms. The exception is Users with a linked mailbox; as previously mentioned, these will never provision an account to Azure AD.
The assumption is that if a disabled User account is found, then we will not find another active account later and the object is provisioned to Azure AD with the UserPrincipalName and sourceAnchor found. In case another active account will join to the same metaverse object, then its UserPrincipalName and sourceAnchor will be used.
Quelle: Understanding Users and Contacts in Azure Active Directory Sync (https://msdn.microsoft.com/nl-nl/library/azure/dn783470.aspx)

"Precendence"

Beim Hybrid Ressourceforest-Modell muss ADSync die Daten zum Benutzer und dessen Anmeldedaten, also primär den UPN auf jeden Fall aus dem Account-Forest nutzen. Auf der anderen Seite müssen alle Informationen zu Exchange aus dem Ressource-Forest kommen. Durch das Setup werden für jeden Forest entsprechende Replication Rules angelegt.

Dabei gewinnt der Eintrag mit der niedrigsten Nummer.

Precedence determines what rule wins(lower numeric value) a conflict resolution if there's an attribute flow conflict.
Quelle: How to customize a synchronization rule
https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/how-to-connect-create-custom-sync-rule

Das bedeutet aber nun auch, dass der UPN aus dem Forest kommt. welcher an der niedrigsten Stelle steht. Sollte dies der Ressource Forest sein, dann kommt von dort auch der UPN. Gewünscht ist natürlich, dass der Account-Forest an erster Stelle steht und der Exchange Ressource Forest danach folgt. Das bedeutet dann aber auch, dass die für Exchange relevanten Felder im Account-Forest entweder leer oder identisch zum Ressource-Forest sein müssen. Idealerweise hat Account-Forests nie eine Exchange Installation gesehen, so dass es dort auch keine Schema-Erweiterung gibt.

Cloud Postfach mit Linked Account

Der nächste Schritt besteht darin, das Postfach selbst in die Cloud zu verschieben. Der eigentliche Verschiebe-Prozess ist mit Office 365 Bordmitteln recht einfach realisiert. Office 365 repliziert mittels MRSProxy per HTTPS die Mails vom On-Prem Exchange Postfach in die Cloud und wenn alle Daten "drüben" sind, dann wird das Cloud Postfach aktiviert und aus dem lokalen Postfach im Ressource Forest wird eine "RemoteMailbox". Es bleibt lokal also ein deaktivierter AD-Benutzer mit Exchange Properties, die aber über die TargetAddress Mails zur Cloud routet.

Neuanlage eines Cloud Konto mit Linked Account

irgendwann werden Benutzer nicht mehr nur durch Migration in die Cloud verschoben sondern auch direkt in der Cloud angelegt. Sie können das Anmeldekonto zwar im Anmeldeforest anlegen aber dort gibt es ja kein Exchange. Sie müssen dazu nun also noch eine "Remote Mailbox" im Exchange Ressourcen Forrest anlegen. Damit aber ADSync nun nicht das Konto aus dem Ressource Forest als "Anmeldekonto irrtümlich in die Cloud repliziert, müssen Sie hier weiterhin die Felder einer klassischen "Linked Mailbox" füllen. Es gibt nur keine "Remote Linked Mailbox".

Wenn Sie nun einen neuen Benutzer direkt in der Cloud anlegen müssen, dann ist der folgende Weg korrekt:

  1. Anlegen des Anmeldekontos im Anmeldeforest
    ADSync kann gerne den Benutzer schon in die Cloud anlegen. Er darf nur noch keine Lizenz bekommen.
  2. Anlegen einer Remote Mailbox mit MasterAccountSid im Resource Forest
    Dieser Schritt muss ohne Zeitverzug passieren, damit ADSync nicht mitten in einem Synclauf eine RemoteMailbox ohne MasteraccountSID findet.
  3. ADSync abwarten
    ADSync findet beide Objekte und führt diese zusammen. Am Ende haben wir in der Cloud eine Identität mit Postfach
  4. Benutzer in der Cloud lizenzieren
    Erst wenn das Office 365 Objekte mit den Exchange Properties versorgt ist, darf eine Exchange Online Lizenz zu gewiesen werden.

Der Aufwand ist also etwas größer aber wenn Sie die Zusammenhänge verstanden haben, ist das auch verständlich-

Lokale Reorganisation

Oft laufen bei Firmen mehrere Projekte parallel. Wer heute mehrere AD-Forests betreibt, wird mit Office 365 vielleicht auch eine Vereinfachung der lokalen Umgebung anstreben und z.B. Forests zurückbauen. Dazu müssen Sie natürlich vorher die Objekte in dem Forest in das neue Ziel verschieben oder neu anlegen.

Ein Office 365 Tenant kann übrigens problemlos auch mit mehreren Exchange Organisationen verbunden werden. Dies wird von Microsoft auch unterstützt und ist damit eine Option den Ressourcen Forrest los zu werden, wenn die Migration nach Office 365 abgeschlossen ist.

Allerdings brauchen Sie in Verbindung mit ADSync natürlich auch im Jahr 2019 noch einen Exchange Server On-Premises, um die Exchange-Eigenschaften der lokalen AD-Objekte zu verwalten. Mehr Informationen finden Sie dazu auf den beiden Seiten:

Wenn Sie Objekte On-Premises zusammenführen, z.B. indem Sie die Exchange Eigenschaften der Remote Mailbox des Ressourcen Forest an das AD-Konto im Anmeldeforest übertragen wollen, dann müssen Sie erst einmal ein paar Vorarbeiten leisten:

  • Exchange Schema-Erweiterung im Anmeldeforest
    Sonst können Sie dort ja die Informationen nicht schreiben
  • Exchange Hybrid Server im Anmeldeforest installieren
    Ansonsten haben Sie keine PowerShell zum Verwalten der Empfänger und bei den meisten Firmen ist auch ein lokaler SMTP-Brückenkopf gefordert, damit interne Systeme nicht direkt mit Office 365 bidirektional kommunizieren müssen.

Die erste Aufgabe vor der Abschaltung des Ressource Forest ist daher der Aufbau eines Exchange im Anmeldeforest, der danach übrig bleibt.

Nun kommt aber dazu, dass Sie ja die Remote Mailbox im Ressource Forest nicht einfach löschen können. ADSync würde das schon richtig verstehen und das Postfach in der Cloud weg nehmen. Wenn Sie sich die Mühe einer Wiederherstellung des Cloud-Postfachs ersparen wolle, dann sorgen Sie besser dafür, dass die Änderung sich nur so auf die beiden lokalen Objekte bezieht, dass im Metaverse sich einfach nur die Quelle für die Information ändert. Das funktioniert im Prinzip auf folgende Weise

  • Anhalten ADSync
    Wir möchten zuverlässig verhindern, dass zwischen den Änderungen in beiden Forest der ADSync die Daten halb liest.
  • Remote Mailbox im Anmeldeforest
    Aus dem Anmeldebenutzer ohne Exchange Eigenschaften wird nun eine Remote-Mailbox mit der gleichen TargetAddresse, Proxy Addresses etc wie im bisherigen Ressource Forest.
  • Remote Mailbox im Ressource Forest für ADSync ausschließen
    Ich würde das Objekt noch nicht löschen, da es ja noch andere Empfänger in dem Ressource Forest gibt, die das Objekt noch brauchen. Aber ADSync sollte das Objekt nicht mehr sehen. Dazu können Sie in ADSync einen Import-Filter auf LDAP-Felder, Gruppenmitgliedschaften oder OUs setzen. Wenn Sie also eine von ADSync ausgeschlossene OU für diese umgestellten Objekte vorbereitet haben, dann verschieben Sie das Konto einfach dort hin.
  • ADSync mit "Import" starten
    Nun geht es an den Import. Der Import aus dem Ressource Forest "sieht" das Object nicht mehr und Entfernt die Exchange Properties im Metaverse. Nun kommt aber noch der Import au dem Account-Forest nach und hier sind nun genau diese Felder bei der neuen "Remote Mailbox" vorhanden. ADSync importiert die Werte und wenn alles glatt geht, dann gibt es nichts, was er Richtung Office 365 schreiben muss.

Das ist natürlich nur die "Einfach-Version", denn wenn Sie beide Exchange Forests einige Zeit parallel betreiben, dann sollten Sie schon Hilfsmittel einsetzen, um die Empfänger zwischen den Forests abzugleichen und vor allem auch die Mitgliedschaften den den Gruppe (=Mailverteiler) synchronisieren oder die Gruppen in einem System auf dem anderen System als "Kontakt" anzulegen.

Ein Verzeichnisabgleich zwischen drei Umgebungen muss gut überlegt sein, da ADSync nur die Aufgabe übernimmt, von den beiden Forests die Daten in die Cloud zu bringen aber nicht zurück repliziert und erst recht nicht die beiden Forests miteinander abgleich. Das ist dann eine Aufgabe für Skripte, 3rd Party-Produkte oder ein Identity Management. Das würde aber den Rahmen der MSXFAQ hier sprengen. Umgebungen mit diesen Anforderungen lassen Sie hier eh helfen oder bauen das Know-how selbst auf.

Weitere Links