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 verwijderen van gebruikers in tenants met behulp van de beschikbare Azure-hulpprogramma's, waaronder Microsoft Entra B2B-samenwerking en synchronisatie tussen tenants.

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. Bedrijfsbeheerders kunnen aan de eindgebruikers de mogelijkheid geven om onderaannemers uit te nodigen of zelfbediening te configureren voor de toegang tot de middelen van onderaannemers.

Accounts voorzien

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 over zelfbedieningsregistratie- en goedkeuringsmachtigingen voor toepassingen beschikken. Groepseigenaren kunnen externe gebruikers uitnodigen voor hun groepen.
• Rechtenbeheer. Beheerders of resource-eigenaren de mogelijkheid geven om toegangspakketten te creëren met middelen, toegestane externe organisaties, vervaldatum 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, wat aangeduid wordt als just-in-time (JIT) toegang, als een van de volgende scenario's van toepassing 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-samenwerkingsuitnodiging inwisseling.

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 door 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.

• VerborgenVanAdreslijstenIngeschakeld [ToonInAdreslijst]
• Voornaam [GivenName]
• Achternaam [SurName]
• Titel
• Departement
• Telefoonnummer

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.

Deprovisioneren van accounts

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 resource-tenantbeheerders een gescript pull-proces om detectie en voorziening van externe gebruikers te automatiseren.

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

• Gebruik single sign-on voor alle ingerichte bronnen.
• Zoek elkaar en middelen in een geïntegreerde GAL.
• Bepaal elkaars aanwezigheid en initieer chat.
• Toegang tot toepassingen op basis van dynamische lidmaatschapsgroepen.

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

Accounts voorzien

Met Delta Query kunnen tenantbeheerders een scripted pull-proces implementeren om detectie en identiteitsinrichting te automatiseren om toegang tot resources te ondersteunen. Dit proces controleert de thuistenant 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.

Diagramtitel: multitenant topologie diagram. Aan de linkerkant bevat een vak met het label Bedrijf A interne gebruikers en externe gebruikers. Aan de rechterkant bevat een vak met het label Bedrijf B interne gebruikers en externe gebruikers. Tussen bedrijf A en bedrijf B gaat een interactie van bedrijf A naar bedrijf B met het label, Script om A-gebruikers naar B te halen. Een andere interactie gaat van bedrijf B naar bedrijf A met het label, Script om B-gebruikers naar A te halen.

• Tenantbeheerders regelen vooraf de referenties en geven toestemming zodat iedere tenant kan lezen.
• Tenantbeheerders automatiseren enumeratie en het ophalen van gebruikers in scope 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.

Deprovisioneren van accounts

Delta Query kan aangeven wanneer een externe gebruiker gedeprovisioneerd moet worden. 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 uitrukkingsopties mogelijk dan door de eindgebruiker geïnitieerde opties of scriptbewerkingen.

In geautomatiseerde scenario's gebruiken resource-tenant beheerders een identiteitsbeheer systeem om de provisioning en ontmantelingsprocessen te automatiseren. In scenario's binnen de Commercial Cloud-omgeving van Microsoft hebben we cross-tenant synchronisatie. 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, worden kenmerkupdates automatisch gesynchroniseerd en is het deprovisioning geautomatiseerd.
• 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 uitgebreide cross-cloud scenario heeft een Defense Industrial Base (DIB) aannemer 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, die automatisch met beide tenants worden gesynchroniseerd, zodanig rechten en beperkingen voor toepassingen en inhoud bevatten. Voorbeelden van vereisten zijn:

• Amerikaanse werknemers hebben mogelijk alomtegenwoordige toegang tot beide tenants.
• Niet-Amerikaanse werknemers verschijnen in de geünificeerde globalen adreslijst (GAL) van beide tenants, maar hebben geen toegang tot beveiligde inhoud in de GCC High tenant.

Voor dit scenario zijn automatische synchronisatie en identiteitsbeheer vereist om gebruikers in beide tenants te configureren en hen te koppelen aan de juiste toekenning en gegevensbeschermingsbeleid.

Cross-cloud B2B vereist dat u instellingen voor Cross-Tenant Access configureert voor elke organisatie waarmee u wilt samenwerken in de externe cloudinstantie.

Accounts voorzien

In deze paragraaf worden drie technieken beschreven voor het automatiseren van accountprovisioning in een geautomatiseerd scenario.

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

