Hoe toepassings provisioning werkt in Azure Active Directory

Automatisch inrichten verwijst naar het maken van gebruikersidentiteiten en -rollen in de cloudtoepassingen waar gebruikers toegang tot nodig hebben. Naast het maken van gebruikersidentiteiten omvat automatische inrichting het onderhoud en de verwijdering van gebruikersidentiteiten, zoals gewijzigde status of rollen. Voordat u een implementatie start, kunt u dit artikel lezen om te leren hoe Azure AD-inrichting werkt en om aanbevelingen voor de configuratie te krijgen.

De Azure AD Provisioning Service biedt gebruikers de beschikking over SaaS-apps en andere systemen door verbinding te maken met een system for Cross-Domain Identity Management (SCIM) 2.0 USER Management API-eindpunt dat wordt geleverd door de leverancier van de toepassing. Met dit SCIM-eindpunt kan Azure AD programmatisch gebruikers maken, bijwerken en verwijderen. Voor geselecteerde toepassingen kan de inrichtingsservice ook aanvullende identiteitsgerelateerde objecten, zoals groepen en rollen, maken, bijwerken en verwijderen. Het kanaal dat wordt gebruikt voor het inrichten tussen Azure AD en de toepassing, wordt versleuteld met HTTPS TLS 1.2-versleuteling.

AD-inrichtingsservice: De Azure AD-inrichtingsservice

Azure AD naar populaire SaaS-toepassingen

HCM-toepassingen (Human Capital Management) naar Azure Active Directory en Windows Server Active Directory

Inrichten met SCIM 2.0

De Azure AD-inrichtingsservice maakt gebruik van het SCIM 2.0-protocol voor automatische inrichting. De service maakt verbinding met het SCIM-eindpunt voor de toepassing en gebruikt SCIM-gebruikersobjectschema en REST API's om het inrichten en de inrichting van gebruikers en groepen te automatiseren. Voor de meeste toepassingen in de Azure AD-galerie wordt een op SCIM gebaseerde inrichtingsconnector geleverd. Bij het bouwen van apps voor Azure AD kunnen ontwikkelaars de SCIM 2.0-API voor gebruikersbeheer gebruiken om een SCIM-eindpunt te bouwen dat Azure AD integreert voor inrichting. Zie Een SCIM-eindpunt bouwen en gebruikersinrichten configureren voor meer informatie.

Als u een automatische Azure AD-inrichtingsconnector wilt aanvragen voor een app die er momenteel geen heeft, vult u een aanvraag in Azure Active Directory Toepassingsaanvraag.

Autorisatie

Azure AD heeft referenties nodig om verbinding te maken met de API voor gebruikersbeheer van de toepassing. Terwijl u automatische inrichting van gebruikers configureert voor een toepassing, moet u geldige referenties invoeren. Voor galerietoepassingen kunt u referentietypen en vereisten voor de toepassing vinden door te verwijzen naar de zelfstudie over de app. Voor toepassingen buiten de galerie raadpleegt u de SCIM-documentatie om inzicht te krijgen in de referentietypen en -vereisten. In de Azure Portal kunt u de referenties testen door Azure AD te laten proberen verbinding te maken met de inrichtings-app van de app met behulp van de opgegeven referenties.

Toewijzingskenmerken

Wanneer u het inrichten van gebruikers voor een SaaS-toepassing van derden inschakelen, Azure Portal de kenmerkwaarden door middel van kenmerktoewijzingen. Toewijzingen bepalen de gebruikerskenmerken die tussen Azure AD en de doeltoepassing stromen wanneer gebruikersaccounts worden ingericht of bijgewerkt.

Er is een vooraf geconfigureerde set kenmerken en kenmerktoewijzingen tussen Azure AD-gebruikersobjecten en de gebruikersobjecten van elke SaaS-app. Sommige apps beheren andere typen objecten naast gebruikersobjecten, zoals objecten voor groepen.

