Szenarien der mandantenfähigen Benutzerverwaltung

Dieser Artikel ist der zweite in einer Reihe von Artikeln, die Leitfäden für die Konfiguration und Bereitstellung von Benutzerlebenszyklusverwaltung in mandantenfähigen Microsoft Entra-Umgebungen enthalten. In den folgenden Artikeln der Reihe finden Sie weitere Informationen wie beschrieben.

• Einführung in die mandantenfähige Benutzerverwaltung ist der erste in einer Reihe von Artikeln, die Leitfäden für die Konfiguration und Bereitstellung der Benutzerlebenszyklusverwaltung in mandantenfähigen Microsoft Entra-Umgebungen enthalten.
• Allgemeine Überlegungen zur mandantenfähigen Benutzerverwaltung enthält Leitfäden für diese Überlegungen: Mandantenübergreifende Synchronisierung, Verzeichnisobjekt, Microsoft Entra Bedingter Zugriff, zusätzliche Zugriffskontrolle und Office 365.
• Gemeinsame Lösungen für die mandantenübergreifende Benutzerverwaltung, wenn eine einzelne Mandantenfähigkeit für Ihr Szenario nicht ausreicht. Dieser Artikel bietet eine Anleitung für diese Herausforderungen: Automatische Benutzerlebenszyklusverwaltung und Ressourcenzuweisung über Mandanten hinweg, gemeinsame Nutzung von lokalen Anwendungen über Mandanten hinweg.

Diese Anleitung hilft Ihnen, eine konsistente Benutzerlebenszyklusverwaltung zu erreichen. Die Lebenszyklusverwaltung umfasst das mandantenübergreifende Bereitstellen, Verwalten und Aufheben der Bereitstellung von Benutzer*innen mithilfe der verfügbaren Azure-Tools, einschließlich Microsoft Entra B2B Collaboration (B2B) und die mandantenübergreifende Synchronisierung.

Dieser Artikel beschreibt drei Szenarien, für die Sie die Funktionen der mandantenfähigen Benutzerverwaltung nutzen können.

• Endbenutzerinitiiert
• Skript erstellt
• Automatisiert

Endbenutzerinitiiertes Szenario

In Szenarien, die vom Endbenutzer initiiert wurden, delegieren Ressourcenmandantenadministratoren bestimmte Funktionen an Benutzer im Mandanten. Administratoren ermöglichen es Endbenutzern, externe Benutzer in den Mandanten, eine App oder eine Ressource einzuladen. Sie können Benutzer aus dem Basismandanten einladen. Alternativ können sich diese einzeln registrieren.

Beispiel: Ein weltweit tätiges Dienstleistungsunternehmen arbeitet gemeinsam mit Subunternehmern an Projekten. Subunternehmer (externe Benutzer) benötigen Zugriff auf die Anwendungen und Dokumente des Unternehmens. Unternehmensadministratoren können Endbenutzer per Delegation befähigen, Subunternehmer einzuladen oder den Self-Service-Ressourcenzugriff für Subunternehmer zu konfigurieren.

Bereitstellen von Konten

Hier die häufigsten Methoden, mit denen Endbenutzer eingeladen werden können, auf Mandantenressourcen zuzugreifen.

• Anwendungsbasierte Einladungen: Microsoft-Anwendungen (z. B. Teams und SharePoint) können Einladungen externer Benutzer unterstützen. Konfigurieren Sie Einstellungen für B2B-Einladungen sowohl in Microsoft Entra B2B als auch in den relevanten Anwendungen.
• MyApps: Benutzer können mithilfe von MyApps externe Benutzer einladen und Anwendungen zuweisen. Das Benutzerkonto muss über Berechtigungen von genehmigenden Personen für Anwendungs-Self-Service-Registrierung verfügen. Gruppenbesitzer können externe Benutzer in ihre Gruppen einladen.
• Berechtigungsverwaltung: Ermöglicht es Administratoren oder Ressourcenbesitzern, Zugriffspakete mit Ressourcen, zulässigen externen Unternehmen, Ablauffristen für die Konten externer Benutzer und Zugriffsrichtlinien zu erstellen. Veröffentlichen Sie Zugriffspakete, um externen Benutzern die Self-Service-Registrierung für den Ressourcenzugriff zu ermöglichen.
• Azure-Portal: Endbenutzer*innen mit der Rolle Gasteinladender können sich beim Azure-Portal anmelden und über das Menü Benutzer in Microsoft Entra ID externe Benutzer*innen einladen.
• Programmgesteuert (PowerShell, Graph-API): Endbenutzer mit der Rolle Gasteinladender können externe Benutzer über PowerShell oder die Graph API einladen.

