Så här fungerar programetablering i Azure Active Directory

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 omfattar 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 Azure AD-etablering fungerar och få konfigurationsrekommendationer.

Azure AD Provisioning Service etablerar användare till SaaS-appar och andra system genom att ansluta till ett system för IDENTITETshantering mellan domäner (SCIM) 2.0-slutpunkten för användarhantering som tillhandahålls av programleverantören. Med den här SCIM-slutpunkten kan Azure AD programmatiskt skapa, uppdatera och ta bort användare. För valda program kan etableringstjänsten även skapa, uppdatera och ta bort ytterligare identitetsrelaterade objekt, till exempel grupper och roller. Kanalen som används för etablering mellan Azure AD och programmet krypteras med HTTPS TLS 1.2-kryptering.

bild 1: Azure AD-etableringstjänsten

Bild 2: Arbetsflöde för "utgående" användareablering från Azure AD till populära SaaS-program

HCM-program (Human Capital Management) till Azure Active Directory och Windows Server Active Directory

Etablering med SCIM 2.0

Azure AD-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 finns för de flesta program i Azure AD-galleriet. När du skapar appar för Azure AD kan utvecklare använda SCIM 2.0-api:et för användarhantering för att skapa en SCIM-slutpunkt som integrerar Azure AD för etablering. Mer information finns i Skapa en SCIM-slutpunkt och konfigurera användareablering.

Om du vill begära en automatisk Anslutningsapp för Azure AD-etablering för en app som för närvarande inte har någon, fyller du i en Azure Active Directory-programbegäran.

Auktorisering

Autentiseringsuppgifter krävs för att Azure AD ska kunna ansluta till programmets API för användarhantering. När du konfigurerar automatisk användareablering 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 app-självstudien. För program som inte är gallerier kan du läsa SCIM-dokumentationen för att förstå autentiseringstyperna och kraven. I Azure Portal du testa autentiseringsuppgifterna genom att azure AD försöker ansluta till appens etableringsapp med de angivna autentiseringsuppgifterna.

Mappa attribut

När du aktiverar användareablering för ett SaaS-program från tredje part kontrollerar Azure Portal attributvärdena via attributmappningar. Mappningar avgör vilka användarattribut som flödar mellan Azure AD och målprogrammet när användarkonton etableras eller uppdateras.

