Delen via


Scenario's voor multitenant-gebruikersbeheer

Dit artikel is de tweede in een reeks artikelen die richtlijnen bieden voor het configureren en bieden van levenscyclusbeheer van gebruikers in Microsoft Entra-omgevingen met meerdere tenants. De volgende artikelen in de reeks bevatten meer informatie zoals beschreven.

  • Inleiding tot multitenant-gebruikersbeheer is de eerste in de reeks artikelen die richtlijnen bieden voor het configureren en bieden van levenscyclusbeheer van gebruikers in Microsoft Entra-omgevingen met meerdere tenants.
  • Algemene overwegingen voor multitenant-gebruikersbeheer bieden richtlijnen voor deze overwegingen: synchronisatie tussen tenants, adreslijstobject, voorwaardelijke toegang van Microsoft Entra, extra toegangsbeheer en Office 365.
  • Algemene oplossingen voor multitenant-gebruikersbeheer wanneer één tenancy niet werkt voor uw scenario, biedt dit artikel richtlijnen voor deze uitdagingen: automatisch levenscyclusbeheer van gebruikers en resourcetoewijzing voor tenants, on-premises apps delen tussen tenants.

De richtlijnen helpen u bij het realiseren van een consistente status van levenscyclusbeheer van gebruikers. Levenscyclusbeheer omvat het inrichten, beheren en ongedaan maken van de inrichting van gebruikers in tenants met behulp van de beschikbare Azure-hulpprogramma's die Microsoft Entra B2B-samenwerking (B2B) en synchronisatie tussen tenants omvatten.

In dit artikel worden drie scenario's beschreven waarvoor u functies voor multitenant gebruikersbeheer kunt gebruiken.

  • Door de eindgebruiker geïnitieerd
  • Gescript
  • Geautomatiseerd

Scenario dat door de eindgebruiker is geïnitieerd

In door de eindgebruiker geïnitieerde scenario's delegeren resourcetenantbeheerders bepaalde mogelijkheden aan gebruikers in de tenant. Beheerders stellen eindgebruikers in staat externe gebruikers uit te nodigen voor de tenant, een app of een resource. U kunt gebruikers uitnodigen vanuit de thuistenant of ze kunnen zich afzonderlijk registreren.

Een wereldwijd professioneel dienstverlener werkt bijvoorbeeld samen met onderaannemers aan projecten. Onderaannemers (externe gebruikers) hebben toegang nodig tot de toepassingen en documenten van het bedrijf. Vaste beheerders kunnen de eindgebruikers de mogelijkheid geven om onderaannemers uit te nodigen of selfservice te configureren voor toegang tot onderaannemers.

Accounts inrichten

Hier volgen de meestgebruikte manieren om eindgebruikers uit te nodigen voor toegang tot tenantbronnen.

  • Uitnodigingen op basis van toepassingen. Microsoft-toepassingen (zoals Teams en SharePoint) kunnen uitnodigingen voor externe gebruikers inschakelen. Configureer B2B-uitnodigingsinstellingen in zowel Microsoft Entra B2B als in de relevante toepassingen.
  • MyApps. Gebruikers kunnen externe gebruikers uitnodigen en toewijzen aan toepassingen met Behulp van MyApps. Het gebruikersaccount moet selfservicemachtigingen hebben voor het registreren van fiatteurs voor toepassingen. Groepseigenaren kunnen externe gebruikers uitnodigen voor hun groepen.
  • Rechtenbeheer. Beheerders of resource-eigenaren in staat stellen toegangspakketten te maken met resources, toegestane externe organisaties, verlooptijd van externe gebruikers en toegangsbeleid. Publiceer toegangspakketten om selfserviceregistratie van externe gebruikers in te schakelen voor toegang tot resources.
  • Azure Portal. Eindgebruikers met de rol Gastuitnodiging kunnen zich aanmelden bij Azure Portal en externe gebruikers uitnodigen via het menu Gebruikers in Microsoft Entra ID.
  • Programmatisch (PowerShell, Graph API). Eindgebruikers met de rol Gastnodiger kunnen PowerShell of Graph API gebruiken om externe gebruikers uit te nodigen.

