Uitnodigingsinwisseling voor Azure Active Directory B2B-samenwerking
In dit artikel worden de manieren beschreven waarop gastgebruikers toegang hebben tot uw resources en het toestemmingsproces dat ze tegenkomen. Als u een uitnodigingse-mail naar de gast verzendt, bevat de uitnodiging een koppeling die de gast kan inwisselen om toegang te krijgen tot uw app of portal. De uitnodigingse-mail is slechts een van de manieren waarop gasten toegang kunnen krijgen tot uw resources. Als alternatief kunt u gasten toevoegen aan uw directory en hen een directe koppeling geven naar de portal of app die u wilt delen. Ongeacht de methode die ze gebruiken, worden gasten door een eerste toestemmingsproces geleid. Dit proces zorgt ervoor dat uw gasten akkoord gaan met de privacyvoorwaarden en alle gebruiksvoorwaarden accepteren die u hebt ingesteld.
Wanneer u een gastgebruiker aan uw directory toevoegt, heeft het gastgebruikersaccount een toestemmingsstatus (te bekijken in PowerShell) die in eerste instantie is ingesteld op PendingAcceptance. Deze instelling blijft bestaan totdat de gast uw uitnodiging accepteert en akkoord gaat met uw privacybeleid en gebruiksvoorwaarden. Daarna wordt de toestemmingsstatus gewijzigd in Geaccepteerd en worden de toestemmingspagina's niet meer aan de gast gepresenteerd.
Belangrijk
- Als Azure AD B2B-klanten vanaf 12 juli 2021 nieuwe Google-integraties instellen voor gebruik met selfservice-aanmelding voor hun aangepaste of Line-Of-Business-toepassingen, werkt verificatie met Google-identiteiten pas als verificaties worden verplaatst naar systeemwebweergaven. Meer informatie.
- Vanaf 30 september 2021 biedt Google geen ondersteuning meer voor ingesloten webweergave-aanmeldingen. Als uw apps gebruikers verifiëren met een ingesloten webweergave en u Google-federatie met Azure AD B2C of Azure AD B2B gebruikt voor externe gebruikersuitnodigingen of selfservice-aanmelding,kunnen Google Gmail-gebruikers zich niet verifiëren. Meer informatie.
- Vanaf 1 november 2021 wordt een wijziging uitgerold om de e-mailfunctie voor een een time-time wachtwoordcode in te zetten voor alle bestaande tenants en deze standaard in te stellen voor nieuwe tenants. Als onderdeel van deze wijziging stopt Microsoft met het maken van nieuwe, niet-beherende ('virale') Azure AD-accounts en -tenants tijdens het inwisselen van de uitnodiging voor B2B-samenwerking. Om onderbrekingen tijdens de feestdagen en implementatievergrendelingen te minimaliseren, zien de meeste tenants wijzigingen die in januari 2022 worden geïmplementeerd. We schakelen de e-mailfunctie voor een een time-time wachtwoordcode in omdat deze een naadloze terugvalmethode biedt voor uw gastgebruikers. Als u deze functie echter niet automatisch wilt in- of uitschakelen, kunt u deze uitschakelen.
Inwisselen en aanmelden via een gemeenschappelijk eindpunt
Gastgebruikers kunnen zich nu via een gemeenschappelijk eindpunt (URL) aanmelden bij uw apps voor meerdere tenants of microsoft- eigen apps, bijvoorbeeld https://myapps.microsoft.com . Voorheen werd met een algemene URL een gastgebruiker omgeleid naar de eigen tenant in plaats van uw resource-tenant voor verificatie, dus er was een tenantspecifieke koppeling vereist (bijvoorbeeld https://myapps.microsoft.com/?tenantid=<tenant id> ). De gastgebruiker kan nu naar de algemene URL van de toepassing gaan, aanmeldingsopties kiezen en vervolgens Aanmelden bij een organisatie selecteren. De gebruiker kan vervolgens de naam van uw organisatie typen.