Einlösen von Einladungen

Wenn Sie Konten für den Zugriff auf eine Ressource bereitstellen, werden E-Mail-Einladungen an die E-Mail-Adresse des eingeladenen Benutzers gesendet.

Wenn ein eingeladener Benutzer eine Einladung erhält, kann er den in der E-Mail enthaltenen Link verwenden, um zur Einlösungs-URL zu gelangen. Dabei kann der eingeladene Benutzer die Einladung annehmen oder ablehnen und bei Bedarf ein Konto für einen externen Benutzer erstellen.

Eingeladene Benutzer können auch versuchen, direkt auf die Ressource zuzugreifen. Dies wird als JIT-Einlösung (Just-In-Time) bezeichnet und kann verwendet werden, wenn eines der folgenden Szenarien vorliegt.

• Der/die eingeladene Benutzer*in verfügt bereits über ein Microsoft Entra ID- oder ein Microsoft-Konto.
• Administratoren haben Einmal-Passcodes per E-Mail aktiviert.

Bei der JIT-Rücknahme können die folgenden Überlegungen zutreffen.

• Wenn Administratoren Zustimmungsaufforderungen nicht unterdrückt haben, muss der Benutzer zustimmen, bevor er auf die Ressource zugreift.
• Mithilfe einer eine Positivliste oder Sperrliste können Sie Einladungen für externe Benutzer aus bestimmten Unternehmen zulassen oder sperren.

Weitere Informationen finden Sie unter Microsoft Entra B2B Collaboration: Einlösen der Einladung.

Aktivieren der Authentifizierung mit Einmal-Passcode

In Szenarien, in denen Sie Ad-hoc-B2B zulassen, aktivieren Sie die Authentifizierung mit Einmal-Passcode per E-Mail. Durch diese Funktion werden externe Benutzer authentifiziert, die nicht mit anderen Methoden authentifiziert werden können, z. B.:

• Microsoft Entra ID.
• Microsoft-Konto:
• Gmail-Konto über Google-Verbund
• Konto von einem Security Assertion Markup Language (SAML)/WS-Fed IDP über Direct Federation.

Bei der Authentifizierung mit Einmalkennung ist es nicht erforderlich, ein Microsoft-Konto zu erstellen. Wenn der externe Benutzer eine Einladung einlöst oder auf eine freigegebene Ressource zugreift, wird an seine E-Mail-Adresse ein temporärer Code gesendet. Anschließend gibt er den Code ein, um die Anmeldung fortzusetzen.

Verwalten von Konten

Im endbenutzerinitiierten Szenario verwaltet der Ressourcenmandantenadministrator Konten für externe Benutzer im Ressourcenmandanten (der nicht basierend auf den aktualisierten Werten im Basismandanten aktualisiert wird). Die einzigen sichtbaren Attribute, die empfangen werden, sind die E-Mail-Adresse und der Anzeigename.

Sie können weitere Attribute für externe Benutzerobjekte konfigurieren, um verschiedene Szenarien (z. B. Berechtigungsszenarien) zu unterstützen. Sie können das Adressbuch mit Kontaktdaten auffüllen lassen. Beispielsweise kommen folgende Attribute infrage:

• HiddenFromAddressListsEnabled [ShowInAddressList]
• FirstName [GivenName]
• LastName [SurName]
• Titel
• Abteilung
• TelephoneNumber

Sie können diese Attribute festlegen, um externe Benutzer zur globalen Adressliste (GAL) und zur Personensuche (z. B. SharePoint-Personenauswahl) hinzuzufügen. Für andere Szenarien sind möglicherweise andere Attribute erforderlich (z. B. das Festlegen von Berechtigungen und Berechtigungen für Zugriffspakete, dynamische Gruppenmitgliedschaft und SAML-Ansprüche).

Eingeladene externe Benutzer werden standardmäßig aus der GAL ausgeblendet. Legen Sie fest, dass Attribute für externe Benutzer eingeblendet werden, damit sie in die vereinheitlichte GAL aufgenommen werden. Im Abschnitt Microsoft Exchange Online unter Allgemeine Überlegungen zur mandantenfähigen Benutzerverwaltung wird beschrieben, wie Sie die Beschränkungen verringern können, indem Sie externe Mitgliedsbenutzer anstelle von externen Gastbenutzern erstellen.

Aufheben der Bereitstellung von Konten