Uitnodigingen inwisselen

Wanneer u accounts inricht voor toegang tot een resource, gaan e-mailuitnodigingen naar het e-mailadres van de uitgenodigde gebruiker.

Wanneer een uitgenodigde gebruiker een uitnodiging ontvangt, kan deze de koppeling in het e-mailbericht volgen naar de inwisselings-URL. Als u dit doet, kan de uitgenodigde gebruiker de uitnodiging goedkeuren of weigeren en, indien nodig, een extern gebruikersaccount maken.

Uitgenodigde gebruikers kunnen ook proberen rechtstreeks toegang te krijgen tot de resource, aangeduid als Just-In-Time (JIT) inwisselen als een van de volgende scenario's waar is.

  • De uitgenodigde gebruiker heeft al een Microsoft Entra-id of Microsoft-account, of
  • Beheerders hebben eenmalige wachtwoordcodes voor e-mail ingeschakeld.

Tijdens het inwisselen van JIT kunnen de volgende overwegingen van toepassing zijn.

  • Als beheerders geen toestemmingsprompts hebben onderdrukt, moet de gebruiker toestemming geven voordat hij toegang verleent tot de resource.
  • U kunt uitnodigingen voor externe gebruikers van specifieke organisaties toestaan of blokkeren met behulp van een acceptatielijst of een bloklijst.

Zie Voor meer informatie microsoft Entra B2B samenwerking uitnodiging inwisselen.

Eenmalige wachtwoordcodeverificatie inschakelen

In scenario's waarin u ad-hoc B2B toestaat, schakelt u eenmalige wachtwoordcodeverificatie voor e-mail in. Met deze functie worden externe gebruikers geverifieerd wanneer u ze niet via andere manieren kunt verifiëren, zoals:

  • Microsoft Entra-id.
  • Microsoft-account.
  • Gmail-account via Google Federation.
  • Account van een Security Assertion Markup Language (SAML)/WS-Fed IDP via directe federatie.

Met eenmalige wachtwoordcodeverificatie hoeft u geen Microsoft-account te maken. Wanneer de externe gebruiker een uitnodiging inwisselt of een gedeelde resource opent, ontvangt deze een tijdelijke code op het e-mailadres. Vervolgens voeren ze de code in om door te gaan met aanmelden.

Accounts beheren

In het scenario dat door de eindgebruiker is geïnitieerd, beheert de beheerder van de resourcetenant externe gebruikersaccounts in de resourcetenant (niet bijgewerkt op basis van de bijgewerkte waarden in de basistenant). De enige zichtbare kenmerken die zijn ontvangen, bevatten het e-mailadres en de weergavenaam.

U kunt meer kenmerken voor externe gebruikersobjecten configureren om verschillende scenario's (zoals rechtenscenario's) te vergemakkelijken. U kunt het adresboek invullen met contactgegevens. Denk bijvoorbeeld aan de volgende kenmerken.

  • HiddenFromAddressListsEnabled [ShowInAddressList]
  • FirstName [GivenName]
  • Achternaam [SurName]
  • Titel
  • Departement
  • TelephoneNumber

U kunt deze kenmerken instellen om externe gebruikers toe te voegen aan de algemene adreslijst (GAL) en om personen te zoeken (zoals SharePoint People Picker). Voor andere scenario's zijn mogelijk verschillende kenmerken vereist (zoals het instellen van rechten en machtigingen voor toegangspakketten, dynamisch groepslidmaatschap en SAML-claims).

Standaard verbergt de GAL uitgenodigde externe gebruikers. Stel in dat externe gebruikerskenmerken zichtbaar moeten worden gemaakt om ze op te nemen in de geïntegreerde GAL. In de sectie Microsoft Exchange Online van Algemene overwegingen voor multitenant-gebruikersbeheer wordt beschreven hoe u limieten kunt verminderen door externe lidgebruikers te maken in plaats van externe gastgebruikers.

Accounts ongedaan maken

Door eindgebruikers geïnitieerde scenario's decentraliseren toegangsbeslissingen, waardoor het lastig kan zijn om te bepalen wanneer een externe gebruiker en de bijbehorende toegang moeten worden verwijderd. Met rechtenbeheer en toegangsbeoordelingen kunt u bestaande externe gebruikers en hun resourcetoegang controleren en verwijderen.

