Så här fungerar programetablering i Microsoft Entra-ID

Artikel
08/25/2024

Automatisk etablering syftar på att skapa användaridentiteter och roller i de molnprogram som användarna behöver åtkomst till. Förutom att skapa användaridentiteter inkluderar automatisk etablering underhåll och borttagning av användaridentiteter när status eller roller ändras. Innan du startar en distribution kan du läsa den här artikeln för att lära dig hur Microsoft Entra-etablering fungerar och få konfigurationsrekommendationer.

Microsoft Entra-etableringstjänsten etablerar användare till SaaS-appar och andra system genom att ansluta till en API-slutpunkt för system för hantering av identiteter mellan domäner (SCIM) 2.0 som tillhandahålls av programleverantören eller en lokal etableringsagent. Med den här SCIM-slutpunkten kan Microsoft Entra-ID:t programmatiskt skapa, uppdatera och ta bort användare. För valda program kan etableringstjänsten också skapa, uppdatera och ta bort extra identitetsrelaterade objekt, till exempel grupper. Den kanal som används för etablering mellan Microsoft Entra-ID och programmet krypteras med HTTPS TLS 1.2-kryptering.

Bild 1: Microsoft Entra-etableringstjänsten

Bild 2: Arbetsflöde för utgående användaretablering från Microsoft Entra-ID till populära SaaS-program

Bild 3: Arbetsflöde för inkommande användaretablering från populära HCM-program (Human Capital Management) till Microsoft Entra ID och Windows Server Active Directory

Etablering med SCIM 2.0

Microsoft Entra-etableringstjänsten använder SCIM 2.0-protokollet för automatisk etablering. Tjänsten ansluter till SCIM-slutpunkten för programmet och använder SCIM-användarobjektschema och REST-API:er för att automatisera etablering och avetablering av användare och grupper. En SCIM-baserad etableringsanslutning tillhandahålls för de flesta program i Microsoft Entra-galleriet. Utvecklare använder SCIM 2.0-användarhanterings-API:et i Microsoft Entra-ID för att skapa slutpunkter för sina appar som integreras med etableringstjänsten. Mer information finns i Skapa en SCIM-slutpunkt och konfigurera användaretablering. Den lokala etableringsagenten översätter även Microsoft Entra SCIM-åtgärder till LDAP, SQL, REST eller SOAP, PowerShell, anrop till en anpassad ECMA-anslutningsapp eller anslutningsappar och gatewayer som skapats av partner.

Information om hur du begär en automatisk Microsoft Entra-etableringsanslutning för en app som för närvarande inte har någon finns i Microsoft Entra-programbegäran.

Auktorisering

Autentiseringsuppgifter krävs för att Microsoft Entra-ID ska kunna ansluta till programmets API för användarhantering. När du konfigurerar automatisk användaretablering för ett program måste du ange giltiga autentiseringsuppgifter. För galleriprogram kan du hitta typer av autentiseringsuppgifter och krav för programmet genom att referera till appguiden. För program som inte är galleriprogram kan du läsa SCIM-dokumentationen för att förstå typer och krav för autentiseringsuppgifter. I administrationscentret för Microsoft Entra kan du testa autentiseringsuppgifterna genom att låta Microsoft Entra-ID:t försöka ansluta till appens etableringsapp med de angivna autentiseringsuppgifterna.

Mappningsattribut

När du aktiverar användaretablering för ett SaaS-program från tredje part styr administrationscentret för Microsoft Entra dess attributvärden via attributmappningar. Mappningar avgör vilka användarattribut som flödar mellan Microsoft Entra-ID och målprogrammet när användarkonton etableras eller uppdateras.

Det finns en förkonfigurerad uppsättning attribut och attributmappningar mellan Microsoft Entra-användarobjekt och varje SaaS-app användarobjekt. Vissa appar hanterar andra typer av objekt tillsammans med Användare, till exempel Grupper.