In endbenutzerinitiierten Szenarien werden Entscheidungen über Zugriffsberechtigungen dezentralisiert. Dadurch wird es schwieriger zu entscheiden, wann ein externer Benutzer und dessen Zugriff entfernt werden sollten. Mit der Berechtigungsverwaltung und Zugriffsüberprüfungen können Sie vorhandene externe Benutzer und deren Ressourcenzugriff überprüfen und entfernen.

Wenn Sie Benutzer außerhalb der Berechtigungsverwaltung einladen, müssen Sie einen separaten Prozess erstellen, um deren Zugriff zu überprüfen und zu verwalten. Wenn Sie z. B. einen externen Benutzer direkt über SharePoint in Microsoft 365 einladen, gehört er nicht zu Ihrem Prozess der Berechtigungsverwaltung.

Skriptszenario

Im skriptbasierten Szenario stellen Ressourcenmandantenadministratoren einen Skriptpullprozess bereit, um die Ermittlung und Bereitstellung externer Benutzer zu automatisieren.

Beispiel: Ein Wettbewerber wird von einem Unternehmen übernommen. Jedes Unternehmen verfügt über einen einzelnen Microsoft Entra-Mandanten. Die folgenden Szenarien sollen an Tag 1 funktionieren, ohne dass Benutzer Schritte zum Einladen oder Einlösen ausführen müssen. Alle Benutzer müssen zu Folgendem in der Lage sein:

• Einmaliges Anmelden für alle bereitgestellten Ressourcen verwenden
• Gegenseitige Suchen und Ressourcensuchen in einer vereinheitlichten GAL ausführen
• Gegenseitige Anwesenheit ermitteln und Chats initiieren
• Zugreifen auf Anwendungen basierend auf dynamischer Gruppenmitgliedschaft

In diesem Szenario ist der Mandant jedes Unternehmens der Basismandant für seine vorhandenen Mitarbeiter und der Ressourcenmandant für die Mitarbeiter der anderen Unternehmen.

Bereitstellen von Konten

Mit Delta Query können Mandantenadministratoren einen Skriptpullprozess bereitstellen, um die Ermittlung und Bereitstellung von Identitäten zur Unterstützung des Ressourcenzugriffs zu automatisieren. Bei diesem Prozess wird der Basismandant auf neue Benutzer überprüft. Es verwendet die B2B Graph APIs, um neue Benutzer als externe Benutzer im Ressourcenmandanten bereitzustellen, wie im folgenden mandantenfähigen Topologiediagramm dargestellt.

Diagrammtitel: Diagramm der mandantenfähigen Topologie. Das Feld „Company A“ (Unternehmen A) auf der linken Seite enthält interne und externe Benutzer. Das Feld „Company B“ (Unternehmen B) auf der rechten Seite enthält interne und externe Benutzer. Unternehmen A interagiert mit Unternehmen B. Dabei sollen Benutzer von A skriptbasiert nach B gepullt werden. Außerdem interagiert Unternehmen B mit Unternehmen A. Dabei sollen Benutzer skriptbasiert von B nach A gepullt werden.

• Mandantenadministratoren bestimmen Anmeldeinformationen und Zustimmungen vorab, damit jeder Mandant Leseberechtigungen erhält.
• Mandantenadministratoren automatisieren das Aufzählen und das Pullen bereichsbezogener Benutzer in den Ressourcenmandanten.
• Verwenden Sie die Microsoft Graph-API mit genehmigten Berechtigungen zum Lesen und Bereitstellen von Benutzern über die Einladungs-API.
• Bei der ersten Bereitstellung können Quellattribute gelesen und auf das Zielbenutzerobjekt angewendet werden.

Verwalten von Konten

Die Ressourcenorganisation kann die Profildaten erweitern, um Freigabeszenarien zu unterstützen, indem die Metadatenattribute des Benutzers im Ressourcenmandanten aktualisiert werden. Wenn jedoch eine fortlaufende Synchronisierung erforderlich ist, ist eine synchronisierte Lösung möglicherweise eine bessere Option.

Aufheben der Bereitstellung von Konten

Delta Query kann signalisieren, wann die Bereitstellung eines externen Benutzers aufgehoben werden muss. Die Berechtigungsverwaltung und Zugriffsüberprüfungen können eine Möglichkeit bieten, vorhandene externe Benutzer und deren Zugriff auf Ressourcen zu überprüfen und zu entfernen.

Wenn Sie Benutzer außerhalb der Berechtigungsverwaltung einladen, erstellen Sie einen separaten Prozess, um den Zugriff externer Benutzer zu überprüfen und zu verwalten. Wenn Sie den externen Benutzer beispielsweise direkt über SharePoint in Microsoft 365 einladen, gehört er nicht zu Ihrem Prozess der Berechtigungsverwaltung.