De gebruiker wordt vervolgens omgeleid naar het eindpunt van uw tenant, waar hij zich kan aanmelden met zijn e-mailadres of een door u geconfigureerde id-provider kan selecteren.
Inwisselen via een directe koppeling
Als alternatief voor de uitnodigings-e-mail of de algemene URL van een toepassing kunt u een gast een directe koppeling naar uw app of portal geven. U moet eerst de gastgebruiker toevoegen aan uw directory via de Azure Portal of PowerShell. Vervolgens kunt u een van de aanpasbare manieren gebruiken om toepassingente implementeren voor gebruikers, inclusief directe aanmeldingskoppelingen. Wanneer een gast een directe koppeling gebruikt in plaats van de uitnodigings-e-mail, wordt hij of zij nog steeds begeleid bij de eerste keer toestemming.
Notitie
Een directe koppeling is tenantsyte specifiek. Met andere woorden, het bevat een tenant-id of geverifieerd domein, zodat de gast kan worden geverifieerd in uw tenant, waar de gedeelde app zich bevindt. Hier zijn enkele voorbeelden van directe koppelingen met tenantcontext:
- Toegangsvenster voor apps:
https://myapps.microsoft.com/?tenantid=<tenant id> - Toegangsvenster voor apps voor een geverifieerd domein:
https://myapps.microsoft.com/<;verified domain> - Azure Portal:
https://portal.azure.com/<tenant id> - Afzonderlijke app: zie een koppeling voor directe aanmelding gebruiken
Er zijn enkele gevallen waarin de uitnodigings-e-mail wordt aanbevolen via een directe koppeling. Als deze speciale gevallen belangrijk zijn voor uw organisatie, raden we u aan om gebruikers uit te nodigen met behulp van methoden die nog steeds de uitnodigingsmail verzenden:
- De gebruiker heeft geen Azure AD-account, een MSA of een e-mailaccount in een federatief organisatie. Tenzij u de functie voor een een time-wachtwoordcode gebruikt, moet de gast de uitnodigings-e-mail inwisselen om de stappen voor het maken van een MSA te doorlopen.
- Soms heeft het uitgenodigde gebruikersobject geen e-mailadres vanwege een conflict met een contactobject (bijvoorbeeld een Outlook-object). In dit geval moet de gebruiker op de inwissel-URL in de uitnodigings-e-mail klikken.
- De gebruiker kan zich aanmelden met een alias van het e-mailadres dat is uitgenodigd. (Een alias is een extra e-mailadres dat is gekoppeld aan een e-mailaccount.) In dit geval moet de gebruiker op de inwissel-URL in de uitnodigings-e-mail klikken.
Inwisselen via de uitnodigingse-mail
Wanneer u een gastgebruiker aan uw directory toevoegt met behulp van de Azure Portal,wordt er een uitnodigingse-mail verzonden naar de gast in het proces. U kunt er ook voor kiezen om uitnodigingsmails te verzenden wanneer u PowerShell gebruikt om gastgebruikers toe te voegen aan uw directory. Hier is een beschrijving van de ervaring van de gast bij het inwisselen van de koppeling in de e-mail.
- De gast ontvangt een uitnodigingsmail die wordt verzonden vanuit Microsoft Invitations.
- De gast selecteert Uitnodiging accepteren in het e-mailbericht.
- De gast gebruikt zijn eigen referenties om zich aan te melden bij uw directory. Als de gast geen account heeft dat kan worden ge federeerd naar uw directory en de functie voor een een time-wachtwoordcode (OTP) voor e-mail niet is ingeschakeld; de gast wordt gevraagd een persoonlijke MSA of een Azure AD-selfserviceaccount te maken. Raadpleeg de stroom voor het inwisselen van uitnodigingen voor meer informatie.
- De gast wordt begeleid door de toestemmingservaring die hieronder wordt beschreven.
Beperking voor inwisselen met conflicterend contactobject
Soms kan het e-mailadres van de uitgenodigde externe gastgebruiker conflicteren met een bestaand contactobject,waardoor de gastgebruiker wordt gemaakt zonder proxyAddress. Dit is een bekende beperking waardoor gastgebruikers het volgende niet kunnen doen:
- Een uitnodiging inwisselen via een directe koppeling met behulp van SAML/WS-Fed IdP, Microsoft-accounts, Google Federationof e-mail One-Time wachtwoordcodeaccounts.
- Een uitnodiging inwisselen via een inwisselkoppeling voor uitnodigingsmail met behulp van SAML/WS-Fed IdP en e-mail One-Time wachtwoordcodeaccounts.
- Aanmelden bij een toepassing na inwisseling met behulp van SAML/WS-Fed IdP en Google Federation-accounts.
Als u gebruikers wilt deblokkeren die een uitnodiging niet kunnen inwisselen vanwege een conflicterend contactobject,volgt u deze stappen:
- Verwijder het conflicterende contactobject.
- Verwijder de gastgebruiker in de Azure Portal (de eigenschap Uitnodiging geaccepteerd van de gebruiker moet de status In behandeling hebben).
- Nodig de gastgebruiker opnieuw uit.
- Wacht tot de gebruiker de uitnodiging heeft ingewisseld.
- Voeg het e-mailadres Contact van de gebruiker weer toe aan Exchange en eventuele DL's waar ze deel van moeten uitmaken.
Stroom voor uitnodiging inwisselen
Wanneer een gebruiker op de koppeling Uitnodiging accepteren in een uitnodigingse-mail klikt, wordt de uitnodiging automatisch ingewisseld door Azure AD op basis van de inwisselstroom, zoals hieronder wordt weergegeven:

*Als de USER Principal Name (UPN) van de gebruiker overeenkomt met zowel een bestaand Azure AD- als een persoonlijk MSA-account, wordt de gebruiker gevraagd om te kiezen met welk account hij of zij wil inwisselen.
Azure AD voert detectie op basis van gebruikers uit om te bepalen of de gebruiker in een bestaande Azure AD-tenant bestaat.
Als een beheerder federatie van SAML/WS-Fed-IdPheeft ingeschakeld, controleert Azure AD of het domeinachtervoegsel van de gebruiker overeenkomt met het domein van een geconfigureerde SAML/WS-Fed-id-provider en wordt de gebruiker omgeleid naar de vooraf geconfigureerde id-provider.
Als een beheerder Federatie van Googleheeft ingeschakeld, controleert Azure AD of het domeinachtervoegsel van de gebruiker gmail.com of googlemail.com en wordt de gebruiker omgeleid naar Google.
Tijdens het inwisselproces wordt gecontroleerd of de gebruiker een bestaande persoonlijke Microsoft-account (MSA) heeft voor JIT-inwisselingen (Just-In-Time), maar niet voor het inwisselen van een uitnodigingsmailkoppeling. Als de gebruiker al een bestaande MSA heeft, melden ze zich aan met hun bestaande MSA.
Zodra de basismap van de gebruiker is geïdentificeerd, wordt de gebruiker naar de bijbehorende id-provider verzonden om zich aan te melden.
Als in stap 1 tot en met 4 geen basisdirectory voor de uitgenodigde gebruiker wordt gevonden, bepaalt Azure AD of de uitnodigende tenant de functie voor een een time-time wachtwoordcode (OTP) voor gasten heeft ingeschakeld voor e-mail.
Als een een time-time wachtwoordcode voor gasten isingeschakeld, wordt via de uitgenodigde e-mail een wachtwoordcode naar de gebruiker verzonden. De gebruiker haalt deze wachtwoordcode op en voert deze in op de aanmeldingspagina van Azure AD.
Als een een time-time wachtwoordcode voor gasten is uitgeschakeld, controleert Azure AD het domeinachtervoegsel om te bepalen of deze bij een consumentenaccount hoort. Als dat het zo is, wordt de gebruiker gevraagd om een persoonlijke Microsoft-account. Zo niet, dan wordt de gebruiker gevraagd een Selfserviceaccountvoor Azure AD te maken.
Azure AD probeert een selfserviceaccount voor Azure AD te maken door de toegang tot de e-mail te controleren. Controleer of het account wordt uitgevoerd door een code naar het e-mailbericht te verzenden en de gebruiker deze op te halen en naar Azure AD te verzenden. Als de tenant van de uitgenodigde gebruiker echter federatief is of als het veld AllowEmailVerifiedUsers is ingesteld op false in de tenant van de uitgenodigde gebruiker, kan de gebruiker de inwisseling niet voltooien en resulteert de stroom in een fout. Zie Troubleshooting Azure Active Directory B2B collaboration (Problemen met B2B-samenwerking oplossen) voor meer informatie.
De gebruiker wordt gevraagd om een persoonlijke Microsoft-account (MSA) te maken.
Na de authenticatie bij de juiste id-provider wordt de gebruiker omgeleid naar Azure AD om de toestemmingservaring te voltooien.
Voor JIT-aflossingen (Just-In-Time), waarbij inwisselen via een tenanttoepassingskoppeling gebeurt, zijn stap 8 tot en met 10 niet beschikbaar. Als een gebruiker stap 6 bereikt en de functie Een een time-time wachtwoordcode e-mailen niet is ingeschakeld, ontvangt de gebruiker een foutbericht en kan de uitnodiging niet inwisselen. Om deze fout te voorkomen, moeten beheerders een een time-time wachtwoordcode voor e-mail inschakelen of ervoor zorgen dat de gebruiker op een uitnodigingskoppeling klikt.
Toestemmingservaring voor de gast
Wanneer een gast zich voor het eerst bij een partnerorganisatie meldt voor toegang tot resources, wordt deze door de volgende pagina's geleid.
De gast bekijkt de pagina Machtigingen controleren waarin de privacyverklaring van de uitnodigende organisatie wordt beschreven. Een gebruiker moet het gebruik van hun gegevens accepteren in overeenstemming met het privacybeleid van de uitnodigende organisatie om door te gaan.