När du konfigurerar etablering är det viktigt att granska och konfigurera attributmappningar och arbetsflöden som definierar vilka användaregenskaper (eller grupp)-egenskaper som flödar från Microsoft Entra-ID till programmet. Granska och konfigurera matchande egenskap (Matcha objekt med det här attributet) som används för att unikt identifiera och matcha användare/grupper mellan de två systemen.

Du kan anpassa standardattributmappningarna efter dina affärsbehov. Du kan därför ändra eller ta bort befintliga attributmappningar eller skapa nya attributmappningar. Mer information finns i Anpassa attributmappningar för användaretablering för SaaS-program.

När du konfigurerar etablering till ett SaaS-program är en av de typer av attributmappningar som du kan ange en uttrycksmappning. För dessa mappningar måste du skriva ett skriptliknande uttryck som gör att du kan omvandla användarnas data till format som är mer acceptabla för SaaS-programmet. Mer information finns i Skriva uttryck för attributmappningar.

Omfång

Tilldelningsbaserad omfång

För utgående etablering från Microsoft Entra-ID till ett SaaS-program är det vanligaste sättet att avgöra vilka användare som är i omfånget för etablering att förlita sig på användar- eller grupptilldelningar . Eftersom användartilldelningar också används för att aktivera enkel inloggning kan samma metod användas för att hantera både åtkomst och etablering. Tilldelningsbaserad omfång gäller inte för scenarier för inkommande etablering som Workday och Successfactors.

Grupper. Med en licensplan för Microsoft Entra ID P1 eller P2 kan du använda grupper för att tilldela åtkomst till ett SaaS-program. När etableringsomfånget sedan är inställt på Synkronisera endast tilldelade användare och grupper etablerar eller avetablerar Microsoft Entra-etableringstjänsten användare baserat på om de är medlemmar i en grupp som har tilldelats till programmet. Själva gruppobjektet etableras inte om inte programmet stöder gruppobjekt. Kontrollera att grupper som tilldelats ditt program har egenskapen "SecurityEnabled" inställd på "True".
Dynamiska grupper. Microsoft Entra-användaretableringstjänsten kan läsa och etablera användare i dynamiska medlemskapsgrupper. Tänk på följande varningar och rekommendationer:
- Dynamiska grupper kan påverka prestanda för etablering från slutpunkt till slutpunkt från Microsoft Entra-ID till SaaS-program.
- Hur snabbt en användare i en dynamisk grupp etableras eller avetableras i ett SaaS-program beror på hur snabbt den dynamiska gruppen kan utvärdera medlemskapsändringar. Information om hur du kontrollerar bearbetningsstatusen för en dynamisk grupp finns i Kontrollera bearbetningsstatus för en medlemskapsregel.
- När en användare förlorar medlemskap i den dynamiska gruppen betraktas det som en avetableringshändelse. Tänk på det här scenariot när du skapar regler för dynamiska medlemskapsgrupper.
Kapslade grupper. Microsoft Entra-tjänsten för användaretablering kan inte läsa eller etablera användare i kapslade grupper. Tjänsten kan bara läsa och etablera användare som är omedelbart medlemmar i en explicit tilldelad grupp. Den här begränsningen för "gruppbaserade tilldelningar till program" påverkar även enkel inloggning (se Använda en grupp för att hantera åtkomst till SaaS-program). Tilldela i stället direkt eller på annat sätt omfång i de grupper som innehåller de användare som behöver etableras.

Attributbaserad omfång

Du kan använda omfångsfilter för att definiera attributbaserade regler som avgör vilka användare som är etablerade i ett program. Den här metoden används ofta för inkommande etablering från HCM-program till Microsoft Entra ID och Active Directory. Omfångsfilter konfigureras som en del av attributmappningarna för varje Microsoft Entra-anslutningsapp för användaretablering. Mer information om hur du konfigurerar attributbaserade omfångsfilter finns i Attributbaserad programetablering med omfångsfilter.

B2B-användare (gäst)