Automatisiertes Szenario

Die mandantenübergreifende synchronisierte Freigabe ist das komplexeste der in diesem Artikel beschriebenen Muster. Dieses Muster unterstützt mehr Optionen für die automatisierte Verwaltung und Aufhebung der Bereitstellung als endbenutzerinitiierte oder skriptbasierte Optionen.

In automatisierten Szenarien verwenden Ressourcenmandantenadministratoren ein Identitätsbereitstellungssystem, um die Prozesse für die Bereitstellung und Aufhebung der Bereitstellung zu automatisieren. In Szenarien innerhalb der kommerziellen Cloudinstanz von Microsoft kann eine mandantenübergreifende Synchronisierung genutzt werden. In Szenarien, die Sovereign Cloud-Instanzen von Microsoft umfassen, benötigen Sie eine andere Herangehensweise, da die mandantenübergreifende Synchronisierung noch nicht cloudübergreifend unterstützt wird.

Ein Beispiel: Ein multinationaler/regionaler Konzern hat innerhalb einer Microsoft Commercial-Cloudinstanz mehrere Tochtergesellschaften mit den folgenden Anforderungen.

• Jede verfügt über einen eigenen Microsoft Entra-Mandanten und muss mit den anderen zusammenarbeiten.
• Zusätzlich zur Synchronisierung neuer Benutzer unter den Mandanten werden Attributupdates automatisch synchronisiert und die Aufhebung der Bereitstellung automatisiert.
• Wenn ein Mitarbeiter einer Niederlassung nicht mehr angehört, sollten Sie sein Konto während der nächsten Synchronisierung aus allen anderen Mandanten entfernen.

In einem erweiterten, cloudübergreifenden Szenario verfügt ein DIB-Auftragnehmer (Defense Industrial Base) über eine Niederlassung im Verteidigungsbereich und eine im kommerziellen Bereich. Diese haben konkurrierende Regulierungsanforderungen:

• Das US-Unternehmen im Verteidigungsbereich befindet sich in einem US Sovereign Cloud-Mandanten wie Microsoft 365 US Government GCC High und Azure Government.
• Das Unternehmen im kommerziellen Bereich befindet sich in einem separaten Microsoft Entra-Mandanten in einer kommerziellen Instanz, z. B. in einer Microsoft Entra-Umgebung, die in der globalen Azure-Cloud ausgeführt wird.

Um wie ein einziges Unternehmen zu agieren, das in einer cloudübergreifenden Architektur bereitgestellt wird, werden Benutzer mit beiden Mandanten synchronisiert. Dieser Ansatz ermöglicht eine einheitliche GAL-Verfügbarkeit in beiden Mandanten und kann sicherstellen, dass Benutzer, die automatisch mit beiden Mandanten synchronisiert werden, Berechtigungen und Einschränkungen für Anwendungen und Inhalte erhalten. Die Anforderungen umfassen beispielsweise:

• US-Angestellte haben möglicherweise allgegenwärtigen Zugang zu beiden Mandanten.
• Mitarbeiter außerhalb der USA werden in der vereinheitlichen GAL beider Mandanten angezeigt, haben aber keinen Zugriff auf geschützte Inhalte im GCC High-Mandanten.

Dieses Szenario erfordert die automatische Synchronisierung und Identitätsverwaltung, um Benutzer in beiden Mandanten zu konfigurieren, während sie den richtigen Berechtigungs- und Datenschutzrichtlinien zugeordnet werden.

Cloudübergreifendes B2B erfordert, dass Sie mandantenübergreifende Zugriffseinstellungen für jedes Unternehmen konfigurieren, mit dem Sie in der Remotecloudinstanz zusammenarbeiten möchten.

Bereitstellen von Konten

In diesem Abschnitt werden drei Verfahren zum Automatisieren der Kontobereitstellung im automatisierten Szenario beschrieben.

Verfahren 1: Verwenden der integrierten mandantenübergreifenden Synchronisierungsfunktion in Microsoft Entra ID

Dieser Ansatz funktioniert nur, wenn sich alle Mandanten, die Sie synchronisieren müssen, in derselben Cloudinstanz befinden (z. B. „Kommerziell-zu-Kommerziell“).

Verfahren 2: Bereitstellen von Konten mit Microsoft Identity Manager

Verwenden Sie eine externe IAM-Lösung (Identity & Access Management) wie Microsoft Identity Manager (MIM) als Synchronisierungsmodul.