Wanneer u gebruikers buiten rechtenbeheer uitnodigt, moet u een afzonderlijk proces maken om hun toegang te controleren en te beheren. Als u bijvoorbeeld rechtstreeks een externe gebruiker uitnodigt via SharePoint in Microsoft 365, bevindt dit zich niet in uw rechtenbeheerproces.

Scriptscenario

In het scenario met scripts implementeren resourcetenantbeheerders een pull-proces met scripts om detectie en inrichting van externe gebruikers te automatiseren.

Een bedrijf verwerft bijvoorbeeld een concurrent. Elk bedrijf heeft één Microsoft Entra-tenant. Ze willen dat de volgende scenario's van Day One werken zonder dat gebruikers een uitnodiging of inwisselingsstappen hoeven uit te voeren. Alle gebruikers moeten het volgende kunnen doen:

  • Gebruik eenmalige aanmelding voor alle ingerichte resources.
  • Zoek elkaar en resources in een geïntegreerde GAL.
  • Bepaal elkaars aanwezigheid en initieer chat.
  • Toegang tot toepassingen op basis van dynamisch groepslidmaatschap.

In dit scenario is de tenant van elke organisatie de basistenant voor de bestaande werknemers, terwijl deze de resourcetenant is voor de werknemers van de andere organisatie.

Accounts inrichten

Met Delta Query kunnen tenantbeheerders een scripted pull-proces implementeren om detectie en identiteitsinrichting te automatiseren om toegang tot resources te ondersteunen. Met dit proces wordt de thuistenant gecontroleerd op nieuwe gebruikers. Hierbij worden de B2B Graph-API's gebruikt om nieuwe gebruikers in te richten als externe gebruikers in de resourcetenant, zoals wordt geïllustreerd in het volgende multitenant-topologiediagram.

Diagram illustreert het gebruik van B2B Graph-API's voor het inrichten van nieuwe gebruikers als externe gebruikers in de resourcetenant.

  • Tenantbeheerders rangschikken referenties en toestemming om elke tenant te laten lezen.
  • Tenantbeheerders automatiseren inventarisatie en het ophalen van gebruikers binnen het bereik van de resourcetenant.
  • Gebruik Microsoft Graph API met toestemmingsmachtigingen om gebruikers te lezen en in te richten met de uitnodigings-API.
  • Initiële inrichting kan bronkenmerken lezen en toepassen op het doelgebruikersobject.

Accounts beheren

De resourceorganisatie kan profielgegevens uitbreiden ter ondersteuning van scenario's voor delen door de metagegevenskenmerken van de gebruiker in de resourcetenant bij te werken. Als doorlopende synchronisatie echter nodig is, is een gesynchroniseerde oplossing mogelijk een betere optie.

Accounts ongedaan maken

Delta Query kan signaleren wanneer een externe gebruiker de inrichting ongedaan moet maken. Rechtenbeheer en toegangsbeoordelingen kunnen een manier bieden om bestaande externe gebruikers en hun toegang tot resources te controleren en te verwijderen.

Als u gebruikers buiten rechtenbeheer uitnodigt, maakt u een afzonderlijk proces om externe gebruikerstoegang te controleren en te beheren. Als u de externe gebruiker bijvoorbeeld rechtstreeks uitnodigt via SharePoint in Microsoft 365, bevindt deze zich niet in uw rechtenbeheerproces.

Geautomatiseerd scenario

Gesynchroniseerd delen tussen tenants is het meest complex van de patronen die in dit artikel worden beschreven. Dit patroon maakt meer geautomatiseerde beheer- en de inrichtingsopties mogelijk dan door de eindgebruiker geïnitieerde of scriptbewerkingen.

In geautomatiseerde scenario's gebruiken resourcetenantbeheerders een identiteitsinrichtingssysteem om inrichtings- en de inrichtingsprocessen te automatiseren. In scenario's binnen het commerciële cloudexemplaren van Microsoft hebben we synchronisatie tussen tenants. In scenario's die Microsoft Sovereign Cloud-exemplaren omvatten, hebt u andere benaderingen nodig, omdat synchronisatie tussen tenants nog geen ondersteuning biedt voor meerdere clouds.