Bij het instellen van de inrichting is het belangrijk om de kenmerktoewijzingen en werkstromen te controleren en te configureren waarmee wordt bepaald welke gebruikerseigenschappen (of groep)-eigenschappen van Azure AD naar de toepassing stromen. Controleer en configureer de overeenkomende eigenschap (Objecten matchen met behulp van dit kenmerk ) die wordt gebruikt om gebruikers/groepen uniek te identificeren en te matchen tussen de twee systemen.

U kunt de standaardtoewijzingen van kenmerken aanpassen op basis van de behoeften van uw bedrijf. Dit betekent dat u bestaande kenmerktoewijzingen kunt wijzigen of verwijderen, of nieuwe kenmerktoewijzingen kunt maken. Zie Customizing user provisioning attribute-mappings for SaaS applications (Kenmerktoewijzingen voor het inrichten van gebruikers aanpassen voor SaaS-toepassingen) voor meer informatie.

Wanneer u inrichting voor een SaaS-toepassing configureert, is een van de typen kenmerktoewijzingen die u kunt opgeven een expressietoewijzing. Voor deze toewijzingen moet u een script-achtige expressie schrijven waarmee u de gegevens van uw gebruikers kunt transformeren in indelingen die acceptabeler zijn voor de SaaS-toepassing. Zie Expressies schrijven voor kenmerktoewijzingen voor meer informatie.

Scoping

Bereik op basis van toewijzing

Voor uitgaande inrichting van Azure AD naar een SaaS-toepassing is het afhankelijk zijn van gebruikers- of groepstoewijzingen de meest voorkomende manier om te bepalen welke gebruikers binnen het bereik voor inrichting vallen. Omdat gebruikerstoewijzingen ook worden gebruikt voor het inschakelen van een aanmelding, kan dezelfde methode worden gebruikt voor het beheren van zowel toegang als inrichting. Bereik op basis van toewijzingen is niet van toepassing op scenario's voor inkomende inrichting, zoals Workday en Successfactors.

• Groepen. Met een Azure AD Premium kunt u groepen gebruiken om toegang tot een SaaS-toepassing toe te wijzen. Wanneer het inrichtingsbereik vervolgens is ingesteld op Alleen toegewezen gebruikers en groepen synchroniseren, zal de Azure AD-inrichtingsservice gebruikers inrichten of de inrichting ervan op basis van het feit of ze lid zijn van een groep die is toegewezen aan de toepassing. Het groepsobject zelf is niet ingericht, tenzij de toepassing ondersteuning biedt voor groepsobjecten. Zorg ervoor dat voor groepen die zijn toegewezen aan uw toepassing de eigenschap SecurityEnabled is ingesteld op Waar.

• Dynamische groepen. Met de Azure AD-service voor het inrichten van gebruikers kunnen gebruikers in dynamische groepen worden gelezen en ingericht. Houd rekening met deze waarschuwingen en aanbevelingen:

  • Dynamische groepen kunnen van invloed zijn op de prestaties van end-to-end inrichting van Azure AD naar SaaS-toepassingen.

  • Hoe snel een gebruiker in een dynamische groep wordt ingericht of de inrichting ervan in een SaaS-toepassing wordt beëindigd, is afhankelijk van hoe snel de dynamische groep lidmaatschapswijzigingen kan evalueren. Zie Verwerkingsstatus controleren voor een lidmaatschapsregel voor informatie over het controleren van de verwerkingsstatus van een dynamische groep.

  • Wanneer een gebruiker het lidmaatschap van de dynamische groep verliest, wordt dit beschouwd als een gebeurtenis voor het uitrichten. Houd rekening met dit scenario bij het maken van regels voor dynamische groepen.

• Geneste groepen. De Azure AD-service voor het inrichten van gebruikers kan geen gebruikers in geneste groepen lezen of inrichten. De service kan alleen gebruikers lezen en inrichten die direct lid zijn van een expliciet toegewezen groep. Deze beperking van 'toewijzingen aan toepassingen op basis van groepen' is ook van invloed op een aanmelding (zie Een groep gebruiken om toegang tot SaaS-toepassingen te beheren). Wijs in plaats daarvan rechtstreeks of anderszins een bereik toe aan de groepen die de gebruikers bevatten die moeten worden ingericht.