Diese erweiterte Bereitstellung nutzt MIM als Synchronisierungsmodul. MIM ruft die Microsoft Graph-API und Exchange Online PowerShell auf. Alternative Implementierungen können der cloudgehostete Active Directory-Synchronisierungsdienst (ADSS) sein. Dabei handelt es sich um ein Angebot eines verwalteten Diensts aus den Branchenlösungen von Microsoft. Es gibt Angebote, die nicht von Microsoft stammen und die Sie mit anderen IAM-Angeboten (wie SailPoint, Omada und OKTA) von Grund auf neu erstellen können.

Sie führen eine Cloud-zu-Cloud-Synchronisierung von Identitäten (Benutzer, Kontakte und Gruppen) von einem Mandanten zu einem anderen durch, wie im folgenden Diagramm dargestellt.

Diagrammtitel: Cloud-zu-Cloud-Synchronisierung von Identitäten Das Feld „Company A“ (Unternehmen A) auf der linken Seite enthält interne und externe Benutzer. Das Feld „Company B“ (Unternehmen B) auf der rechten Seite enthält interne und externe Benutzer. Zwischen Unternehmen A und Unternehmen B verlaufen die Interaktionen des Synchronisierungsmoduls von Unternehmen A nach Unternehmen B und von Unternehmen B nach Unternehmen A.

Themen wie die Integration lokaler Anwendungen gehen über den Rahmen dieses Artikels hinaus.

Verfahren 3: Bereitstellen von Konten mit Microsoft Entra Connect

Dieses Verfahren bezieht sich nur auf komplexe Unternehmen, die alle Identitäten in herkömmlichen Windows Server-basierten Active Directory Domain Services (AD DS) verwalten. Bei diesem Ansatz wird Microsoft Entra Connect als Synchronisierungsmodul verwendet, wie im folgenden Diagramm veranschaulicht.

Diagrammtitel: Bereitstellen von Konten mit Microsoft Entra Connect Das Diagramm zeigt vier Hauptkomponenten. Ein Feld auf der linken Seite stellt den Kunden dar. Die Darstellung einer Wolke auf der rechten Seite stellt die B2B-Konvertierung dar. Oben in der Mitte befindet sich ein Feld mit einer Wolke, die die kommerzielle Cloud von Microsoft darstellt. Unten in der Mitte befindet sich ein Feld mit einer Wolke, die die Microsoft Sovereign Cloud für US-Regierungsbehörden darstellt. Im Feld „Customer“ (Kunde) wird ein Windows Server Active Directory-Symbol mit zwei Feldern mit der Bezeichnung „Microsoft Entra Connect“ verbunden. Die Verbindungen werden durch gestrichelte rote Linien mit Pfeilen an beiden Enden und einem etwa mittigen Aktualisierungssymbol dargestellt. In der Wolke „Microsoft Commercial Cloud“ (kommerzielle Cloud von Microsoft) befindet sich eine weitere Wolke, die die kommerzielle Version von Microsoft Azure darstellt. Darin befindet sich eine weitere Wolke, die Microsoft Entra ID darstellt. Rechts von der Form der Microsoft Azure Commercial Cloud befindet sich ein Kästchen, das Office 365 mit der Bezeichnung Public Multitenant darstellt. Eine durchgezogene rote Linie mit Pfeilen an beiden Enden verbindet das Feld „Office 365“ mit der kommerziellen Microsoft Azure-Cloud und ist mit „Hybrid Workloads“ (Hybridworkloads) beschriftet. Zwei gestrichelte Linien verbinden das Feld „Office 365“ mit dem Wolkensymbol für Microsoft Entra. Eine Linie verfügt über einen Pfeil am Ende, der eine Verbindung mit Microsoft Entra ID herstellt. Die andere Linie hat Pfeile an beiden Enden. Eine gestrichelte Linie mit Pfeilen an beiden Enden verbindet das Wolkensymbol für Microsoft Entra mit dem oberen Feld für Microsoft Entra Connect im Feld „Customer“ (Kunde). Eine gestrichelte Linie mit Pfeilen an beiden Enden verbindet das Symbol für die kommerzielle Microsoft-Cloud mit dem Wolkensymbol für die B2B-Konvertierung. Im Feld für die Microsoft Sovereign Cloud für US-Regierungsbehörden befindet sich ein weiteres Wolkensymbol, das Microsoft Azure Government darstellt. Darin befindet sich eine weitere Wolke, die Microsoft Entra ID darstellt. Rechts neben der kommerziellen Cloud von Microsoft Azure befindet sich ein Feld, das Office 365 darstellt und mit „US Gov GCC-High L4“ beschriftet ist. Eine durchgezogene rote Linie mit Pfeilen an beiden Enden verbindet das Feld „Office 365“ mit der Microsoft Azure Government-Cloud und ist mit „Hybrid Workloads“ (Hybridworkloads) beschriftet. Zwei gestrichelte Linien verbinden das Feld „Office 365“ mit dem Wolkensymbol für Microsoft Entra. Eine Linie verfügt über einen Pfeil am Ende, der eine Verbindung mit Microsoft Entra ID herstellt. Die andere Linie hat Pfeile an beiden Enden. Eine gestrichelte Linie mit Pfeilen an beiden Enden verbindet das Wolkensymbol für Microsoft Entra mit dem unteren Feld für Microsoft Entra Connect im Feld „Customer“ (Kunde). Eine gestrichelte Linie mit Pfeilen an beiden Enden verbindet das Symbol für die kommerzielle Microsoft-Cloud mit dem Wolkensymbol für die B2B-Konvertierung.

