Scenarier för hantering av flera klientorganisationer
Den här artikeln är den andra i en serie artiklar som ger vägledning för att konfigurera och tillhandahålla användarlivscykelhantering i Microsoft Entra-miljöer med flera klientorganisationer. Följande artiklar i serien innehåller mer information enligt beskrivningen.
- Introduktionen till användarhantering med flera klientorganisationer är den första i serien med artiklar som ger vägledning för att konfigurera och tillhandahålla användarlivscykelhantering i Microsoft Entra-miljöer med flera klientorganisationer.
- Vanliga överväganden för hantering av flera klienter ger vägledning för följande överväganden: synkronisering mellan klientorganisationer, katalogobjekt, villkorsstyrd åtkomst i Microsoft Entra, ytterligare åtkomstkontroll och Office 365.
- Vanliga lösningar för hantering av flera klienter när en enskild klientorganisation inte fungerar för ditt scenario. Den här artikeln innehåller vägledning för dessa utmaningar: automatisk hantering av användarlivscykel och resursallokering mellan klienter, delning av lokala appar mellan klientorganisationer.
Vägledningen hjälper dig att uppnå ett konsekvent tillstånd för användarlivscykelhantering. Livscykelhantering omfattar etablering, hantering och avetablering av användare mellan klienter med hjälp av tillgängliga Azure-verktyg som omfattar Microsoft Entra B2B-samarbete (B2B) och synkronisering mellan klientorganisationer.
I den här artikeln beskrivs tre scenarier där du kan använda funktioner för användarhantering med flera klientorganisationer.
- Slutanvändarinitierad
- Skript
- Automatiserade
Scenario som initieras av slutanvändare
I slutanvändarinitierade scenarier delegerar resursklientadministratörer vissa funktioner till användare i klientorganisationen. Administratörer gör det möjligt för slutanvändare att bjuda in externa användare till klientorganisationen, en app eller en resurs. Du kan bjuda in användare från hemklientorganisationen eller registrera dem individuellt.
Till exempel samarbetar ett globalt företag för professionella tjänster med underleverantörer i projekt. Underleverantörer (externa användare) kräver åtkomst till företagets program och dokument. Företagsadministratörer kan delegera möjligheten att bjuda in underleverantörer till slutanvändarna eller konfigurera självbetjäning för resursåtkomst för underleverantörer.
Etableringskonton
Här är de vanligaste sätten att bjuda in slutanvändare att komma åt klientresurser.
- Programbaserade inbjudningar. Microsoft-program (till exempel Teams och SharePoint) kan aktivera externa användarinbjudningar. Konfigurera B2B-inbjudningsinställningar i både Microsoft Entra B2B och i relevanta program.
- MyApps. Användare kan bjuda in och tilldela externa användare till program med Hjälp av MyApps. Användarkontot måste ha behörighet som godkännare för programregistrering via självbetjäning . Gruppägare kan bjuda in externa användare till sina grupper.
- Berättigandehantering. Gör det möjligt för administratörer eller resursägare att skapa åtkomstpaket med resurser, tillåtna externa organisationer, förfallodatum för externa användare och åtkomstprinciper. Publicera åtkomstpaket för att aktivera extern självbetjäningsregistrering för resursåtkomst.
- Azure Portal. Slutanvändare med rollen Gästinbjudare kan logga in på Azure Portal och bjuda in externa användare från menyn Användare i Microsoft Entra-ID.
- Programmatiskt (PowerShell, Graph API). Slutanvändare med rollen Gästinbjudare kan använda PowerShell eller Graph API för att bjuda in externa användare.
Lösa in inbjudningar
När du etablerar konton för åtkomst till en resurs går e-postinbjudningar till den inbjudna användarens e-postadress.
När en inbjuden användare får en inbjudan kan de följa länken i e-postmeddelandet till inlösnings-URL:en. På så sätt kan den inbjudna användaren godkänna eller neka inbjudan och, om det behövs, skapa ett externt användarkonto.
Inbjudna användare kan också försöka få direkt åtkomst till resursen, som kallas just-in-time-inlösning (JIT), om något av följande scenarier är sant.
- Den inbjudna användaren har redan ett Microsoft Entra-ID eller Microsoft-konto, eller
- Administratörer har aktiverat engångslösenord för e-post.
Under JIT-inlösen kan följande överväganden gälla.
- Om administratörer inte har undertryckt medgivandemeddelanden måste användaren samtycka innan den får åtkomst till resursen.
- Du kan tillåta eller blockera inbjudningar till externa användare från specifika organisationer med hjälp av en lista över tillåtna eller blockerade.
Mer information finns i Inlösen av Microsoft Entra B2B-samarbetsinbjudan.
Aktivera engångslösenordsautentisering
I scenarier där du tillåter ad hoc B2B aktiverar du autentisering med engångslösenord för e-post. Den här funktionen autentiserar externa användare när du inte kan autentisera dem på annat sätt, till exempel:
- Microsoft Entra-ID.
- Microsoft-konto.
- Gmail-konto via Google Federation.
- Konto från ett SAML (Security Assertion Markup Language)/WS-Fed IDP via Direkt federation.
Med autentisering med ett engångslösenord behöver du inte skapa ett Microsoft-konto. När den externa användaren löser in en inbjudan eller får åtkomst till en delad resurs får de en tillfällig kod på sin e-postadress. De anger sedan koden för att fortsätta logga in.
Hantera konton
I det slutanvändarinitierade scenariot hanterar resursklientadministratören externa användarkonton i resursklientorganisationen (uppdateras inte baserat på de uppdaterade värdena i hemklientorganisationen). De enda synliga attribut som tas emot är e-postadressen och visningsnamnet.
Du kan konfigurera fler attribut för externa användarobjekt för att underlätta olika scenarier (till exempel berättigandescenarier). Du kan inkludera att fylla i adressboken med kontaktuppgifter. Tänk till exempel på följande attribut.
- HiddenFromAddressListsEnabled [ShowInAddressList]
- FirstName [GivenName]
- Efternamn [SurName]
- Title
- Avdelning
- Telefonnummer
Du kan ange dessa attribut för att lägga till externa användare i den globala adresslistan (GAL) och för personsökning (till exempel SharePoint People Picker). Andra scenarier kan kräva olika attribut (till exempel att ange rättigheter och behörigheter för åtkomstpaket, dynamiskt gruppmedlemskap och SAML-anspråk).
Som standard döljer GAL inbjudna externa användare. Ange externa användarattribut så att de tas med i den enhetliga GAL:en. Avsnittet Microsoft Exchange Online i Vanliga överväganden för användarhantering med flera klienter beskriver hur du kan minska gränserna genom att skapa externa medlemsanvändare i stället för externa gästanvändare.
Avetableringskonton
Slutanvändarinitierade scenarier decentraliserar åtkomstbeslut, vilket kan skapa utmaningen att bestämma när en extern användare och deras associerade åtkomst ska tas bort. Med rättighetshantering och åtkomstgranskningar kan du granska och ta bort befintliga externa användare och deras resursåtkomst.
När du bjuder in användare utanför berättigandehantering måste du skapa en separat process för att granska och hantera deras åtkomst. Om du till exempel bjuder in en extern användare direkt via SharePoint i Microsoft 365 finns det inte i din rättighetshanteringsprocess.
Scenario med skript
I det skriptade scenariot distribuerar resursklientadministratörer en skriptad pull-process för att automatisera identifiering och extern användaretablering.
Ett företag förvärvar till exempel en konkurrent. Varje företag har en enda Microsoft Entra-klientorganisation. De vill att följande dag ett-scenarier ska fungera utan att användarna behöver utföra några inbjudnings- eller inlösningssteg. Alla användare måste kunna:
- Använd enkel inloggning för alla etablerade resurser.
- Hitta varandra och resurser i en enhetlig GAL.
- Fastställ varandras närvaro och initiera chatt.
- Få åtkomst till program baserat på dynamiska medlemskapsgrupper.
I det här scenariot är varje organisations klientorganisation hemklientorganisationen för sina befintliga anställda samtidigt som den är resursklient för den andra organisationens anställda.
Etableringskonton
Med Delta Query kan klientadministratörer distribuera en skriptbaserad pull-process för att automatisera identifiering och identitetsetablering för att stödja resursåtkomst. Den här processen kontrollerar hemklientorganisationen efter nya användare. Den använder B2B Graph-API:er för att etablera nya användare som externa användare i resursklientorganisationen, vilket visas i följande topologidiagram för flera klienter.
- Klientadministratörer förinstallerar autentiseringsuppgifter och samtycker till att tillåta att varje klientorganisation läser.
- Klientadministratörer automatiserar uppräkning och hämtar begränsade användare till resursklientorganisationen.
- Använd Microsoft Graph API med medgivande behörigheter för att läsa och etablera användare med inbjudnings-API:et.
- Inledande etablering kan läsa källattribut och tillämpa dem på målanvändarobjektet.
Hantera konton
Resursorganisationen kan utöka profildata för att stödja delningsscenarier genom att uppdatera användarens metadataattribut i resursklientorganisationen. Men om pågående synkronisering är nödvändig kan en synkroniserad lösning vara ett bättre alternativ.
Avetableringskonton
Delta Query kan signalera när en extern användare måste avetableras. Rättighetshantering och åtkomstgranskningar kan vara ett sätt att granska och ta bort befintliga externa användare och deras åtkomst till resurser.
Om du bjuder in användare utanför berättigandehantering skapar du en separat process för att granska och hantera extern användaråtkomst. Om du till exempel bjuder in den externa användaren direkt via SharePoint i Microsoft 365 finns det inte i din rättighetshanteringsprocess.
Automatiserat scenario
Synkroniserad delning mellan klienter är den mest komplexa av de mönster som beskrivs i den här artikeln. Det här mönstret möjliggör mer automatiserade hanterings- och avetableringsalternativ än slutanvändarinitierade eller skriptade.
I automatiserade scenarier använder resursklientadministratörer ett identitetsetableringssystem för att automatisera etablerings- och avetableringsprocesser. I scenarier inom Microsofts commercial cloud-instans har vi synkronisering mellan klientorganisationer. I scenarier som omfattar Microsoft Sovereign Cloud-instanser behöver du andra metoder eftersom synkronisering mellan klientorganisationer ännu inte stöder korsmoln.
I en Microsoft Commercial Cloud-instans har till exempel ett multinationellt/regionalt konglomerat flera dotterbolag med följande krav.
- Var och en har sin egen Microsoft Entra-klientorganisation och måste arbeta tillsammans.
- Förutom att synkronisera nya användare mellan klienter synkroniserar du automatiskt attributuppdateringar och automatiserar avetablering.
- Om en anställd inte längre är i ett dotterbolag tar du bort deras konto från alla andra klienter under nästa synkronisering.
I ett utökat, molnöverskridande scenario har en DIB-entreprenör (Defense Industrial Base) ett försvarsbaserat och kommersiellt baserat dotterbolag. Dessa har konkurrerande regleringskrav:
- Det amerikanska försvarsföretaget finns i en US Sovereign Cloud-klientorganisation som Microsoft 365 US Government GCC High och Azure Government.
- Det kommersiella företaget finns i en separat Microsoft Entra-klientorganisation i Commercial, till exempel en Microsoft Entra-miljö som körs i det globala Azure-molnet.
För att fungera som ett enda företag som distribuerats till en arkitektur mellan moln synkroniserar alla användare till båda klienterna. Den här metoden möjliggör enhetlig GAL-tillgänglighet för båda klienterna och kan säkerställa att användare som automatiskt synkroniseras med båda klienterna inkluderar rättigheter och begränsningar för program och innehåll. Exempelkrav är:
- Amerikanska anställda kan ha allestädes närvarande åtkomst till båda klienterna.
- Icke-amerikanska anställda visas i den enhetliga GAL för båda klienterna men har inte åtkomst till skyddat innehåll i GCC High-klientorganisationen.
Det här scenariot kräver automatisk synkronisering och identitetshantering för att konfigurera användare i båda klientorganisationer samtidigt som de associeras med rätt berättigande- och dataskyddsprinciper.
B2B mellan moln kräver att du konfigurerar åtkomstinställningar mellan klientorganisationer för varje organisation som du vill samarbeta med i den fjärranslutna molninstansen.
Etableringskonton
I det här avsnittet beskrivs tre metoder för att automatisera kontoetablering i det automatiserade scenariot.
Teknik 1: Använd den inbyggda synkroniseringsfunktionen mellan klientorganisationer i Microsoft Entra-ID
Den här metoden fungerar bara när alla klienter som du behöver synkronisera finns i samma molninstans (till exempel Kommersiell till kommersiell).
Teknik 2: Etablera konton med Microsoft Identity Manager
Använd en lösning för extern identitets- och åtkomsthantering (IAM), till exempel Microsoft Identity Manager (MIM) som en synkroniseringsmotor.
Den här avancerade distributionen använder MIM som synkroniseringsmotor. MIM anropar Microsoft Graph API och Exchange Online PowerShell. Alternativa implementeringar kan vara den molnbaserade active directory-synkroniseringstjänstens (ADSS) hanterade tjänsterbjudande från Microsoft Industry Solutions. Det finns icke-Microsoft-erbjudanden som du kan skapa från grunden med andra IAM-erbjudanden (till exempel SailPoint, Omada och OKTA).
Du utför en moln-till-moln-synkronisering av identitet (användare, kontakter och grupper) från en klientorganisation till en annan enligt följande diagram.
Överväganden som ligger utanför omfånget för den här artikeln omfattar integrering av lokala program.
Teknik 3: Etablera konton med Microsoft Entra Connect
Den här tekniken gäller endast för komplexa organisationer som hanterar alla identiteter i traditionella Windows Server-baserade Active Directory-domän Services (AD DS). Metoden använder Microsoft Entra Connect som synkroniseringsmotor enligt följande diagram.
Till skillnad från MIM-tekniken kommer alla identitetskällor (användare, kontakter och grupper) från traditionella Windows Server-baserade Active Directory-domän Services (AD DS). AD DS-katalogen är vanligtvis en lokal distribution för en komplex organisation som hanterar identiteter för flera klientorganisationer. Molnbaserad identitet finns inte i omfånget för den här tekniken. Alla identiteter måste finnas i AD DS för att inkludera dem i omfånget för synkronisering.
Konceptuellt synkroniserar den här tekniken en användare till en hemklientorganisation som en intern medlemsanvändare (standardbeteende). Alternativt kan den synkronisera en användare till en resursklientorganisation som en extern användare (anpassat beteende).
Microsoft stöder den här användartekniken med dubbel synkronisering med noggranna överväganden om vilka ändringar som sker i Microsoft Entra Connect-konfigurationen. Om du till exempel gör ändringar i den guidedrivna konfigurationskonfigurationen måste du dokumentera ändringarna om du måste återskapa konfigurationen under en supportincident.
Microsoft Entra Connect kan inte synkronisera en extern användare. Du måste utöka den med en extern process (till exempel ett PowerShell-skript) för att konvertera användarna från interna till externa konton.
Fördelarna med den här tekniken är att Microsoft Entra Connect synkroniserar identitet med attribut som lagras i AD DS. Synkronisering kan omfatta adressboksattribut, chefsattribut, gruppmedlemskap och andra hybrididentitetsattribut i alla klienter inom omfånget. Den avetablerar identiteten i linje med AD DS. Det krävs ingen mer komplex IAM-lösning för att hantera molnidentiteten för den här specifika uppgiften.
Det finns en en-till-en-relation med Microsoft Entra Connect per klientorganisation. Varje klientorganisation har en egen konfiguration av Microsoft Entra Connect som du kan ändra individuellt för att stödja synkronisering av medlemmar eller externa användarkonton.
Välja rätt topologi
De flesta kunder använder någon av följande topologier i automatiserade scenarier.
- En nättopologi möjliggör delning av alla resurser i alla klienter. Du skapar användare från andra klienter i varje resursklientorganisation som externa användare.
- En topologi för en enskild resursklient använder en enda klientorganisation (resursklientorganisationen), där användare från andra klienter är externa användare.
Referera till följande tabell som ett beslutsträd när du utformar lösningen. Efter tabellen illustrerar diagram båda topologierna som hjälper dig att avgöra vilken som är rätt för din organisation.
Jämförelse av mesh jämfört med klienttopologier för en enskild resurs
Att tänka på | Nättopologi | Klientorganisation för enskild resurs |
---|---|---|
Varje företag har en separat Microsoft Entra-klient med användare och resurser | Ja | Ja |
Resursplats och samarbete | ||
Delade appar och andra resurser finns kvar i den aktuella hemklientorganisationen | Ja | Nej. Du kan bara dela appar och andra resurser i resursklientorganisationen. Du kan inte dela appar och andra resurser som finns kvar i andra klienter. |
Alla kan visas i enskilda företags GALs (Unified GAL) | Ja | Nej |
Resursåtkomst och -administration | ||
Du kan dela ALLA program som är anslutna till Microsoft Entra-ID mellan alla företag. | Ja | Nej. Endast program i resursklientorganisationen delas. Du kan inte dela program som finns kvar i andra klienter. |
Global resursadministration | Fortsätt på klientorganisationsnivå. | Konsoliderad i resursklientorganisationen. |
Licensiering: Office 365 SharePoint i Microsoft 365, unified GAL, Teams har åtkomst till alla supportgäster; Andra Exchange Online-scenarier gör det dock inte. | Fortsätter på klientorganisationsnivå. | Fortsätter på klientorganisationsnivå. |
Licensiering: Microsoft Entra ID (premium) | De första 50 K månatliga aktiva användarna är kostnadsfria (per klientorganisation). | De första 50 K månatliga aktiva användarna är kostnadsfria. |
Licensiering: SaaS-appar (programvara som en tjänst) | Stanna kvar i enskilda klientorganisationer, kan kräva licenser per användare per klientorganisation. | Alla delade resurser finns i den enskilda resursklientorganisationen. Du kan undersöka hur du konsoliderar licenser till den enskilda klientorganisationen om det är lämpligt. |
Nättopologi
Följande diagram illustrerar nättopologin.
I en nättopologi synkroniseras varje användare i varje hemklientorganisation med var och en av de andra klientorganisationer som blir resursklientorganisationer.
- Du kan dela alla resurser i en klientorganisation med externa användare.
- Varje organisation kan se alla användare i konglomeratet. I diagrammet ovan finns det fyra enhetliga GAL:er, som var och en innehåller hemanvändare och externa användare från de övriga tre klienterna.
Vanliga överväganden för användarhantering med flera klienter innehåller information om etablering, hantering och avetablering av användare i det här scenariot.
Mesh-topologi för molnöverskridande
Du kan använda nättopologin i så få som två klienter, till exempel i scenariot för en DIB-försvarsentreprenör som sträcker sig över en molnlösning mellan nationella nätverk. Precis som med nättopologin synkroniseras varje användare i varje hemklientorganisation med den andra klientorganisationen, som blir en resursklient. I avsnittsdiagrammet Teknik 3 synkroniserar den interna användaren för den offentliga kommersiella klientorganisationen till den amerikanska nationella GCC High-klienten som ett externt användarkonto. Samtidigt synkroniserar den interna GCC High-användaren till Commercial som ett externt användarkonto.
Diagrammet illustrerar också datalagringsplatser. Datakategorisering och efterlevnad ligger utanför omfånget för den här artikeln, men du kan inkludera rättigheter och begränsningar för program och innehåll. Innehållet kan innehålla platser där en intern användares användarägda data finns (till exempel data som lagras i en Exchange Online-postlåda eller OneDrive). Innehållet kan finnas i deras hemklientorganisation och inte i resursklientorganisationen. Delade data kan finnas i någon av klientorganisationen. Du kan begränsa åtkomsten till innehållet via åtkomstkontroll och principer för villkorsstyrd åtkomst.
Topologi för enskild resursklient
Följande diagram illustrerar topologin för en enskild resursklient.
I en enskild resursklienttopologi synkroniserar användare och deras attribut till resursklientorganisationen (företag A i diagrammet ovan).
- Alla resurser som delas mellan medlemsorganisationerna måste finnas i den enskilda resursklientorganisationen. Om flera dotterbolag har prenumerationer på samma SaaS-appar finns det en möjlighet att konsolidera dessa prenumerationer.
- Endast GAL i resursklientorganisationen visar användare från alla företag.
Hantera konton
Den här lösningen identifierar och synkroniserar attributändringar från källklientanvändare till externa resursklientanvändare. Du kan använda dessa attribut för att fatta auktoriseringsbeslut (till exempel när du använder dynamiska medlemskapsgrupper).
Avetableringskonton
Automation identifierar borttagning av objekt i källmiljön och tar bort det associerade externa användarobjektet i målmiljön.
Vanliga överväganden för hantering av flera klienter ger ytterligare information om etablering, hantering och avetablering av användare i det här scenariot.
Nästa steg
- Introduktionen till användarhantering med flera klientorganisationer är den första i serien med artiklar som ger vägledning för att konfigurera och tillhandahålla användarlivscykelhantering i Microsoft Entra-miljöer med flera klientorganisationer.
- Vanliga överväganden för hantering av flera klienter ger vägledning för följande överväganden: synkronisering mellan klientorganisationer, katalogobjekt, villkorsstyrd åtkomst i Microsoft Entra, ytterligare åtkomstkontroll och Office 365.
- Vanliga lösningar för hantering av flera klienter när en enskild klientorganisation inte fungerar för ditt scenario. Den här artikeln innehåller vägledning för dessa utmaningar: automatisk hantering av användarlivscykel och resursallokering mellan klienter, delning av lokala appar mellan klientorganisationer.