Deze aanpak werkt alleen wanneer alle tenants die u wilt synchroniseren zich in hetzelfde cloudexemplaar bevinden (zoals Commercieel voor 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 het door de cloud gehoste Active Directory Synchronization Service (ADSS) beheerd serviceaanbod. 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.

Diagramtitel: Cloud-naar-cloud-identiteitssynchronisatie. Aan de linkerkant bevat een vak met het label Bedrijf A interne gebruikers en externe gebruikers. Aan de rechterkant bevat een vak met het label Bedrijf B interne gebruikers en externe gebruikers. Tussen bedrijf A en bedrijf B gaan de interacties tussen de synchronisatie-engine van bedrijf A naar bedrijf B en van bedrijf B naar bedrijf A.

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.

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 wolkvorm die Microsoft Commercial Cloud vertegenwoordigt. In het midden onderaan staat een vak met een wolkvorm die Microsoft US Government Sovereign Cloud vertegenwoordigt. 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. Binnen de vorm van Microsoft Commercial Cloud bevindt zich een andere cloudvorm die Microsoft Azure Commercial vertegenwoordigt. Binnen is een andere cloudvorm 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, Publieke multitenant. Een effen rode lijn met pijlen aan beide uiteinden verbindt het Office 365-vak met de vorm van de commerciële cloud Microsoft Azure en heeft het label "Hybride Workloads". Twee stippellijnen verbinden het Office 365-vak met de Microsoft Entra-cloudvorm. 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-cloudvorm met het bovenste vak van Microsoft Entra Connect voor Klant. Een stippellijn met pijlen aan beide uiteinden verbindt de Microsoft Commercial Cloud-vorm met de B2B-conversie-cloudvorm. In de Sovereign Cloud-box van Microsoft voor de Amerikaanse overheid bevindt zich een andere cloudvorm die Microsoft Azure Government vertegenwoordigt. Binnen is een andere cloudvorm die Microsoft Entra ID vertegenwoordigt. Rechts van de commerciële cloudvorm van Microsoft Azure bevindt zich een vak dat Office 365 vertegenwoordigt met het 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 de label "Hybride Workloads". Twee stippellijnen verbinden het Office 365-vak met de Microsoft Entra-cloudvorm. 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-cloudvorm met het onderste vak voor Microsoft Entra Connect van de klant. Een stippellijn met pijlen aan beide uiteinden verbindt de Microsoft Commercial Cloud-vorm met de B2B-conversie-cloudvorm.

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.

In essentie synchroniseert deze techniek een gebruiker in een thuisomgeving 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 dubbele synchronisatietechniek voor gebruikers met zorgvuldige overwegingen voor 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. Je creëert gebruikers van andere tenants binnen elke brontenant 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 versus topologieën met een enkele 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	Ja	Nee. U kunt alleen apps en andere resources delen in de resourcetenant. U kunt geen apps en andere resources delen die zich in andere tenants bevinden.
Alles zichtbaar in de GAL's van afzonderlijke bedrijven (Unified GAL)	Ja	Nee
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 middelen bevinden zich in de enkele resource-tenant. U kunt indien nodig het consolideren van licenties voor één tenant onderzoeken.

Mesh-topologie

In het volgende diagram ziet u een mesh-topologie.

Diagramtitel: Mesh-topologie. Linksboven bevat een vak met het label Bedrijf A interne gebruikers en externe gebruikers. Rechtsboven bevat een vak met het label Bedrijf B interne gebruikers en externe gebruikers. Linksonder bevat een vak met het label Bedrijf C interne gebruikers en externe gebruikers. Rechtsonder bevat een vak met het label Bedrijf D interne gebruikers en externe gebruikers. Tussen Bedrijf A en Bedrijf B en tussen Bedrijf C en Bedrijf D worden de synchronisatiemotor-interacties uitgevoerd tussen de bedrijven aan de linkerkant en de bedrijven aan de rechterkant.

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 deprovisioning van gebruikers in dit scenario.

Mesh-topologie voor multi-cloudomgevingen

U kunt de meshtopologie in slechts twee tenants gebruiken, zoals in het scenario voor een DIB-defensieaannemer die gebruikmaakt van een soeverein overstijgende cloudoplossing. Net als bij de mesh-topologie synchroniseert elke gebruiker in elke thuistenant met de andere tenant, die een resourcetenant wordt. In het diagram van Techniek 3 synchroniseert de interne gebruiker van de openbare commerciële tenant met de Amerikaanse soevereine 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). 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 een enkele resourcetenant

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

Diagramtitel: topologie van één resourcetenant. Bovenaan bevindt zich een doos die Bedrijf A vertegenwoordigt en drie vakken bevat. Aan de linkerkant vertegenwoordigt een vak alle gedeelde resources. In het midden is een vak dat interne gebruikers vertegenwoordigt. Aan de rechterkant is een vak dat externe gebruikers vertegenwoordigt. Onder het vak Bedrijf A staat een vak dat de synchronisatie-engine vertegenwoordigt. Drie pijlen verbinden de synchronisatie-engine met Bedrijf A. Onder het vak synchronisatie-engine, onder aan het diagram, staan drie vakken die Bedrijf B, Bedrijf C en Bedrijf D vertegenwoordigen. Een pijl verbindt ze allemaal met het vak synchronisatie-engine. Binnen elk van de onderste bedrijfsvakken bevindt zich een label, Microsoft Graph API Exchange Online PowerShell en pictogrammen die interne gebruikers vertegenwoordigen.

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 bevinden in een enkele resource-tenant. 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 lidmaatschapsgroepen gebruikt).

Deprovisioneren van accounts

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 provisionen, beheren en deprovisionen 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.