Topologien für Azure AD Connect

In diesem Artikel werden verschiedene lokale und Azure Active Directory (Azure AD)-Topologien beschrieben, die Azure AD Connect-Synchronisierung als Schlüsselintegrationslösung verwenden. In diesem Artikel werden sowohl unterstützte als auch nicht unterstützte Konfigurationen beschrieben.

Legende für Bilder im Artikel:

BESCHREIBUNG	Symbol
Lokale Active Directory-Gesamtstruktur
Lokales Active Directory mit gefiltertem Import
Azure AD Connect-Synchronisierungsserver
Azure AD Connect-Synchronisierungsserver „Stagingmodus“
GALSync mit Forefront Identity Manager (FIM) 2010 oder Microsoft Identity Manager (MIM) 2016
Azure AD Connect-Synchronisierungsserver, detailliert
Azure AD
Nicht unterstütztes Szenario

Wichtig

Microsoft unterstützt die Änderung oder den Einsatz der Azure AD Connect-Synchronisierung außerhalb dieser formal dokumentierten Konfigurationen oder Aktionen nicht. Diese Konfigurationen oder Aktionen können zu einem inkonsistenten oder nicht unterstützten Status der Azure AD Connect-Synchronisierung führen. Folglich kann Microsoft auch keinen technischen Support für solche Bereitstellungen leisten.

Einzelne Gesamtstruktur, einzelner Azure AD-Mandant

Die häufigste Topologie ist eine einzelne lokale Gesamtstruktur mit einer oder mehreren Domänen und einem einzelnen Azure AD-Mandanten. Für die Azure AD-Authentifizierung wird die Kennworthashsynchronisierung verwendet. Die Expressinstallation von Azure AD Connect unterstützt nur diese Topologie.

Einzelne Gesamtstruktur, mehrere Synchronisierungsserver zu einem Azure AD-Mandanten

Das Verbinden mehrerer Azure AD Connect-Synchronisierungsserver mit dem gleichen Azure AD-Mandanten wird nicht unterstützt, Stagingserver ausgenommen. Dies wird auch dann nicht unterstützt, wenn diese Server für die Synchronisierung sich gegenseitig ausschließender Objektsätze konfiguriert sind. Diese Topologie haben Sie möglicherweise in Betracht gezogen, wenn Sie nicht alle Domänen in der Gesamtstruktur über einen einzelnen Server erreichen können oder die Last auf mehrere Server verteilen möchten. (Es treten keine Fehler auf, wenn ein neuer Azure AD-Synchronisierungsserver für eine neue Azure AD-Gesamtstruktur und eine neue überprüfte untergeordnete Domäne konfiguriert wird.)

Mehrere Gesamtstrukturen, einzelner Azure AD-Mandant

Viele Organisationen verfügen über Umgebungen mit mehreren lokalen Active Directory-Gesamtstrukturen. Für die Verwendung mehrerer lokaler Active Directory-Gesamtstrukturen gibt es verschiedene Gründe. Typische Beispiele sind Entwürfe mit Kontoressourcengesamtstrukturen und Gesamtstrukturen nach einer Unternehmensfusion oder -übernahme.

Wenn Sie über mehrere Gesamtstrukturen verfügen, müssen alle Gesamtstrukturen von einem einzelnen Azure AD Connect-Synchronisierungsserver aus erreichbar sein. Der Server muss in eine Domäne eingebunden werden. Wenn alle Gesamtstrukturen erreichbar sein müssen, kann der Server in einem Umkreisnetzwerk (auch bekannt als DMZ, demilitarisierte Zone und überwachtes Subnetz) platziert werden.

Der Installationsassistent von Azure AD Connect bietet mehrere Optionen zur Konsolidierung von Benutzern in mehreren Gesamtstrukturen. Das Ziel besteht darin, dass ein Benutzer lediglich einmal in Azure AD vorhanden ist. Es gibt einige allgemeine Topologien, die Sie im benutzerdefinierten Installationspfad im Installations-Assistenten konfigurieren können. Wählen Sie auf der Seite Eindeutige Identifizierung der Benutzer die entsprechende Option für Ihre Topologie aus. Die Konsolidierung wird nur für Benutzer konfiguriert. Duplizierte Gruppen werden mit der Standardkonfiguration nicht konsolidiert.

Allgemeine Topologien werden in den Abschnitten über separate Topologien unter Vollständig vermaschtes Netz und Kontoressource erläutert.

Die Standardkonfiguration der Azure AD Connect-Synchronisierung basiert auf folgenden Annahmen:

• Jeder Benutzer hat nur ein einziges aktiviertes Konto, und die Gesamtstruktur, in der sich dieses Konto befindet, wird verwendet, um den Benutzer zu authentifizieren. Diese Annahme gilt für die Kennworthashsynchronisierung, Pass-Through-Authentifizierung und den Verbund. „userPrincipalName“ und „sourceAnchor/immutableID“ stammen aus dieser Gesamtstruktur.
• Jeder Benutzer hat nur ein Postfach.
• Die Gesamtstruktur, die das Postfach für einen Benutzer hostet, hat die beste Datenqualität für Attribute, die in der globalen Exchange-Adressliste (Global Address List, GAL) sichtbar sind. Wenn kein Postfach für den Benutzer vorhanden ist, kann jede Gesamtstruktur verwendet werden, um diese Attributwerte beizutragen.
• Wenn Sie über ein verknüpftes Postfach verfügen, wird auch ein Konto in einer anderen Gesamtstruktur für die Anmeldung verwendet.

Wenn Ihre Umgebung diesen Annahmen nicht entspricht, passiert Folgendes:

• Wenn Sie über mehrere aktive Konten oder Postfächer verfügen, wählt das Synchronisierungsmodul eines davon aus und ignoriert die anderen.
• Verknüpfte Postfächer ohne anderes aktives Konto werden nicht in Azure AD exportiert. Das Benutzerkonto wird nicht als Mitglied einer Gruppe dargestellt. Ein verknüpftes Postfach in DirSync wird stets als normales Postfach angezeigt. Diese Änderung ist eine absichtlich herbeigeführte Verhaltensänderung, um Szenarien mit mehreren Gesamtstrukturen besser unterstützen zu können.

Ausführlichere Informationen finden Sie unter Grundlegendes zur Standardkonfiguration.

Mehrere Gesamtstrukturen, mehrere Synchronisierungsserver zu einem Azure AD-Mandanten

Das Verbinden mehrerer Azure AD Connect-Synchronisierungsserver mit einem einzelnen Azure AD-Mandanten wird nicht unterstützt. Von dieser Regel sind lediglich Stagingserverausgenommen.

Diese Topologie unterscheidet sich von der folgenden dadurch, dass nicht mehrere Synchronisierungsserver unterstützt werden, die mit einem einzigen Azure AD-Mandanten verbunden sind. (Dies wird zwar nicht unterstützt, funktioniert aber dennoch.)

Mehrere Gesamtstrukturen, ein einziger Synchronisierungsserver, Darstellung von Benutzern in einem einzigen Verzeichnis

In dieser Umgebung werden alle lokalen Gesamtstrukturen als getrennte Entitäten behandelt. Kein Benutzer ist in einer anderen Gesamtstruktur vorhanden. Jede Gesamtstruktur verfügt über eine eigene Exchange-Organisation, und es gibt keine GALSync zwischen den Gesamtstrukturen. Diese Topologie kann beispielsweise nach einer Fusion/Übernahme oder in einer Organisation vorliegen, in der jede Geschäftseinheit unabhängig agiert. Diese Gesamtstrukturen befinden sich in der gleichen Organisation in Azure AD und werden mit einer einheitlichen GAL angezeigt. In der vorherigen Abbildung wird jedes Objekt in jeder Gesamtstruktur einmal im Metaverse dargestellt und im Azure AD-Mandanten aggregiert.

Mehrere Gesamtstrukturen: Benutzer abgleichen

Diese Szenarien haben alle eins gemeinsam: Die Verteiler- und Sicherheitsgruppen können eine Kombination aus Benutzern, Kontakten und fremden Sicherheitsprinzipalen (Foreign Security Principals, FSPs) enthalten. FSPs werden in Active Directory Domain Services (AD DS) verwendet, um Mitglieder aus anderen Gesamtstrukturen in einer Sicherheitsgruppe darzustellen. Alle FSPs werden zu dem eigentlichen Objekt in Azure AD aufgelöst.

Mehrere Gesamtstrukturen: Vollständiges Netz mit optionaler GALSync

Mit einer vollständig vernetzten Topologie können sich Benutzer und Ressourcen in jeder Gesamtstruktur befinden. Häufig bestehen bidirektionale Vertrauensstellungen zwischen den Gesamtstrukturen.

Wenn Exchange in mehreren Gesamtstrukturen vorhanden ist, kann (optional) eine lokale GALSync-Lösung vorhanden sein. Dadurch wird jeder Benutzer in allen anderen Gesamtstrukturen als Kontakt dargestellt. GALSync wird in der Regel über FIM 2010 oder MIM 2016 implementiert. Azure AD Connect kann nicht für lokale GALSync verwendet werden.

In diesem Szenario werden Identitätsobjekte über das E-Mail-Attribut verknüpft. Ein Benutzer mit einem Postfach in einer Gesamtstruktur wird mit den Kontakten in den anderen Gesamtstrukturen verknüpft.