Det är möjligt att använda Microsoft Entra-användaretableringstjänsten för att etablera B2B-användare (gäst) i Microsoft Entra-ID till SaaS-program. Men för att B2B-användare ska kunna logga in på SaaS-programmet med hjälp av Microsoft Entra-ID måste du manuellt konfigurera SaaS-programmet för att använda Microsoft Entra-ID som en SAML-identitetsprovider (Security Assertion Markup Language).

Följ dessa allmänna riktlinjer när du konfigurerar SaaS-appar för B2B-användare (gästanvändare):

För de flesta appar måste användarkonfigurationen ske manuellt. Användarna måste också skapas manuellt i appen.
För appar som stöder automatisk installation, till exempel Dropbox, skapas separata inbjudningar från apparna. Användarna måste vara noga med att acceptera varje inbjudan.
I användarattributen anger du alltid användaridentifieraren till user.mail för att minimera eventuella problem med manglad disk för användarprofil (UPD) i gästanvändare.

Kommentar

UserPrincipalName för en B2B-samarbetsanvändare representerar den externa användarens e-postadress alias@theirdomain som "alias_theirdomain#EXT#@yourdomain". När attributet userPrincipalName ingår i attributmappningarna som ett källattribut och en B2B-användare etableras tas #EXT# och domänen bort från userPrincipalName, så endast deras ursprungliga alias@theirdomain används för matchning eller etablering. Om du behöver det fullständiga användarens huvudnamn, inklusive #EXT# och din domän, ersätter du userPrincipalName med originalUserPrincipalName som källattribut.
userPrincipalName = alias@theirdomain
originalUserPrincipalName = alias_theirdomain#EXT#@yourdomain

Etableringscykler: Inledande och inkrementell

När Microsoft Entra ID är källsystemet använder etableringstjänsten deltafrågan för att spåra ändringar i Microsoft Graph-data för att övervaka användare och grupper. Etableringstjänsten kör en inledande cykel mot källsystemet och målsystemet, följt av periodiska inkrementella cykler.

Inledande cykel

När etableringstjänsten startas kommer den första cykeln att:

Fråga alla användare och grupper från källsystemet och hämta alla attribut som definierats i attributmappningarna.
Filtrera de användare och grupper som returneras med hjälp av eventuella konfigurerade tilldelningar eller attributbaserade omfångsfilter.
När en användare tilldelas eller i omfånget för etablering frågar tjänsten målsystemet efter en matchande användare med hjälp av de angivna matchande attributen. Exempel: Om userPrincipal-namnet i källsystemet är det matchande attributet och mappar till userName i målsystemet frågar etableringstjänsten målsystemet efter userNames som matchar userPrincipal-namnvärdena i källsystemet.
Om en matchande användare inte hittas i målsystemet skapas den med hjälp av attributen som returneras från källsystemet. När användarkontot har skapats identifierar och cachelagrar etableringstjänsten målsystemets ID för den nya användaren. Det här ID:t används för att köra alla framtida åtgärder på den användaren.
Om en matchande användare hittas uppdateras den med hjälp av attributen som tillhandahålls av källsystemet. När användarkontot har matchats identifierar och cachelagrar etableringstjänsten målsystemets ID för den nya användaren. Det här ID:t används för att köra alla framtida åtgärder på den användaren.
Om attributmappningarna innehåller "referensattribut" gör tjänsten fler uppdateringar i målsystemet för att skapa och länka de refererade objekten. En användare kan till exempel ha ett "Manager"-attribut i målsystemet, som är länkat till en annan användare som skapats i målsystemet.
Spara en vattenstämpel i slutet av den inledande cykeln, vilket ger startpunkten för de senare inkrementella cyklerna.

Vissa program som ServiceNow, G Suite och Box stöder inte bara etablering av användare, utan även etableringsgrupper och deras medlemmar. I dessa fall, om gruppetablering är aktiverat i mappningarna, synkroniserar etableringstjänsten användarna och grupperna och synkroniserar sedan den dynamiska medlemskapsgruppen senare.

Inkrementella cykler

Efter den inledande cykeln kommer alla andra cykler att:

Fråga källsystemet efter alla användare och grupper som har uppdaterats sedan den senaste vattenstämpeln lagrades.
Filtrera de användare och grupper som returneras med hjälp av eventuella konfigurerade tilldelningar eller attributbaserade omfångsfilter.
När en användare tilldelas eller i omfånget för etablering frågar tjänsten målsystemet efter en matchande användare med hjälp av de angivna matchande attributen.
Om en matchande användare inte hittas i målsystemet skapas den med hjälp av attributen som returneras från källsystemet. När användarkontot har skapats identifierar och cachelagrar etableringstjänsten målsystemets ID för den nya användaren. Det här ID:t används för att köra alla framtida åtgärder på den användaren.
Om en matchande användare hittas uppdateras den med hjälp av attributen som tillhandahålls av källsystemet. Om det är ett nyligen tilldelat konto som matchas identifierar och cachelagrar etableringstjänsten målsystemets ID för den nya användaren. Det här ID:t används för att köra alla framtida åtgärder på den användaren.
Om attributmappningarna innehåller "referensattribut" gör tjänsten fler uppdateringar i målsystemet för att skapa och länka de refererade objekten. En användare kan till exempel ha ett "Manager"-attribut i målsystemet, som är länkat till en annan användare som skapats i målsystemet.
Om en användare som tidigare fanns i omfånget för etablering tas bort från omfånget, inklusive att den inte har tilldelats, inaktiverar tjänsten användaren i målsystemet via en uppdatering.
Om en användare som tidigare fanns i omfånget för etablering inaktiveras eller tas bort mjukt i källsystemet inaktiverar tjänsten användaren i målsystemet via en uppdatering.
Om en användare som tidigare fanns i omfånget för etablering tas bort hårt i källsystemet, tar tjänsten bort användaren i målsystemet. I Microsoft Entra-ID är användarna hårt borttagna 30 dagar efter att de har tagits bort.
Spara en ny vattenstämpel i slutet av den inkrementella cykeln, vilket ger startpunkten för de senare inkrementella cyklerna.

Kommentar

Du kan också inaktivera kryssrutorna Skapa, Uppdatera eller Ta bort med hjälp av kryssrutorna Målobjektåtgärder i avsnittet Mappningar . Logiken för att inaktivera en användare under en uppdatering styrs också via en attributmappning från ett fält, till exempel accountEnabled.

Etableringstjänsten fortsätter att köra inkrementella back-to-back-cykler på obestämd tid, med intervall som definieras i självstudien som är specifika för varje program. Inkrementella cykler fortsätter tills någon av händelserna inträffar:

Tjänsten stoppas manuellt med hjälp av administrationscentret för Microsoft Entra eller med hjälp av lämpligt Microsoft Graph API-kommando.
En ny inledande cykel utlöses med hjälp av alternativet Starta om etablering i administrationscentret för Microsoft Entra eller med hjälp av lämpligt Microsoft Graph API-kommando. Åtgärden rensar alla lagrade vattenstämplar och gör att alla källobjekt utvärderas igen. Åtgärden bryter inte heller länkarna mellan käll- och målobjekt. Om du vill bryta länkarna använder du Starta om synkroniseringsjobbet med begäran:

POST https://graph.microsoft.com/beta/servicePrincipals/{id}/synchronization/jobs/{jobId}/restart
Authorization: Bearer <token>
Content-type: application/json
{
   "criteria": {
       "resetScope": "Full"
   }
}

En ny inledande cykel utlöses på grund av en ändring i attributmappningar eller omfångsfilter. Den här åtgärden rensar även alla lagrade vattenstämplar och gör att alla källobjekt utvärderas igen.
Etableringsprocessen hamnar i karantän (se exempel) på grund av en hög felfrekvens och förblir i karantän i mer än fyra veckor. I så fall inaktiveras tjänsten automatiskt.

Fel och återförsök