Een multinationale/regionale conglomeratie heeft bijvoorbeeld binnen een exemplaar van Microsoft Commercial Cloud meerdere dochterondernemingen met de volgende vereisten.

  • Elk heeft een eigen Microsoft Entra-tenant en moet samenwerken.
  • Naast het synchroniseren van nieuwe gebruikers tussen tenants, synchroniseert u automatisch kenmerkupdates en automatiseert u het ongedaan maken van de inrichting.
  • Als een werknemer zich niet meer op een dochteronderneming bevindt, verwijdert u zijn of haar account uit alle andere tenants tijdens de volgende synchronisatie.

In een uitgebreid, cross-cloudscenario heeft een dib-aannemer (Defense Industrial Base) een op defensie gebaseerde en commerciële dochteronderneming. Deze hebben concurrerende regelgevingsvereisten:

  • Het Amerikaanse defensiebedrijf bevindt zich in een Amerikaanse onafhankelijke cloudtenant, zoals Microsoft 365 GCC High en Azure Government.
  • Het commerciële bedrijf bevindt zich in een afzonderlijke Microsoft Entra-tenant in Commercial, zoals een Microsoft Entra-omgeving die wordt uitgevoerd in de wereldwijde Azure-cloud.

Als u wilt fungeren als één bedrijf dat is geïmplementeerd in een architectuur voor meerdere clouds, synchroniseren alle gebruikers met beide tenants. Deze benadering maakt geïntegreerde gal-beschikbaarheid mogelijk voor beide tenants en kan ervoor zorgen dat gebruikers automatisch worden gesynchroniseerd met beide tenants rechten en beperkingen voor toepassingen en inhoud bevatten. Voorbeelden van vereisten zijn:

  • Amerikaanse werknemers hebben mogelijk alomtegenwoordige toegang tot beide tenants.
  • Niet-Amerikaanse werknemers worden weergegeven in de uniforme GAL van beide tenants, maar hebben geen toegang tot beveiligde inhoud in de GCC High-tenant.

Voor dit scenario is automatische synchronisatie en identiteitsbeheer vereist om gebruikers in beide tenants te configureren terwijl ze worden gekoppeld aan het juiste recht en het juiste beleid voor gegevensbescherming.

Voor B2B voor meerdere clouds moet u instellingen voor crosstenanttoegang configureren voor elke organisatie waarmee u wilt samenwerken in het externe cloudexemplaren.

Accounts inrichten

In deze sectie worden drie technieken beschreven voor het automatiseren van accountinrichting in het geautomatiseerde scenario.

Techniek 1: Gebruik de ingebouwde functie voor synchronisatie tussen tenants in Microsoft Entra-id

Deze benadering werkt alleen wanneer alle tenants die u moet synchroniseren zich in hetzelfde cloudexemplaren bevinden (zoals Commercieel naar Commercieel).

Techniek 2: Accounts inrichten met Microsoft Identity Manager

Gebruik een externe IAM-oplossing (Identity and Access Management), zoals Microsoft Identity Manager (MIM) als synchronisatie-engine.

Deze geavanceerde implementatie maakt gebruik van MIM als synchronisatie-engine. MIM roept de Microsoft Graph API en Exchange Online PowerShell aan. Alternatieve implementaties kunnen bestaan uit de door de cloud gehoste SERVICE voor Active Directory Synchronization Service (ADSS) van Microsoft Industry Solutions. Er zijn niet-Microsoft-aanbiedingen die u helemaal zelf kunt maken met andere IAM-aanbiedingen (zoals SailPoint, Omada en OKTA).

U voert een cloud-naar-cloudsynchronisatie van identiteit (gebruikers, contactpersonen en groepen) uit van de ene tenant naar de andere, zoals wordt geïllustreerd in het volgende diagram.

Diagram illustreert cloud-naar-cloudsynchronisatie van identiteit, zoals gebruikers, contactpersonen en groepen, van de ene tenant naar de andere.

Overwegingen die buiten het bereik van dit artikel vallen, zijn integratie van on-premises toepassingen.

