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.
- Connector Flow
Das erste Bild erinnert noch einmal an die drei Stationen, die ein Objekt von einer Quelle in ein Ziel beim Verzeichnisabgleich durchlaufen muss. Es geht zuerst von der Quelle in den jeweiligen Connector-Space um dann in das MetaVerse überführt zu werden und dann beim Export in das Ziel, Meist Office 365, übertragen wird.
Quelle: https://azure.microsoft.com/en-us/documentation/articles/active-directory-aadconnectsync-understanding-declarative-provisioning/ - Stationen der Verarbeitung
Auf der gleichen Seite sind auch die Phasen
Quelle: https://azure.microsoft.com/en-us/documentation/articles/active-directory-aadconnectsync-understanding-declarative-provisioning/
Aus der Quelle werden erst alle Objekte über den optionalen Scope (OU, LDAP-Felder o.ä.) gefiltert und dann über JOIN-Rules auf ein Objekt im Metaverse abgebildet. Dann werden die ausgewählten Attribute anhand der Transformationsregeln ggfls. umgeschrieben und wenn das Feld im Ziel durch mehrere Source-Connectoren geliefert wird, anhand der Precedence (niedrigste Nummer zuerst) in das Metaverse geschrieben. - Mehrere Quellen und ein Metaverse
Das zweite Bild auf der anderen Webseite zeigt wie nun mehrere Quellen durch den ADSync konsolidiert werden. Die Zusammenführung erfolgt als auf dem Weg von Connector-Space zum MetaVerse
Quelle: https://azure.microsoft.com/en-us/documentation/articles/active-directory-aadconnect-topologies/#multiple-forests-account-resource-forest
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 |
Nein |
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
- Office365:SourceAnchor und ADMT
- Office 365:Identity
- Office 365 Multi Forest ADFS
- Authentifizierung
- Hybrid Ressource Forest
- AzureAD Cloud Sync
-
Managing Hybrid Identities
Across Portals
http://blogs.technet.com/b/askpfeplat/archive/2015/08/31/managing-hybrid-identities-across-portals.aspx -
Hybrid deployments with multiple
forests
https://docs.microsoft.com/de-de/exchange/hybrid-deployment/hybrid-with-multiple-forests -
Federate multiple instances of
Azure AD with single instance of
AD FS
https://docs.microsoft.com/en-us/azure/active-directory/connect/active-directory-aadconnectfed-single-adfs-multitenant-federation -
Multi-forest and Multi-tenant
scenarios with Office 365
https://blogs.technet.microsoft.com/educloud/2013/08/02/multi-forest-and-multi-tenant-scenarios-with-office-365/ -
Office 365: Deciding Between
Single and Multiple Tenants
https://blogs.technet.microsoft.com/ukprodandcomms/?p=182 -
Office 365 – Why You Need to
Understand ImmutableID
http://blogs.perficient.com/microsoft/2015/04/office-365-why-you-need-to-understand-immutableid/ -
Moving ADSync Between Active
Directory Forests
https://blog.kloud.com.au/author/andywalker1979/ -
Real world Azure AD Connect:
multi forest User and resource + User forest implementation
https://blog.kloud.com.au/2016/12/02/real-world-azure-ad-connect-multi-forest-User-and-resource-User-forest-implementation/ - Choosing a sourceAnchor for
Multi-Forest Sync with AAD
Connect
Part 1, Introduction https://blogs.technet.microsoft.com/markrenoden/2017/02/20/choosing-a-sourceanchor-for-multi-forest-sync-with-aad-connect-part-1-introduction/
Part 2, Lab Setup https://blogs.technet.microsoft.com/markrenoden/2017/02/20/choosing-a-sourceanchor-for-multi-forest-sync-with-aad-connect-part-2-lab-setup/
Part 3, An Aside on EmployeeID https://blogs.technet.microsoft.com/markrenoden/2017/02/21/choosing-a-sourceanchor-for-multi-forest-sync-with-aad-connect-part-3-an-aside-on-employeeid/
Part 4, Using msDS-SourceAnchor https://blogs.technet.microsoft.com/markrenoden/2017/02/22/choosing-a-sourceanchor-for-multi-forest-sync-with-aad-connect-part-4-using-msds-sourceanchor/
Part 5, Using mS-DS-ConsistencyGuid https://blogs.technet.microsoft.com/markrenoden/2017/02/23/choosing-a-sourceanchor-for-multi-forest-sync-with-aad-connect-part-5-using-ms-ds-consistencyguid/
Part 6, Moving off objectGuid https://blogs.technet.microsoft.com/markrenoden/2017/02/24/choosing-a-sourceanchor-for-multi-forest-sync-with-aad-connect-part-6-moving-off-objectguid/
Part 7, Migrating Users https://blogs.technet.microsoft.com/markrenoden/2017/02/24/choosing-a-sourceanchor-for-multi-forest-sync-with-aad-connect-part-7-migrating-Users/