Om ett fel i målsystemet förhindrar att en enskild användare läggs till, uppdateras eller tas bort i målsystemet görs åtgärden igen i nästa synkroniseringscykel. Felen görs kontinuerligt igen, vilket gradvis skalar tillbaka frekvensen för återförsök. För att lösa felet måste administratörer kontrollera etableringsloggarna för att fastställa rotorsaken och vidta lämpliga åtgärder. Vanliga fel kan vara:

Användare som inte har ett attribut fyllt i källsystemet som krävs i målsystemet
Användare som har ett attributvärde i källsystemet där det finns en unik begränsning i målsystemet och samma värde finns i en annan användarpost

Lös dessa fel genom att justera attributvärdena för den berörda användaren i källsystemet eller genom att justera attributmappningarna så att de inte orsakar konflikter.

Karantän

Om de flesta eller alla anrop som görs mot målsystemet konsekvent misslyckas på grund av ett fel (till exempel ogiltiga administratörsautentiseringsuppgifter) hamnar etableringsjobbet i ett "karantäntillstånd". Det här tillståndet anges i rapporten för etableringssammanfattning och via e-post om e-postaviseringar har konfigurerats i administrationscentret för Microsoft Entra.

I karantän minskas frekvensen för inkrementella cykler gradvis till en gång per dag.

Etableringsjobbet avslutar karantänen när alla fel har åtgärdats och nästa synkroniseringscykel startar. Om etableringsjobbet ligger kvar i karantän i mer än fyra veckor inaktiveras etableringsjobbet. Läs mer här om karantänstatus här.

Hur lång tid tar etableringen?

Prestanda beror på om etableringsjobbet kör en inledande etableringscykel eller en inkrementell cykel. Mer information om hur lång tid etableringen tar och hur du övervakar statusen för etableringstjänsten finns i Kontrollera status för användaretablering.

Så här ser du om användarna etableras korrekt

Alla åtgärder som körs av användaretableringstjänsten registreras i Microsoft Entra Provisioning-loggarna. Loggarna innehåller alla läs- och skrivåtgärder som gjorts till käll- och målsystemen samt användardata som lästes eller skrevs under varje åtgärd. Information om hur du läser etableringsloggarna i administrationscentret för Microsoft Entra finns i guiden för etableringsrapportering.

Avetablering

Microsoft Entra-etableringstjänsten håller käll- och målsystemen synkroniserade genom att avetablera konton när användaråtkomst tas bort.

Etableringstjänsten stöder både borttagning och inaktivering (kallas ibland för mjuk borttagning). Den exakta definitionen av inaktivera och ta bort varierar beroende på målappens implementering, men vanligtvis indikerar en inaktivering att användaren inte kan logga in. En borttagning anger att användaren har tagits bort helt från programmet. För SCIM-program är en inaktivering en begäran om att ange den aktiva egenskapen till false för en användare.

Konfigurera programmet för att inaktivera en användare

Bekräfta att kryssrutan för uppdateringar är markerad.

Bekräfta mappningen för aktiv för ditt program. Om du använder ett program från appgalleriet kan mappningen skilja sig något. I det här fallet använder du standardmappningen för galleriprogram.

Konfigurera ditt program för att ta bort en användare

Scenariot utlöser en inaktivera eller en borttagning:

En användare tas bort mjukt i Microsoft Entra-ID (skickas till papperskorgen/egenskapen AccountEnabled inställd på false). Trettio dagar efter att en användare har tagits bort i Microsoft Entra-ID tas de bort permanent från klientorganisationen. Nu skickar etableringstjänsten en DELETE-begäran om att permanent ta bort användaren i programmet. När som helst under 30-dagarsfönstret kan du manuellt ta bort en användare permanent, vilket skickar en borttagningsbegäran till programmet.
En användare tas bort/tas bort permanent från papperskorgen i Microsoft Entra-ID.
En användare har inte tilldelats från en app.
En användare går från omfång till utanför omfånget (skickar inte ett omfångsfilter längre).

Som standard tar Microsoft Entra-etableringstjänsten bort eller inaktiverar användare som inte omfattas. Om du vill åsidosätta det här standardbeteendet kan du ange en flagga för att hoppa över borttagningar utanför omfånget.