Notitie
Zie How-to: Add your organization's privacy info in Azure Active Directory (Uitleg:privacygegevens van uw organisatie toevoegen in Azure Active Directory) voor meer informatie over hoe u als tenantbeheerder een koppeling kunt maken naar de privacyverklaring van uw organisatie.
Als de gebruiksvoorwaarden zijn geconfigureerd, wordt de gast geopend en controleert hij de gebruiksvoorwaarden en selecteert vervolgens Accepteren.

U kunt de gebruiksvoorwaarden configureren in External Identities > Gebruiksrechtovereenkomst.
Tenzij anders aangegeven, wordt de gast omgeleid naar het toegangsvenster Apps, waarin de toepassingen worden vermeld die de gast kan openen.

Notitie
De toestemmingservaring wordt pas weergegeven nadat de gebruiker zich heeft meldt en niet eerder. Er zijn enkele scenario's waarin de toestemmingservaring niet wordt weergegeven aan de gebruiker, bijvoorbeeld:
- De gebruiker heeft de toestemmingservaring al geaccepteerd
- De beheerder verleent tenantbrede beheerders toestemming voor een toepassing
In uw directory wordt de waarde voor Uitnodiging geaccepteerd van de gast gewijzigd in Ja. Als er een MSA is gemaakt, geeft de bron van de gast het Microsoft-account weer. Zie Eigenschappen van een Azure AD B2B-samenwerkingsgebruiker voor meer informatie over eigenschappen van gastgebruikersaccounts. Als er een foutbericht wordt weergegeven dat toestemming van de beheerder vereist tijdens het openen van een toepassing, bekijkt u Hoe u beheerderstoegang verleent aan apps.
Volgende stappen
- Wat is Azure AD B2B-samenwerking?
- Gebruikers Azure Active Directory B2B-samenwerking toevoegen aan de Azure Portal
- Hoe voegen informatiemedewerkers gebruikers van B2B-samenwerking toe aan Azure Active Directory?
- Gebruikers Azure Active Directory B2B-samenwerking toevoegen met behulp van PowerShell
- Een organisatie verlaten als gastgebruiker