Techniek 3: Accounts inrichten met Microsoft Entra Connect

Deze techniek is alleen van toepassing op complexe organisaties die alle identiteiten beheren in traditionele Op Windows Server gebaseerde Active Directory-domein Services (AD DS). De benadering maakt gebruik van Microsoft Entra Connect als de synchronisatie-engine, zoals geïllustreerd in het volgende diagram.

Diagram illustreert een benadering voor het inrichten van accounts die microsoft Entra Connect als synchronisatie-engine gebruiken.

Diagramtitel: Accounts inrichten met Microsoft Entra Connect. In het diagram ziet u vier hoofdonderdelen. Een vak aan de linkerkant vertegenwoordigt de klant. Een cloudshape aan de rechterkant vertegenwoordigt B2B-conversie. Boven in het midden staat een vak met een cloudshape voor Microsoft Commercial Cloud. In het midden onderaan staat een vak met een cloudshape voor Microsoft US Government Sovereign Cloud. In het vak Klant maakt een Windows Server Active Directory-pictogram verbinding met twee vakken, elk met een Microsoft Entra Connect-label. De verbindingen zijn rode stippellijnen met pijlen aan beide uiteinden en een vernieuwingspictogram. De shape Microsoft Commercial Cloud is een andere cloudshape die Microsoft Azure Commercial vertegenwoordigt. Binnen is een andere cloudshape die Microsoft Entra-id vertegenwoordigt. Rechts van de vorm van de commerciële Microsoft Azure-cloud is een vak dat Office 365 vertegenwoordigt met een label, openbare multitenant. Een effen rode lijn met pijlen aan beide uiteinden verbindt het Office 365-vak met de vorm van de commerciële Microsoft Azure-cloud en een label, hybride workloads. Twee stippellijnen worden vanuit het Office 365-vak verbonden met de Microsoft Entra-cloudshape. Eén heeft een pijl aan het einde die verbinding maakt met Microsoft Entra ID. De andere heeft pijlen aan beide uiteinden. Een stippellijn met pijlen aan beide uiteinden verbindt de Microsoft Entra-cloudshape met het bovenste vak Klant Microsoft Entra Connect. Een stippellijn met pijlen aan beide uiteinden verbindt de shape Microsoft Commercial Cloud met de cloudshape B2B-conversie. In het vak Onafhankelijke cloud van Microsoft voor de Amerikaanse overheid is een andere cloudvorm die Microsoft Azure Government vertegenwoordigt. Binnen is een andere cloudshape die Microsoft Entra-id vertegenwoordigt. Rechts van de vorm van de commerciële Microsoft Azure-cloud is een vak dat Office 365 vertegenwoordigt met een label, US Gov GCC-High L4. Een effen rode lijn met pijlen aan beide uiteinden verbindt het Office 365-vak met de microsoft Azure Government-cloudvorm en een label, hybride workloads. Twee stippellijnen worden vanuit het Office 365-vak verbonden met de Microsoft Entra-cloudshape. Eén heeft een pijl aan het einde die verbinding maakt met Microsoft Entra ID. De andere heeft pijlen aan beide uiteinden. Een stippellijn met pijlen aan beide uiteinden verbindt de Microsoft Entra-cloudshape met het onderste vak Klant Microsoft Entra Connect. Een stippellijn met pijlen aan beide uiteinden verbindt de shape Microsoft Commercial Cloud met de cloudshape B2B-conversie.

In tegenstelling tot de MIM-techniek zijn alle identiteitsbronnen (gebruikers, contactpersonen en groepen) afkomstig van traditionele Op Windows Server gebaseerde Active Directory-domein Services (AD DS). De AD DS-directory is doorgaans een on-premises implementatie voor een complexe organisatie die de identiteit voor meerdere tenants beheert. Identiteit in de cloud valt niet binnen het bereik van deze techniek. Alle identiteiten moeten zich in AD DS bevinden om ze op te nemen in het bereik voor synchronisatie.

Conceptueel gezien synchroniseert deze techniek een gebruiker in een thuistenant als interne lidgebruiker (standaardgedrag). Het kan ook zijn dat een gebruiker wordt gesynchroniseerd met een resourcetenant als een externe gebruiker (aangepast gedrag).