Bereik op basis van kenmerken

U kunt bereikfilters gebruiken om op kenmerken gebaseerde regels te definiëren die bepalen welke gebruikers worden ingericht voor een toepassing. Deze methode wordt vaak gebruikt voor inkomende inrichting van HCM-toepassingen naar Azure AD en Active Directory. Bereikfilters worden geconfigureerd als onderdeel van de kenmerktoewijzingen voor elke Azure AD-connector voor het inrichten van gebruikers. Zie Op kenmerken gebaseerde toepassing inrichten met bereikfilters voor meer informatie over het configureren van bereikfilters op basis van kenmerken.

B2B-gebruikers (gast)

Het is mogelijk om de Azure AD-service voor het inrichten van gebruikers te gebruiken om B2B-gebruikers (of gastgebruikers) in Azure AD in te leveren voor SaaS-toepassingen. B2B-gebruikers kunnen zich echter alleen aanmelden bij de SaaS-toepassing met behulp van Azure AD als voor de SaaS-toepassing een op SAML gebaseerde mogelijkheid voor een specifieke aanmelding is geconfigureerd. Zie SaaS-apps configureren voor B2B-samenwerking voor meer informatie over het configureren van SaaS-toepassingen ter ondersteuning van aanmeldingen van B2B-gebruikers.

De userPrincipalName voor een gastgebruiker wordt vaak weergegeven als 'alias#EXT# @domain.com '. Wanneer de userPrincipalName is opgenomen in uw kenmerktoewijzingen als een bronkenmerk, wordt de #EXT# verwijderd uit de userPrincipalName. Als u wilt dat #EXT# aanwezig is, vervangt u userPrincipalName door originalUserPrincipalName als het bronkenmerk.

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

Inrichtingscycli: Eerste en incrementele

Wanneer Azure AD het bronsysteem is, gebruikt de inrichtingsservice de Delta-query gebruiken om wijzigingen in Microsoft Graph bij te houden voor het bewaken van gebruikers en groepen. De inrichtingsservice voert een eerste cyclus uit op basis van het bronsysteem en doelsysteem, gevolgd door periodieke incrementele cycli.

Initiële cyclus

Wanneer de inrichtingsservice wordt gestart, wordt de eerste cyclus:

1. Een query uitvoeren op alle gebruikers en groepen van het bronsysteem en alle kenmerken ophalen die zijn gedefinieerd in de kenmerktoewijzingen.

2. Filter de geretourneerde gebruikers en groepen met behulp van geconfigureerde toewijzingen of bereikfilters op basis van kenmerken.

3. Wanneer een gebruiker is toegewezen of binnen het bereik voor inrichting, vraagt de service het doelsysteem op naar een overeenkomende gebruiker met behulp van de opgegeven overeenkomende kenmerken. Voorbeeld: als de userPrincipal-naam in het bronsysteem het overeenkomende kenmerk is en wordt toe te staan aan userName in het doelsysteem, wordt met de inrichtingsservice een query op het doelsysteem opgevraagd voor userNames die overeenkomen met de waarden van de userPrincipal-naam in het bronsysteem.

4. Als er geen overeenkomende gebruiker in het doelsysteem wordt gevonden, wordt deze gemaakt met behulp van de kenmerken die worden geretourneerd door het bronsysteem. Nadat het gebruikersaccount is gemaakt, detecteert en cachet de inrichtingsservice de id van het doelsysteem voor de nieuwe gebruiker. Deze id wordt gebruikt om alle toekomstige bewerkingen voor die gebruiker uit te voeren.

5. Als er een overeenkomende gebruiker wordt gevonden, wordt deze bijgewerkt met behulp van de kenmerken van het bronsysteem. Nadat het gebruikersaccount is gematcht, detecteert en cachet de inrichtingsservice de id van het doelsysteem voor de nieuwe gebruiker. Deze id wordt gebruikt om alle toekomstige bewerkingen voor die gebruiker uit te voeren.