Anders als beim MIM-Verfahren stammen alle Identitätsquellen (Benutzer, Kontakte und Gruppen) aus herkömmlichen Windows Server-basierten Active Directory Domain Services (AD DS). Das AD DS-Verzeichnis ist in der Regel eine lokale Bereitstellung für ein komplexes Unternehmen, von dem Identitäten für mehrere Mandanten verwaltet werden. Dieses Verfahren sieht keine reine Cloudidentität vor. Alle Identitäten müssen in AD DS enthalten sein, damit sie in die Synchronisierung einbezogen werden können.

Bei diesem Verfahren wird ein Benutzer als internes Mitglied in einen Basismandanten synchronisiert (Standardverhalten). Alternativ kann ein Benutzer auch als externer Benutzer in einen Ressourcenmandanten synchronisiert werden (angepasstes Verhalten).

Microsoft unterstützt dieses Verfahren der doppelten Benutzersynchronisierung, wobei sorgfältig zu prüfen ist, welche Änderungen in der Microsoft Entra Connect-Konfiguration vorgenommen werden. Wenn Sie beispielsweise Änderungen an der assistentengestützten Einrichtung vornehmen, müssen Sie die Änderungen dokumentieren, wenn Sie die Konfiguration während eines Supportvorfalls neu erstellen müssen.

Microsoft Entra Connect ist standardmäßig nicht in der Lage, externe Benutzer*innen zu synchronisieren. Sie müssen eine externe Lösung (z. B. ein PowerShell-Skript) hinzuziehen, um Konten von internen Benutzern in Konten von externen Benutzern zu konvertieren.

Dieses Verfahren bietet den Vorteil, dass Microsoft Entra Connect die Identität mit den in AD DS gespeicherten Attributen synchronisiert. Die Synchronisierung kann Adressbuchattribute, Managerattribute, Gruppenmitgliedschaften und andere hybride Identitätsattribute in allen Mandanten innerhalb des Bereichs umfassen. Die Bereitstellung von Identitäten wird in Übereinstimmung mit AD DS aufgehoben. Es ist keine komplexere IAM-Lösung erforderlich, um die Cloudidentität für diese spezifische Aufgabe zu verwalten.

Pro Mandant besteht eine 1:1-Beziehung mit Microsoft Entra Connect. Jeder Mandant hat seine eigene Konfiguration von Microsoft Entra Connect, die Sie individuell ändern können, um die Synchronisierung von Mitglieder- oder externen Benutzerkonten zu unterstützen.

Wahl der richtigen Topologie

Die meisten Kunden verwenden in automatisierten Szenarien eine der folgenden Topologien.

• Eine Maschentopologie ermöglicht die gemeinsame Nutzung aller Ressourcen in allen Mandanten. Sie erstellen Benutzer aus anderen Mandanten in jedem Ressourcenmandanten als externe Benutzer.
• In einer Topologie mit einem einzelnen Ressourcenmandanten wird ein einzelner Mandant (der Ressourcenmandant) verwendet, in dem Benutzer anderer Mandanten externe Benutzer sind.

Nutzen Sie beim Entwurf Ihrer Lösung die folgende Tabelle als Entscheidungsstruktur. Im Anschluss an die Tabelle werden beide Topologien anhand von Diagrammen veranschaulicht, um zu ermitteln, welche für Ihr Unternehmen geeignet ist.

Vergleich von Maschen- und Einzel-Ressourcenmandanten-Topologien