Det finns en förkonfigurerad uppsättning attribut och attributmappningar mellan Azure AD-användarobjekt och varje SaaS-appanvä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 gruppegenskaper) som flödar från Azure AD till programmet. Granska och konfigurera den matchande egenskapen (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ändareablering 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 godtagbara för SaaS-programmet. Mer information finns i Skriva uttryck för attributmappningar.

Miljöprövningens

Tilldelningsbaserad omfångsomfång

För utgående etablering från Azure AD till ett SaaS-program är det vanligaste sättet att avgöra vilka användare som omfattas av etableringen 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ångsomfång gäller inte för inkommande etableringsscenarier som Workday och Successfactors.

• Grupper. Med en Azure AD Premium licensplan kan du använda grupper för att tilldela åtkomst till ett SaaS-program. När etableringsomfånget sedan anges till Synkronisera endast tilldelade användare och grupper etablerar eller avetabler azure AD-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. Se till att grupper som tilldelats ditt program har egenskapen "SecurityEnabled" inställd på "True".

• Dynamiska grupper. Azure AD-tjänsten för användareablering kan läsa och etablera användare i dynamiska grupper. Tänk på följande varningar och rekommendationer:

  • Dynamiska grupper kan påverka prestandan för etablering från Azure AD 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 grupper.

• Kapslade grupper. Azure AD-tjänsten för användareablering kan inte läsa eller etablera användare i kapslade grupper. Tjänsten kan bara läsa och etablera användare som är omedelbara medlemmar i en explicit tilldelad grupp. Den här begränsningen av "gruppbaserade tilldelningar till program" påverkar också enkel inloggning (se Använda en grupp för att hantera åtkomst till SaaS-program). Tilldela i stället omfånget direkt eller på annat sätt i de grupper som innehåller de användare som behöver etableras.

Attributbaserad omfångsomfå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 Azure AD och Active Directory. Omfångsfilter konfigureras som en del av attributmappningarna för varje anslutningsapp för Azure AD-användareablering. Mer information om hur du konfigurerar attributbaserade omfångsfilter finns i Attributbaserad programetablering med omfångsfilter.

B2B-användare (gäst)

Det går att använda Azure AD-tjänsten för användareablering för att etablera B2B-användare (eller gästanvändare) i Azure AD till SaaS-program. Men för att B2B-användare ska kunna logga in på SaaS-programmet med Azure AD måste SaaS-programmet ha sin SAML-baserade funktion för enkel inloggning konfigurerad på ett visst sätt. Mer information om hur du konfigurerar SaaS-program för att stödja inloggningar från B2B-användare finns i Konfigurera SaaS-appar för B2B-samarbete.

userPrincipalName för en gästanvändare visas ofta som "alias#EXT# @domain.com ". När userPrincipalName ingår i dina attributmappningar som ett källattribut tas #EXT# bort från userPrincipalName. Om du vill att #EXT# ska finnas ersätter du userPrincipalName med originalUserPrincipalName som källattribut.

userPrincipalName = alias@domain.com originalUserPrincipalName = alias#EXT #@domain.com

Etableringscykler: Initial och inkrementell

När Azure AD är källsystemet använder etableringstjänsten använd deltafrågan för att spåra ändringar i Microsoft Graph 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:

1. Fråga alla användare och grupper från källsystemet och hämta alla attribut som definierats i attributmappningarna.

2. Filtrera de användare och grupper som returneras med hjälp av alla konfigurerade tilldelningar eller attributbaserade omfångsfilter.

3. När en användare tilldelas eller ingår i etableringen 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 användarnamn som matchar userPrincipal-namnvärdena i källsystemet.

4. Om en matchande användare inte hittas i målsystemet skapas den med hjälp av de attribut 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. Detta ID används för att köra alla framtida åtgärder på den användaren.

5. Om en matchande användare hittas uppdateras den med hjälp av de attribut som tillhandahålls av källsystemet. När användarkontot matchas identifierar och cachelagrar etableringstjänsten målsystemets ID för den nya användaren. Detta ID används för att köra alla framtida åtgärder på den användaren.

6. Om attributmappningarna innehåller "referensattribut" gör tjänsten ytterligare 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.

7. Spara en vattenstämpel i slutet av den inledande cykeln, vilket utgör startpunkten för senare inkrementella cykler.

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 har aktiveratsi mappningarna , synkroniserar etableringstjänsten användarna och grupperna och synkroniserar sedan gruppmedlemskapen senare.

Inkrementella cykler

Efter den inledande cykeln kommer alla andra cykler att:

1. Fråga källsystemet efter alla användare och grupper som har uppdaterats sedan den senaste vattenstämpeln lagrades.

2. Filtrera de användare och grupper som returneras med hjälp av alla konfigurerade tilldelningar eller attributbaserade omfångsfilter.

3. När en användare tilldelas eller ingår i etableringen frågar tjänsten målsystemet efter en matchande användare med hjälp av de angivna matchande attributen.

4. Om en matchande användare inte hittas i målsystemet skapas den med hjälp av de attribut 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. Detta ID används för att köra alla framtida åtgärder på den användaren.

5. Om en matchande användare hittas uppdateras den med hjälp av de attribut 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. Detta ID används för att köra alla framtida åtgärder på den användaren.

6. Om attributmappningarna innehåller "referensattribut" gör tjänsten ytterligare 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.

7. Om en användare som tidigare var i omfånget för etablering tas bort från omfånget, inklusive otilldelade, inaktiverar tjänsten användaren i målsystemet via en uppdatering.

8. Om en användare som tidigare var i omfånget för etablering är inaktiverad eller mjuk borttagning i källsystemet inaktiverar tjänsten användaren i målsystemet via en uppdatering.

9. Om en användare som tidigare var i omfånget för etablering är hård borttagning i källsystemet, tar tjänsten bort användaren i målsystemet. I Azure AD tas användarna bort permanent 30 dagar efter att de har mjuk borttagning.

10. Spara en ny vattenstämpel i slutet av den inkrementella cykeln, som utgör startpunkten för de senare inkrementella cyklerna.

Etableringstjänsten fortsätter att köra inkrementella cykler bakåt till bakåt 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 följande händelser inträffar:

• Tjänsten stoppas manuellt med hjälp av Azure Portal eller med lämpligt Microsoft Graph API-kommando.
• En ny inledande cykel utlöses med hjälp av alternativet Starta om etablering i Azure Portal eller med lämpligt Microsoft Graph API-kommando. Den här åtgärden rensar alla lagrade vattenstämplar och gör att alla källobjekt utvärderas igen.
• En ny inledande cykel utlöses på grund av en ändring i attributmappningar eller omfångsfilter. Den här åtgärden rensar även eventuell lagrad vattenstämpel och gör att alla källobjekt utvärderas igen.
• Etableringsprocessen försättas i karantän (se nedan) 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, utförs åtgärden igen i nästa synkroniseringscykel. Felen försöks kontinuerligt igen och skalar gradvis 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 ifylld 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 de här felen 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 etableringssammanfattningsrapporten och via e-post om e-postmeddelanden har konfigurerats i Azure Portal.

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

Etableringsjobbet avslutas i karantän när alla felaktiga fel har åtgärdats och nästa synkroniseringscykel startar. Om etableringsjobbet finns 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 status för etableringstjänsten finns i Kontrollera status för användareablering.

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

Alla åtgärder som körs av användaretableringstjänsten registreras i Azure AD-etableringsloggarna (förhandsversion). 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 Azure Portal finns i etableringsrapporteringsguiden.

Avetablering

Azure AD-etableringstjänsten synkroniserar käll- och målsystemen genom att avetableringskonton när användaråtkomst tas bort.

Etableringstjänsten stöder både borttagning och inaktivering av användare (kallas ibland 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 ditt program för att inaktivera en användare

Kontrollera att du har markerat kryssrutan för uppdateringar.

Kontrollera att mappningen är aktiv för ditt program. Om du använder ett program från appgalleriet kan mappningen vara något annorlunda. Se till att du använder standard-/standardmappningen för galleriprogram.

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

Följande scenarier utlöser en inaktivering eller borttagning:

• En användare tas bort mjuk i Azure AD (skickas till papperskorgen/AccountEnabled-egenskapen inställd på falskt). 30 dagar efter att en användare har tagits bort i Azure AD tas de bort permanent från klientorganisationen. I det här läget skickar etableringstjänsten en DELETE-begäran för att permanent ta bort användaren i programmet. Du kan ta bort en användare permanent när som helst under 30-dagarsfönstret, vilket skickar en borttagningsbegäran till programmet.
• En användare tas bort permanent från papperskorgen i Azure AD.
• En användare har inte tilldelats från en app.
• En användare går från inomfång till utanför omfånget (skickar inte ett omfångsfilter längre).

Som standard tar Azure AD-etableringstjänsten bort mjuk borttagning 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.

Om någon av ovanstående fyra händelser inträffar och målprogrammet inte stöder mjuka borttagningar skickar etableringstjänsten en DELETE-begäran för att permanent ta bort användaren från appen.

Om du ser attributet IsSoftDeleted i attributmappningarna används det för att fastställa användarens tillstånd och om du vill skicka en uppdateringsbegäran med aktiv = falskt för att mjuk borttagning av användaren.

Kända begränsningar

• Om en användare som tidigare hanterades av etableringstjänsten inte är tilldelad från en app, eller från en grupp som tilldelats en app, skickar vi en inaktiveringsbegäran. Användaren hanteras då inte av tjänsten och vi skickar ingen borttagningsbegäran när de tas bort från katalogen.
• Etablering av en användare som är inaktiverad i Azure AD stöds inte. De måste vara aktiva i Azure AD innan de etableras.
• När en användare går från mjuk borttagning till aktiv aktiverar Azure AD-etableringstjänsten användaren i målappen, men återställer inte gruppmedlemskapen automatiskt. Målprogrammet ska behålla gruppmedlemskapen för användaren i inaktivt tillstånd. Om målprogrammet inte stöder detta kan du starta om etableringen för att uppdatera gruppmedlemskapen.

Rekommendation

När du utvecklar ett program ska du alltid ha stöd för både mjuka borttagningar och hårda borttagningar. Det gör att kunder kan återställa när en användare har inaktiverats av misstag.

Nästa steg

Planera en distribution med automatisk användaretablering

Konfigurera etablering för en galleriapp

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

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