När en av de fyra händelserna inträffar och målprogrammet inte stöder mjuk borttagning skickar etableringstjänsten en DELETE-begäran för att permanent ta bort användaren från appen.

Om du ser IsSoftDeleted i attributmappningarna används det för att fastställa användarens tillstånd och om du vill skicka en uppdateringsbegäran med active = false för att mjuk-ta bort användaren.

Avetableringshändelser

Tabellen beskriver hur du kan konfigurera avetableringsåtgärder med Microsoft Entra-etableringstjänsten. Dessa regler är skrivna med det icke-galleri-/anpassade programmet i åtanke, men gäller vanligtvis för program i galleriet. Beteendet för galleriprogram kan dock variera eftersom de har optimerats för att uppfylla programmets behov. Om målprogrammet till exempel inte stöder mjuk borttagning kan Microsoft Entra-etableringstjänsten skicka en begäran om hård borttagning för att ta bort användare i stället för att skicka en mjuk borttagning.

Scenario	Så här konfigurerar du i Microsoft Entra-ID
En användare har inte tilldelats från en app, tas bort med mjuk borttagning i Microsoft Entra-ID eller blockeras från inloggning. Du vill inte att något ska göras.	Ta bort `isSoftDeleted` från attributmappningarna och/eller ange egenskapen hoppa över borttagna omfång till true.
En användare har inte tilldelats från en app, tas bort med mjuk borttagning i Microsoft Entra-ID eller blockeras från inloggning. Du vill ange ett specifikt attribut till `true` eller `false`.	Mappa `isSoftDeleted` till attributet som du vill ange till false.
En användare är inaktiverad i Microsoft Entra-ID, otilldelad från en app, mjuk borttagning i Microsoft Entra-ID eller blockerad från inloggning. Du vill skicka en DELETE-begäran till målprogrammet.	Detta stöds för närvarande för en begränsad uppsättning galleriprogram där funktionerna krävs. Det kan inte konfigureras av kunder.
En användare tas bort i Microsoft Entra-ID. Du vill inte att något ska göras i målprogrammet.	Se till att "Ta bort" inte har valts som en av målobjektåtgärderna i attributkonfigurationen.
En användare tas bort i Microsoft Entra-ID. Du vill ange värdet för ett attribut i målprogrammet.	Stöds ej.
En användare tas bort i Microsoft Entra-ID. Du vill ta bort användaren i målprogrammet	Se till att Ta bort är markerat som en av målobjektåtgärderna i attributkonfigurationsmiljön.

Kända begränsningar

När en användare eller grupp inte har tilldelats från en app och inte längre hanteras med etableringstjänsten skickas en inaktiverad begäran. Då hanterar inte tjänsten användaren och en borttagningsbegäran skickas inte när användaren tas bort mjukt från katalogen.
Etablering av en användare som är inaktiverad i Microsoft Entra-ID stöds inte. De måste vara aktiva i Microsoft Entra-ID innan de etableras.
När en användare går från mjuk borttagen till aktiv aktiverar Microsoft Entra-etableringstjänsten användaren i målappen, men återställer inte automatiskt den dynamiska medlemskapsgruppen. Målprogrammet ska underhålla den dynamiska medlemskapsgruppen för användaren i inaktivt tillstånd. Om målprogrammet inte har stöd för att upprätthålla det inaktiva tillståndet kan du starta om etableringen för att uppdatera de dynamiska medlemskapsgrupperna.

Rekommendation

När du utvecklar ett program har du alltid stöd för både mjuk borttagning och hårda borttagningar. Det gör det möjligt för kunder att återställa när en användare av misstag inaktiveras.

Nästa steg

Planera en automatisk distribution av användaretablering

Konfigurera etablering för en galleriapp

Skapa en SCIM-slutpunkt och konfigurera etablering när du skapar en egen app

Felsöka problem med att konfigurera och etablera användare i ett program.

Dela via