Aspekt	Maschentopologie	Einzelner Ressourcenmandant
Jedes Unternehmen verfügt über einen separaten Microsoft Entra -Mandanten mit Benutzer*innen und Ressourcen	Ja	Ja
Ressourcenstandort und Zusammenarbeit
Freigegebene Apps und andere Ressourcen verbleiben im aktuellen Home-Mandanten.	Ja	Nein. Sie können nur Apps und andere Ressourcen im Ressourcenmandanten freigeben. Apps und andere Ressourcen, die in anderen Mandanten enthalten sind, können nicht freigegeben werden.
Alle GALs, die in einzelnen Unternehmen angezeigt werden können (vereinheitlichte GALs)	Ja	Nein
Ressourcenzugriff und -verwaltung
ALLE Anwendungen, die mit Microsoft Entra ID verbunden sind, können von allen Unternehmen gemeinsam genutzt werden.	Ja	Nein. Nur Anwendungen im Ressourcenmandanten werden freigegeben. Anwendungen in anderen Mandanten können nicht freigegeben werden.
Globale Ressourcenverwaltung	Wird auf Mandantenebene fortgesetzt	Konsolidiert im Ressourcenmandanten
Lizenzierung: Office 365 SharePoint in Microsoft 365, einheitliches GAL, Teams-Zugang unterstützen alle Gäste, andere Exchange Online-Szenarien jedoch nicht.	Wird auf Mandantenebene fortgesetzt	Wird auf Mandantenebene fortgesetzt
Lizenzierung: Microsoft Entra ID (Premium)	Die ersten 50.000 aktiven Benutzer pro Monat sind kostenlos (pro Mandant).	Die ersten 50.000 aktiven Benutzer pro Monat sind kostenlos.
Lizenzierung: Software-as-a-Service (SaaS) Anwendungen	Bleiben Sie in einzelnen Mandanten, benötigen Sie möglicherweise Lizenzen pro Benutzer und Mandant.	Alle freigegebenen Ressourcen befinden sich im einzelnen Ressourcenmandanten. Sie können ggf. die Konsolidierung von Lizenzen für den einzelnen Mandanten untersuchen.

Maschentopologie

Im folgenden Diagramm wird die Meshtopologie veranschaulicht.

Diagrammtitel: Meshtopologie. Das Feld „Company A“ (Unternehmen A) oben links enthält interne und externe Benutzer. Das Feld „Company B“ (Unternehmen B) oben rechts enthält interne und externe Benutzer. Das Feld „Company C“ (Unternehmen C) unten links enthält interne und externe Benutzer. Das Feld „Company D“ (Unternehmen D) unten rechts enthält interne und externe Benutzer. Zwischen Unternehmen A und Unternehmen B sowie zwischen Unternehmen C und Unternehmen D verlaufen die Interaktionen des Synchronisierungsmoduls zwischen den Unternehmen auf der linken Seite und den Unternehmen auf der rechten Seite.

In einer Meshtopologie wird jeder Benutzer in jedem Basismandanten mit jedem anderen Mandanten synchronisiert, der zu einem Ressourcenmandanten wird.

• Sie können jede Ressource innerhalb eines Mandanten für externe Benutzer freigeben.
• Alle Benutzer sind für jedes Unternehmen im Konglomerat sichtbar. Im obigen Diagramm gibt es vier vereinheitlichte GALs, von denen jede die Basisbenutzer und externen Benutzer der anderen drei Mandanten enthält.

Gemeinsame Überlegungen zur mandantenfähigen Benutzerverwaltung bieten Informationen zur Bereitstellung, Verwaltung und Deprovisionierung von Benutzern in diesem Szenario.

Cloudübergreifende Meshtopologie

Die Meshtopologie kann in nur zwei Mandanten verwendet werden, z. B. im Szenario für einen DIB-Verteidigungsauftragsnehmer, der sich an einer übergreifenden Sovereign Cloud-Lösung beteiligt. Wie bei der Meshtopologie wird jeder Benutzer in jedem Basismandanten mit dem anderen Mandanten synchronisiert, der zu einem Ressourcenmandanten wird. Im Diagramm zum Abschnitt Verfahren 3 wird der interne Benutzer des öffentlichen kommerziellen Mandanten mit dem Sovereign US GCC High-Mandanten als Konto für einen externen Benutzer synchronisiert. Gleichzeitig wird der interne GCC High-Benutzer mit der kommerziellen Instanz als Konto für einen externen Benutzer synchronisiert.