6. Als de kenmerktoewijzingen 'verwijzingskenmerken' bevatten, brengt de service aanvullende updates uit op het doelsysteem om de objecten waarnaar wordt verwezen te maken en te koppelen. Een gebruiker kan bijvoorbeeld het kenmerk Manager hebben in het doelsysteem, dat is gekoppeld aan een andere gebruiker die in het doelsysteem is gemaakt.

7. Een watermerk aan het einde van de initiële cyclus persistent maken, waarmee het beginpunt voor de latere incrementele cycli wordt gegeven.

Sommige toepassingen, zoals ServiceNow, G Suite en Box, bieden niet alleen ondersteuning voor het inrichten van gebruikers, maar ook voor het inrichten van groepen en hun leden. Als groeps inrichting is ingeschakeld in de toewijzingen, synchroniseert de inrichtingsservicein dat geval de gebruikers en de groepen en synchroniseert deze vervolgens de groepslidmaatschap.

Incrementele cycli

Na de initiële cyclus zullen alle andere cycli het volgende doen:

1. Zoek in het bronsysteem naar gebruikers en groepen die zijn bijgewerkt sinds het laatste watermerk is opgeslagen.

2. Filter de geretourneerde gebruikers en groepen met behulp van geconfigureerde toewijzingen of bereikfilters op basis van kenmerken.

3. Wanneer een gebruiker is toegewezen of binnen het bereik voor inrichting, vraagt de service het doelsysteem op naar een overeenkomende gebruiker met behulp van de opgegeven overeenkomende kenmerken.

4. Als er geen overeenkomende gebruiker in het doelsysteem wordt gevonden, wordt deze gemaakt met behulp van de kenmerken die worden geretourneerd door het bronsysteem. Nadat het gebruikersaccount is gemaakt, detecteert en cachet de inrichtingsservice de id van het doelsysteem voor de nieuwe gebruiker. Deze id wordt gebruikt om alle toekomstige bewerkingen op die gebruiker uit te voeren.

5. Als er een overeenkomende gebruiker wordt gevonden, wordt deze bijgewerkt met behulp van de kenmerken van het bronsysteem. Als er een overeenkomend nieuw toegewezen account is, detecteert en cachet de inrichtingsservice de id van het doelsysteem voor de nieuwe gebruiker. Deze id wordt gebruikt om alle toekomstige bewerkingen op die gebruiker uit te voeren.

6. Als de kenmerktoewijzingen 'verwijzingskenmerken' bevatten, brengt de service aanvullende updates uit op het doelsysteem om de objecten waarnaar wordt verwezen te maken en te koppelen. Een gebruiker kan bijvoorbeeld het kenmerk Manager hebben in het doelsysteem, dat is gekoppeld aan een andere gebruiker die is gemaakt in het doelsysteem.

7. Als een gebruiker die eerder binnen het bereik voor inrichting stond, wordt verwijderd uit het bereik, inclusief niet-toegewezen, schakelt de service de gebruiker in het doelsysteem uit via een update.

8. Als een gebruiker die eerder binnen het bereik voor inrichting stond, is uitgeschakeld of als deze in het bronsysteem wordt verwijderd, schakelt de service de gebruiker in het doelsysteem uit via een update.

9. Als een gebruiker die eerder binnen het bereik voor inrichting stond, in het bronsysteem hard wordt verwijderd, wordt de gebruiker in het doelsysteem door de service verwijderd. In Azure AD worden gebruikers 30 dagen nadat ze zijn verwijderd, hard verwijderd.

10. Behoudt een nieuw watermerk aan het einde van de incrementele cyclus, die het beginpunt vormt voor de latere incrementele cycli.

De inrichtingsservice blijft incrementele back-to-back-cycli voor onbepaalde tijd uitvoeren, met intervallen die zijn gedefinieerd in de zelfstudie die specifiek is voor elke toepassing. Incrementele cycli worden voortgezet totdat een van de volgende gebeurtenissen plaatsvindt:

• De service wordt handmatig gestopt met het Azure Portal of met behulp van de juiste Microsoft Graph API-opdracht.
• Er wordt een nieuwe initiële cyclus geactiveerd met behulp van de optie Inrichting opnieuw opstarten in de Azure Portal of met de juiste Microsoft Graph API-opdracht. Met deze actie worden alle opgeslagen watermerken geweerd en worden alle bronobjecten opnieuw geëvalueerd.
• Een nieuwe initiële cyclus wordt geactiveerd vanwege een wijziging in kenmerktoewijzingen of bereikfilters. Met deze actie worden ook alle opgeslagen watermerken geweerd en worden alle bronobjecten opnieuw geëvalueerd.
• Het inrichtingsproces gaat in quarantaine (zie hieronder) vanwege een hoog foutpercentage en blijft meer dan vier weken in quarantaine. In dit geval wordt de service automatisch uitgeschakeld.

Fouten en nieuwe fouten

Als een fout in het doelsysteem voorkomt dat een afzonderlijke gebruiker wordt toegevoegd, bijgewerkt of verwijderd in het doelsysteem, wordt de bewerking opnieuw uitgevoerd in de volgende synchronisatiecyclus. De fouten worden voortdurend opnieuw proberen uit te proberen, en de frequentie van nieuwe keren wordt geleidelijk teruggeschaald. Beheerders moeten de inrichtingslogboeken controleren om de hoofdoorzaak te achterhalen en de juiste actie te ondernemen om de fout op te lossen. Veelvoorkomende fouten kunnen zijn:

• Gebruikers hebben geen kenmerk ingevuld in het bronsysteem dat is vereist in het doelsysteem
• Gebruikers met een kenmerkwaarde in het bronsysteem waarvoor het doelsysteem een unieke beperking heeft, en dezelfde waarde is aanwezig in een andere gebruikersrecord

Los deze fouten op door de kenmerkwaarden voor de betrokken gebruiker in het bronsysteem aan te passen of door de kenmerktoewijzingen aan te passen zodat deze geen conflicten veroorzaken.

Quarantaine

Als de meeste of alle aanroepen die worden gedaan op het doelsysteem consistent mislukken vanwege een fout (bijvoorbeeld ongeldige beheerdersreferenties), wordt de inrichtings job in quarantaine geplaatst. Deze status wordt aangegeven in het overzichtsrapport van de inrichting en via e-mail als er e-mailmeldingen zijn geconfigureerd in de Azure Portal.

In quarantaine wordt de frequentie van incrementele cycli geleidelijk gereduceerd tot één keer per dag.

De inrichtings job sluit quarantaine nadat alle fouten zijn opgelost en de volgende synchronisatiecyclus wordt gestart. Als de inrichtings job langer dan vier weken in quarantaine blijft, wordt de inrichtings job uitgeschakeld. Meer informatie over de quarantainestatus kunt u hier vinden.

Hoelang inrichten duurt

De prestaties zijn afhankelijk van of uw inrichtings job een initiële inrichtingscyclus of een incrementele cyclus wordt uitgevoerd. Zie De status van het inrichten van gebruikers controleren voor meer informatie over hoe lang het inrichten duurt en hoe u de status van de inrichtingsservice kunt controleren.

Zien of gebruikers juist worden ingericht

Alle bewerkingen die worden uitgevoerd door de service voor het inrichten van gebruikers, worden vastgelegd in de Azure AD-inrichtingslogboeken (preview). De logboeken bevatten alle lees- en schrijfbewerkingen die worden uitgevoerd naar de bron- en doelsystemen, en de gebruikersgegevens die tijdens elke bewerking zijn gelezen of geschreven. Zie de gids voor inrichtingsrapportage voor meer informatie over het lezen van de inrichtingslogboeken in de Azure Portal.

Inrichting op de lange termijn inrichten

De Azure AD-inrichtingsservice zorgt ervoor dat bron- en doelsystemen gesynchroniseerd blijven door het inrichten van accounts op te gesynchroniseerd wanneer gebruikerstoegang wordt verwijderd.