Microsoft ondersteunt deze techniek voor dubbele synchronisatiegebruikers met zorgvuldige overwegingen bij de wijzigingen in de Microsoft Entra Connect-configuratie. Als u bijvoorbeeld wijzigingen aanbrengt in de configuratie op basis van de wizard, moet u de wijzigingen documenteren als u de configuratie tijdens een ondersteuningsincident opnieuw moet opbouwen.

Standaard kan Microsoft Entra Connect geen externe gebruiker synchroniseren. U moet het uitbreiden met een extern proces (zoals een PowerShell-script) om de gebruikers van interne naar externe accounts te converteren.

Voordelen van deze techniek zijn het synchroniseren van identiteit door Microsoft Entra Connect met kenmerken die zijn opgeslagen in AD DS. Synchronisatie kan bestaan uit adresboekkenmerken, managerkenmerken, groepslidmaatschappen en andere hybride identiteitskenmerken in alle tenants binnen het bereik. De inrichting van de identiteit wordt ongedaan gemaakt in overeenstemming met AD DS. Er is geen complexere IAM-oplossing nodig om de cloudidentiteit voor deze specifieke taak te beheren.

Er is een een-op-een-relatie van Microsoft Entra Connect per tenant. Elke tenant heeft een eigen configuratie van Microsoft Entra Connect die u afzonderlijk kunt wijzigen om lid- of externe gebruikersaccountsynchronisatie te ondersteunen.

De juiste topologie kiezen

De meeste klanten gebruiken een van de volgende topologieën in geautomatiseerde scenario's.

  • Een mesh-topologie maakt het delen van alle resources in alle tenants mogelijk. U maakt gebruikers van andere tenants in elke resourcetenant als externe gebruikers.
  • Een topologie van één resourcetenant maakt gebruik van één tenant (de resourcetenant), waarin gebruikers van andere tenants externe gebruikers zijn.

Verwijs naar de volgende tabel als beslissingsstructuur tijdens het ontwerpen van uw oplossing. Na de tabel illustreren diagrammen beide topologieën om u te helpen bepalen wat geschikt is voor uw organisatie.

Vergelijking van mesh-topologieën ten opzichte van één resourcetenant

Overweging Mesh-topologie Eén resourcetenant
Elk bedrijf heeft een afzonderlijke Microsoft Entra-tenant met gebruikers en resources Ja Ja
Resourcelocatie en samenwerking
Gedeelde apps en andere resources blijven in hun huidige thuistenant staan Ja Nee. U kunt alleen apps en andere resources delen in de resourcetenant. U kunt geen apps en andere resources delen die in andere tenants blijven.
Alles zichtbaar in de GAL's van afzonderlijke bedrijven (Unified GAL) Ja Nr.
Toegang tot en beheer van resources
U kunt ALLE toepassingen die zijn verbonden met Microsoft Entra ID delen tussen alle bedrijven. Ja Nee. Alleen toepassingen in de resourcetenant worden gedeeld. U kunt toepassingen die nog in andere tenants blijven, niet delen.
Globaal resourcebeheer Ga door op tenantniveau. Geconsolideerd in de resourcetenant.
Licentieverlening: Office 365 SharePoint in Microsoft 365, geïntegreerde GAL, Teams hebben toegang tot alle ondersteuningsgasten; Andere Exchange Online-scenario's niet. Gaat door op tenantniveau. Gaat door op tenantniveau.
Licentieverlening: Microsoft Entra-id (premium) Eerste 50 K maandelijks actieve gebruikers zijn gratis (per tenant). Eerste 50 K maandelijks actieve gebruikers zijn gratis.
Licentieverlening: SaaS-apps (Software as a Service) Voor afzonderlijke tenants blijven mogelijk licenties per gebruiker per tenant vereist. Alle gedeelde resources bevinden zich in de tenant met één resource. U kunt indien nodig het consolideren van licenties voor één tenant onderzoeken.

Mesh-topologie

In het volgende diagram ziet u een mesh-topologie.

Diagram illustreert de mesh-topologie.