Im Diagramm werden auch Standorte für Datenspeicher dargestellt. Die Kategorisierung und Compliance von Daten liegt nicht im Rahmen dieses Artikels. Allerdings können Sie Berechtigungen und Einschränkungen für Anwendungen und Inhalte einschließen. Zu den Inhalten können auch Speicherorte gehören, an denen sich die Daten von internen Benutzenden befinden (z. B. Daten, die in einem Exchange Online-Postfach oder OneDrive gespeichert sind). Der Inhalt befindet sich möglicherweise in ihrem Hauptmandanten und nicht im Ressourcenmandanten. Freigegebene Daten können sich in beiden Mandanten befinden. Sie können den Zugriff auf den Inhalt durch Richtlinien für die Zugriffssteuerung und für bedingten Zugriff einschränken.

Topologie eines einzelnen Ressourcenmandanten

Das folgende Diagramm veranschaulicht eine Mandantentopologie mit einer einzelnen Ressource.

Diagrammtitel: Mandantentopologie mit einer einzelnen Ressource Das obere Feld, das „Company A“ (Unternehmen A) darstellt, enthält drei Felder. Das Feld links enthält alle freigegebenen Ressourcen. Das Feld in der Mitte enthält interne Benutzer. Das Feld rechts enthält externe Benutzer. Unter dem Feld „Company A“ (Unternehmen A) befindet sich ein Feld, das das Synchronisierungsmodul darstellt. Das Synchronisierungsmodul wird durch drei Pfeile mit „Company A“ (Unternehmen A) verbunden. Unterhalb des Felds mit dem Synchronisierungsmodul unten im Diagramm befinden sich drei Felder, die „Company B“ (Unternehmen B), „Company C“ (Unternehmen C) und „Company D“ (Unternehmen D) darstellen. Von jedem Unternehmen führt ein Pfeil zum Feld des Synchronisierungsmoduls. In jedem der unteren Felder für die Unternehmen befinden sich Bezeichnungen für Microsoft Graph-API, Exchange Online und PowerShell sowie Symbole, die interne Benutzer darstellen.

In einer Mandantentopologie mit einer einzelnen Ressource werden Benutzer und ihre Attribute mit dem Ressourcenmandanten synchronisiert („Company A“ im Diagramm oben).

• Alle Ressourcen, die von den Mitgliedsorganisationen gemeinsam genutzt werden, müssen sich im einzelnen Ressourcenmandanten befinden. Wenn mehrere Niederlassungen über Abonnements für dieselben SaaS-Apps verfügen, kann dies eine Gelegenheit sein, diese Abonnements zu konsolidieren.
• Nur die GAL im Ressourcenmandanten zeigt Benutzer aus allen Unternehmen an.

Verwalten von Konten

Diese Lösung erkennt Attributänderungen von Benutzern von Quellmandanten und synchronisiert sie mit externen Benutzern des Ressourcenmandanten. Sie können diese Attribute verwenden, um Autorisierungsentscheidungen zu treffen (z. B. wenn Sie dynamische Mitgliedergruppen verwenden).

Aufheben der Bereitstellung von Konten

Die Automatisierung erkennt, wenn ein Objekt in der Quellumgebung gelöscht wird, und löscht das zugeordnete Objekt des externen Benutzers in der Zielumgebung.

Allgemeine Überlegungen zur mandantenfähigen Benutzerverwaltung bieten zusätzliche Informationen zur Bereitstellung, Verwaltung und Deprovisionierung von Benutzern in diesem Szenario.

Nächste Schritte

• Einführung in die mandantenfähige Benutzerverwaltung ist der erste in einer Reihe von Artikeln, die Leitfäden für die Konfiguration und Bereitstellung der Benutzerlebenszyklusverwaltung in mandantenfähigen Microsoft Entra-Umgebungen enthalten.
• Allgemeine Überlegungen zur mandantenfähigen Benutzerverwaltung enthält Leitfäden für diese Überlegungen: Mandantenübergreifende Synchronisierung, Verzeichnisobjekt, Microsoft Entra Bedingter Zugriff, zusätzliche Zugriffskontrolle und Office 365.
• Gemeinsame Lösungen für die mandantenübergreifende Benutzerverwaltung, wenn eine einzelne Mandantenfähigkeit für Ihr Szenario nicht ausreicht. Dieser Artikel bietet einen Leitfaden für diese Herausforderungen: Automatische Benutzerlebenszyklusverwaltung und Ressourcenzuweisung über Mandanten hinweg, gemeinsame Nutzung von lokalen Anwendungen über Mandanten hinweg.