De inrichtingsservice ondersteunt zowel het verwijderen als uitschakelen (ook wel soft-deleting genoemd) gebruikers. De exacte definitie van uitschakelen en verwijderen is afhankelijk van de implementatie van de doel-app, maar over het algemeen geeft een uitschakelen aan dat de gebruiker zich niet kan aanmelden. Een delete geeft aan dat de gebruiker volledig is verwijderd uit de toepassing. Voor SCIM-toepassingen is uitschakelen een aanvraag om de actieve eigenschap in te stellen op false voor een gebruiker.

Uw toepassing configureren om een gebruiker uit te schakelen

Zorg ervoor dat u het selectievakje voor updates hebt ingeschakeld.

Zorg ervoor dat u de toewijzing voor actief hebt voor uw toepassing. Als u een toepassing uit de app-galerie gebruikt, kan de toewijzing enigszins verschillen. Zorg ervoor dat u de standaardtoewijzing /out-of-the-box gebruikt voor galerietoepassingen.

Uw toepassing configureren voor het verwijderen van een gebruiker

De volgende scenario's activeren een uitschakelen of verwijderen:

• Een gebruiker wordt in Azure AD soft verwijderd (verzonden naar de prullenbak/de eigenschap AccountEnabled ingesteld op false). 30 dagen nadat een gebruiker in Azure AD is verwijderd, worden deze definitief verwijderd uit de tenant. Op dit moment verzendt de inrichtingsservice een DELETE-aanvraag om de gebruiker permanent te verwijderen in de toepassing. U kunt een gebruiker op elk moment gedurende het venster van 30 dagen handmatig permanentverwijderen, waardoor een verwijderaanvraag naar de toepassing wordt verzendt.
• Een gebruiker wordt permanent verwijderd uit de prullenbak in Azure AD.
• Een gebruiker wordt niet toegewezen vanuit een app.
• Een gebruiker gaat van binnen naar buiten het bereik (geeft geen bereikfilter meer door).

Standaard worden met de Azure AD-inrichtingsservice gebruikers die buiten het bereik vallen, uitgeschakeld of verwijderd. Als u dit standaardgedrag wilt overschrijven, kunt u een vlag instellen om verwijderingen buiten het bereik over te slaan.

Als een van de bovenstaande vier gebeurtenissen optreedt en de doeltoepassing geen ondersteuning biedt voor soft deletes, verzendt de inrichtingsservice een DELETE-aanvraag om de gebruiker permanent uit de app te verwijderen.

Als u een kenmerk IsSoftDeleted ziet in uw kenmerktoewijzingen, wordt dit gebruikt om de status van de gebruiker te bepalen en of een updateaanvraag met active = false moet worden verzenden om de gebruiker te verwijderen.

Bekende beperkingen

• Als een gebruiker die eerder werd beheerd door de inrichtingsservice, niet is toegewezen vanuit een app of vanuit een groep die is toegewezen aan een app, wordt een aanvraag voor uitschakelen verzenden. Op dat moment wordt de gebruiker niet beheerd door de service en verzenden we geen verwijderaanvraag wanneer deze uit de directory wordt verwijderd.
• Het inrichten van een gebruiker die is uitgeschakeld in Azure AD wordt niet ondersteund. Ze moeten actief zijn in Azure AD voordat ze worden ingericht.
• Wanneer een gebruiker van soft-deleted naar active gaat, activeert de Azure AD-inrichtingsservice de gebruiker in de doel-app, maar worden de groepslidmaatschapen niet automatisch hersteld. De doeltoepassing moet de groepslidmaatschap voor de gebruiker inactief houden. Als de doeltoepassing dit niet ondersteunt, kunt u de inrichting opnieuw starten om de groepslidmaatschap bij te werken.

Aanbeveling

Bij het ontwikkelen van een toepassing moet u altijd zowel zachte als harde verwijderingen ondersteunen. Hiermee kunnen klanten herstellen wanneer een gebruiker per ongeluk is uitgeschakeld.

Volgende stappen

Implementatie van een automatische gebruikersinrichting plannen

Inrichting configureren voor een galerie-app

Een SCIM-eindpunt bouwen en inrichting configureren bij het maken van uw eigen app

Problemen oplossen met het configureren en inrichten van gebruikers voor een toepassing.