In een mesh-topologie synchroniseert elke gebruiker in elke thuistenant met elk van de andere tenants, die resourcetenants worden.

  • U kunt elke resource binnen een tenant delen met externe gebruikers.
  • Elke organisatie kan alle gebruikers in het conglomeraat zien. In het bovenstaande diagram zijn er vier geïntegreerde GAL's, die elk de thuisgebruikers en de externe gebruikers van de andere drie tenants bevatten.

Veelvoorkomende overwegingen voor multitenant-gebruikersbeheer bieden informatie over het inrichten, beheren en ongedaan maken van de inrichting van gebruikers in dit scenario.

Mesh-topologie voor cross-cloud

U kunt de mesh-topologie in slechts twee tenants gebruiken, zoals in het scenario voor een DIB-verdedigingscontractant die een crosssoevereine cloudoplossing omcirkelt. Net als bij de mesh-topologie synchroniseert elke gebruiker in elke thuistenant met de andere tenant, die een resourcetenant wordt. In het sectiediagram Techniek 3 synchroniseert de interne gebruiker van de openbare commerciële tenant met de amerikaanse onafhankelijke GCC High-tenant als een extern gebruikersaccount. Tegelijkertijd synchroniseert de interne GCC High-gebruiker met Commercial als een extern gebruikersaccount.

Het diagram illustreert ook locaties voor gegevensopslag. Gegevenscategorisatie en -naleving vallen buiten het bereik van dit artikel, maar u kunt rechten en beperkingen voor toepassingen en inhoud opnemen. Inhoud kan locaties bevatten waar de gegevens van een interne gebruiker zich bevinden (zoals gegevens die zijn opgeslagen in een Exchange Online-postvak of OneDrive voor Bedrijven). De inhoud bevindt zich mogelijk in hun thuistenant en niet in de resourcetenant. Gedeelde gegevens kunnen zich in beide tenants bevinden. U kunt de toegang tot de inhoud beperken via toegangsbeheer en beleid voor voorwaardelijke toegang.

Topologie van één resourcetenant

In het volgende diagram ziet u de topologie van één resourcetenant.

Diagram illustreert één resourcetenanttopologie.

In één resourcetenanttopologie worden gebruikers en hun kenmerken gesynchroniseerd met de resourcetenant (bedrijf A in het bovenstaande diagram).

  • Alle resources die worden gedeeld tussen de lidorganisaties moeten zich in de tenant met één resource bevinden. Als meerdere dochterondernemingen abonnementen hebben op dezelfde SaaS-apps, is er een mogelijkheid om deze abonnementen samen te voegen.
  • Alleen de GAL in de resourcetenant geeft gebruikers van alle bedrijven weer.

Accounts beheren

Deze oplossing detecteert en synchroniseert kenmerkwijzigingen van brontenantgebruikers naar externe gebruikers van de resourcetenant. U kunt deze kenmerken gebruiken om autorisatiebeslissingen te nemen (bijvoorbeeld wanneer u dynamische groepen gebruikt).

Accounts ongedaan maken

Automation detecteert het verwijderen van objecten in de bronomgeving en verwijdert het bijbehorende externe gebruikersobject in de doelomgeving.

Algemene overwegingen voor multitenant-gebruikersbeheer bieden aanvullende informatie over het inrichten, beheren en ongedaan maken van de inrichting van gebruikers in dit scenario.

Volgende stappen

  • Inleiding tot multitenant-gebruikersbeheer is de eerste in de reeks artikelen die richtlijnen bieden voor het configureren en bieden van levenscyclusbeheer van gebruikers in Microsoft Entra-omgevingen met meerdere tenants.
  • Algemene overwegingen voor multitenant-gebruikersbeheer bieden richtlijnen voor deze overwegingen: synchronisatie tussen tenants, adreslijstobject, voorwaardelijke toegang van Microsoft Entra, extra toegangsbeheer en Office 365.
  • Algemene oplossingen voor multitenant-gebruikersbeheer wanneer één tenancy niet werkt voor uw scenario, biedt dit artikel richtlijnen voor deze uitdagingen: automatisch levenscyclusbeheer van gebruikers en resourcetoewijzing voor tenants, on-premises apps delen tussen tenants.