Mehrere Gesamtstrukturen: Kontoressourcengesamtstruktur

In einer Topologie mit Kontoressourcengesamtstruktur verfügen Sie über eine oder mehrere Kontogesamtstrukturen mit aktiven Benutzerkonten. Außerdem verfügen Sie über mindestens eine Ressourcengesamtstruktur mit deaktivierten Konten.

In diesem Szenario vertraut (mindestens) eine Ressourcengesamtstruktur allen Kontogesamtstrukturen. Diese Ressourcengesamtstruktur verfügt in der Regel über ein erweitertes Active Directory-Schema mit Exchange und Lync. Alle Dienste von Exchange und Lync sowie andere freigegebene Dienste befinden sich in dieser Gesamtstruktur. Benutzer haben ein deaktiviertes Benutzerkonto in dieser Gesamtstruktur, und das Postfach ist mit der Kontengesamtstruktur verknüpft.

Microsoft 365 und Überlegungen zur Netzwerktopologie

Für einige Microsoft 365-Workloads gelten bestimmte Einschränkungen für unterstützte Topologien:

Workload	Beschränkungen
Exchange Online	Weitere Informationen zu Hybridtopologien, die von Exchange Online unterstützt werden, finden Sie unter Hybridbereitstellungen mit mehreren Active Directory-Gesamtstrukturen.
Skype for Business	Wenn Sie mehrere lokale Gesamtstrukturen verwenden, wird nur die Topologie mit Kontoressourcengesamtstruktur unterstützt. Weitere Informationen finden Sie unter Anforderungen für die Umgebung für Skype for Business Server 2015.

Wenn es sich um eine größere Organisation handelt, sollten Sie die Verwendung des Features Microsoft 365 PreferredDataLocation in Erwägung ziehen. Mit diesem Feature können Sie festlegen, in welcher Rechenzentrumsregion sich die Ressourcen des Benutzers befinden.

Stagingserver

Azure AD Connect unterstützt die Installation eines zweiten Servers im Stagingmodus. Ein Server in diesem Modus liest Daten aus allen verbundenen Verzeichnissen, schreibt jedoch nicht in die verbundenen Verzeichnisse. Er verwendet den normalen Synchronisierungszyklus und verfügt daher über eine aktualisierte Kopie der Identitätsdaten.

Bei einem notfallbedingten Ausfall des primären Servers kann ein Failover auf den Stagingserver durchgeführt werden. Hierzu wird der Azure AD Connect-Assistent verwendet. Dieser zweite Server kann sich in einem anderen Rechenzentrum befinden, da keine Infrastruktur mit dem primären Server gemeinsam genutzt wird. Jede am primären Server vorgenommene Konfigurationsänderung muss manuell an den zweiten Server kopiert werden.

Sie können einen Stagingserver auch verwenden, um eine neue benutzerdefinierte Konfiguration und deren Auswirkungen auf die Daten zu testen. Sie können eine Vorschau der Änderungen anzeigen und die Konfiguration anpassen. Wenn Sie mit der neuen Konfiguration zufrieden sind, können Sie den Stagingserver zum aktiven Server machen und den alten aktiven Server in den Stagingmodus versetzen.

Mit dieser Methode können Sie auch den aktiven Synchronisierungsserver ersetzen. Bereiten Sie den neuen Server vor, und versetzen Sie ihn in den Stagingmodus. Vergewissern Sie sich, dass er sich in einem fehlerfreien Zustand befindet, deaktivieren Sie den Stagingmodus, um den Server zu aktivieren, und fahren Sie den derzeit aktiven Server herunter.

Sie können mehrere Stagingserver verwenden, wenn Sie mehrere Sicherungen in verschiedenen Rechenzentren benötigen.

Mehrere Azure AD-Mandanten

Wir empfehlen einen einzelnen Mandanten in Azure AD für eine Organisation. Wenn Sie mehrere Azure AD-Mandanten verwenden möchten, erhalten Sie im Artikel Verwaltung administrativer Einheiten in Azure AD weitere Informationen. Es umfasst häufige Szenarien, in denen Sie einen einzelnen Mandanten verwenden können.

Synchronisieren von AD-Objekten mit mehreren Azure AD-Mandanten

Mit dieser Topologie werden die folgenden Anwendungsfälle realisiert:

• AADConnect kann die Benutzer, Gruppen und Kontakte aus einer einzelnen Active Directory-Instanz mit mehreren Azure AD-Mandanten synchronisieren. Diese Tenants können sich in verschiedenen Azure-Umgebungen befinden, z. B. in der Azure China-Umgebung oder in der Azure Government-Umgebung, aber auch in derselben Azure-Umgebung, z. B. zwei Tenants, die sich beide in Azure Commercial befinden. Weitere Informationen zu Optionen finden Sie unter [Planungsidentität für Azure Government-Anwendungen] (/azure/azure-government/documentation-government-plan-identity).
• Derselbe Quellanker kann für ein einzelnes Objekt in verschiedenen Mandanten (aber nicht für mehrere Objekte in demselben Mandanten) verwendet werden. (In zwei Mandanten kann nicht dieselbe überprüfte Domäne verwendet werden. Es sind weitere Details erforderlich, damit dasselbe Objekt über zwei Benutzerprinzipalnamen verfügen kann.)
• Sie müssen einen AADConnect-Server für jeden Azure AD-Mandanten bereitstellen, mit dem eine Synchronisierung erfolgen soll. Ein AADConnect-Server kann nicht mit mehr als einem Azure AD-Mandanten synchronisiert werden.
• Für verschiedene Mandanten sind unterschiedliche Synchronisierungsumfänge und -regeln möglich.
• Es kann nur eine Azure AD-Tenant-Synchronisierung für dasselbe Objekt zum Zurückschreiben in Active Directory konfiguriert werden. Dazu gehören Geräte- und Gruppenrückschreibungen sowie Hybrid Exchange-Konfigurationen - diese Funktionen können nur in einem Mandanten konfiguriert werden. Die einzige Ausnahme ist das Zurückschreiben des Passworts - siehe unten.
• Es wird unterstützt, Password Hash Sync von Active Directory zu mehreren Azure AD-Tenants für dasselbe Benutzerobjekt zu konfigurieren. Wenn Password Hash Sync für einen Mandanten aktiviert ist, kann auch Password Writeback aktiviert werden, und zwar für mehrere Mandanten: Wenn das Passwort auf einem Mandanten geändert wird, wird es durch Password Writeback in Active Directory aktualisiert, und Password Hash Sync aktualisiert das Passwort in den anderen Mandanten.
• Das Hinzufügen und Überprüfen desselben benutzerdefinierten Domänennamens in mehr als einem Azure AD-Mandanten wird nicht unterstützt, auch wenn sich diese Mandanten in unterschiedlichen Azure-Umgebungen befinden.
• Das Konfigurieren von Hybridumgebungen, die die Konfiguration auf Gesamtstrukturebene in AD mit mehr als einem Mandanten nutzen (z. B. nahtloses einmaliges Anmelden und Azure AD Hybrid Join (nicht zielgerichteter Ansatz)) wird nicht unterstützt. Dies würde die Konfiguration des anderen Mandanten überschreiben und ihn unbrauchbar machen. Weitere Informationen finden Sie unter Planen Ihrer Azure Active Directory Hybrid Join-Bereitstellung.
• Sie können Geräteobjekte mit mehr als einem Mandanten synchronisieren, aber ein Gerät kann mit Azure AD Hybrid Join nur in einen Mandanten hybrid eingebunden sein.
• Alle Azure AD Connect-Instanzen sollten auf einem in die Domäne eingebundenen Computer ausgeführt werden.

Hinweis

Die Synchronisierung der globalen Adressliste (GalSync) erfolgt in dieser Topologie nicht automatisch und erfordert eine zusätzliche benutzerdefinierte MIM-Implementierung, um sicherzustellen, dass jeder Mandant über eine vollständige globale Adressliste (GAL) in Exchange Online und Skype for Business Online verfügt.

GALSync mithilfe von Rückschreiben

GALSync mit lokalem Synchronisierungsserver

Sie können FIM 2010 oder MIM 2016 lokal verwenden, um Benutzer (über GALSync) zwischen zwei Exchange-Organisationen zu synchronisieren. Die Benutzer in der einen Organisation werden in der anderen Organisation als fremde Benutzer/Kontakte angezeigt. Diese anderen lokalen Active Directory-Instanzen können dann mit ihren eigenen Azure AD-Mandanten synchronisiert werden.

Verwenden nicht autorisierter Clients für den Zugriff auf das Azure AD Connect-Back-End

Der Azure Active Directory Connect-Server kommuniziert mit Azure Active Directory über das Azure Active Directory Connect-Back-End. Die einzige Software, die für die Kommunikation mit diesem Back-End verwendet werden kann, ist Azure Active Directory Connect. Die Kommunikation mit dem Azure Active Directory Connect-Back-End unter Verwendung anderer Software oder Methoden wird nicht unterstützt.

Nächste Schritte

Weitere Informationen zum Installieren von Azure AD-Connect für diese Szenarios finden Sie unter Benutzerdefinierte Installation von Azure AD Connect.

Weitere Informationen zur Konfiguration der Azure AD Connect-Synchronisierung .

Erfahren Sie mehr zum Integrieren lokaler Identitäten in Azure Active Directory.