Inlösen av inbjudan till Azure Active Directory B2B-samarbete

  • Artikel
  • 8 minuter för att läsa

Den här artikeln beskriver hur gästanvändare kan komma åt dina resurser och medgivandeprocessen som de kommer att stöta på. Om du skickar ett e-postinbjudan till gästen innehåller inbjudan en länk som gästen kan lösa in för att få åtkomst till din app eller portal. E-postinbjudan är bara ett exempel på hur gäster kan få åtkomst till dina resurser. Alternativt kan du lägga till gäster i din katalog och ge dem en direktlänk till portalen eller appen som du vill dela. Oavsett vilken metod de använder guidas gäster genom en process för medgivande för första gången. Den här processen säkerställer att dina gäster accepterar sekretessvillkoren och godkänner användningsvillkoren som du har skapat.

När du lägger till en gästanvändare i din katalog har gästanvändarkontot en medgivandestatus (kan visas i PowerShell) som ursprungligen är inställd på PendingAcceptance. Den här inställningen är kvar tills gästen accepterar din inbjudan och godkänner din sekretesspolicy och användningsvillkor. Därefter ändras medgivandestatusen till Godkänt och medgivandesidorna visas inte längre för gästen.

Viktigt

  • Från och med 12 juli 2021 kommer autentisering med Google-identiteter inte att fungera förrän autentiseringar flyttas till systemets webbvyer om Azure AD B2B-kunder ställer in nya Google-integreringar för användning med självbetjäning för sina anpassade eller verksamhetsbaserade program. Läs mer.
  • Från och med den 30 september 2021 kommer Google att förfasa inbäddat stöd för inloggning med webbvyer. Om dina appar autentiserar användare med en inbäddad webbvy och du använder Google-federation med Azure AD B2C eller Azure AD B2B för externa användarinbjudningar eller självbetjäningsinbjudningar , kommer Google Gmail-användareinte att kunna autentisera. Läs mer.
  • Från och med den 1 november 2021 börjar vi lansera en ändring för att aktivera funktionen för e-postkoder för alla befintliga klienter och aktivera den som standard för nya klienter. Som en del av den här ändringen slutar Microsoft att skapa nya, ohanterade ("virala") Azure AD-konton och klienter under inlösningen av B2B-samarbetsinbjudningar. För att minimera störningar under helgdagar och distributionslås kommer de flesta klienter att se ändringar som distribueras i januari 2022. Vi aktiverar funktionen för e-postlösenord vid ett tillfälle eftersom den ger dina gästanvändare en sömlös återställningsmetod för autentisering. Men om du inte vill tillåta att den här funktionen aktiveras automatiskt kan du inaktivera den.

Inlösning och inloggning via en gemensam slutpunkt

Gästanvändare kan nu logga in på dina appar för flera klienter eller Microsofts förstapart via en gemensam slutpunkt (URL), till exempel https://myapps.microsoft.com . Tidigare skulle en gemensam URL omdirigera en gästanvändare till sin hemklientorganisation i stället för din resursklientorganisation för autentisering, så en klientspecifik länk krävdes (till exempel https://myapps.microsoft.com/?tenantid=<tenant id> ). Nu kan gästanvändaren gå till programmets gemensamma URL, välja Inloggningsalternativ och sedan välja Logga in på en organisation. Användaren skriver sedan namnet på din organisation.

Vanlig slutpunkts inloggning

Användaren omdirigeras sedan till din klientorganisationsslutpunkt, där de antingen kan logga in med sin e-postadress eller välja en identitetsprovider som du har konfigurerat.

Som ett alternativ till e-postinbjudan eller ett programs gemensamma URL kan du ge en gäst en direktlänk till din app eller portal. Du måste först lägga till gästanvändaren i din katalog via Azure Portal eller PowerShell. Sedan kan du använda något av de anpassningsbara sätten att distribuera program till användare,inklusive länkar för direkt inloggning. När en gäst använder en direktlänk i stället för e-postinbjudan vägleds de fortfarande genom den första medgivandeupplevelsen.

Anteckning

En direktlänk är klientspecifik. Med andra ord innehåller den ett klientorganisations-ID eller en verifierad domän så att gästen kan autentiseras i din klientorganisation, där den delade appen finns. Här följer några exempel på direktlänkar med klientorganisationskontext:

  • Åtkomstpanel för appar: https://myapps.microsoft.com/?tenantid=<tenant id>
  • Åtkomstpanel för appar för en verifierad domän: https://myapps.microsoft.com/<;verified domain>
  • Azure-portalen: https://portal.azure.com/<tenant id>
  • Enskild app: Se hur du använder en länk för direkt inloggning

Det finns vissa fall där e-postinbjudan rekommenderas via en direktlänk. Om dessa särskilda fall är viktiga för din organisation rekommenderar vi att du bjuder in användare med hjälp av metoder som fortfarande skickar e-postinbjudan:

  • Användaren har inget Azure AD-konto, msa-konto eller e-postkonto i en federerad organisation. Om du inte använder funktionen för lösenord vid ett tillfälle måste gästen lösa in e-postinbjudan så att den vägleds genom stegen för att skapa ett MSA.
  • Ibland kanske det inbjudna användarobjektet inte har någon e-postadress på grund av en konflikt med ett kontaktobjekt (till exempel Outlook ett kontaktobjekt). I det här fallet måste användaren klicka på inlösnings-URL:en i e-postinbjudan.
  • Användaren kan logga in med ett alias för den e-postadress som bjudits in. (Ett alias är en ytterligare e-postadress som är associerad med ett e-postkonto.) I det här fallet måste användaren klicka på inlösnings-URL:en i e-postinbjudan.

Inlösen via e-postinbjudan

När du lägger till en gästanvändare i din katalog med hjälp av Azure Portalskickas ett e-postmeddelande med inbjudan till gästen i processen. Du kan också välja att skicka e-postinbjudan när du använder PowerShell för att lägga till gästanvändare i din katalog. Här är en beskrivning av gästens upplevelse när de löser in länken i e-postmeddelandet.

  1. Gästen får ett e-postmeddelande med inbjudan som skickas från Microsoft Invitations.
  2. Gästen väljer Acceptera inbjudan i e-postmeddelandet.
  3. Gästen använder sina egna autentiseringsuppgifter för att logga in på din katalog. Om gästen inte har ett konto som kan federeras till din katalog och funktionen för engångslösenord för e-post inte är aktiverad. gästen uppmanas att skapa ett personligt MSA-konto eller ett självbetjäningskonto för Azure AD. Mer information finns i inlösningsflödet för inbjudan.
  4. Gästen vägleds genom medgivandeupplevelsen som beskrivs nedan.

Inlösningsbegränsning med kontaktobjekt i konflikt

Ibland kan den inbjudna externa gästanvändarens e-post stå i konflikt med ett befintligt kontaktobjekt, vilket resulterar i att gästanvändaren skapas utan proxyAddress. Det här är en känd begränsning som förhindrar gästanvändare från att:

Följ dessa steg om du vill avblockera användare som inte kan lösa in en inbjudan på grund av ett kontaktobjekti konflikt:

  1. Ta bort det kontaktobjekt som står i konflikt.
  2. Ta bort gästanvändaren i Azure Portal (användarens egenskap "Inbjudan godkändes" ska vara i ett väntande tillstånd).
  3. Bjud in gästanvändaren på nya sätt.
  4. Vänta tills användaren har löst in inbjudan.
  5. Lägg till användarens kontakt-e-post i Exchange och eventuella DLs som de ska ingå i.

Inlösningsflöde för inbjudan

När en användare klickar på länken Acceptera inbjudan i ett e-postmeddelande med inbjudan löserAzure AD automatiskt in inbjudan baserat på inlösningsflödet enligt nedan:

Skärmbild som visar flödesdiagrammet för inlösning

*Om användarens UPN (User Principal Name) matchar både ett befintligt Azure AD- och ett personligt MSA-konto uppmanas användaren att välja vilket konto som de vill lösa in med.

  1. Azure AD utför användarbaserad identifiering för att avgöra om användaren finns i en befintlig Azure AD-klientorganisation.

  2. Om en administratör har aktiverat SAML/WS-Fed IdP-federationkontrollerar Azure AD om användarens domänsuffix matchar domänen för en konfigurerad SAML/WS-Fed-identitetsprovider och omdirigerar användaren till den förkonfigurerade identitetsprovidern.

  3. Om en administratör har aktiverat Google-federationkontrollerar Azure AD om användarens domänsuffix är gmail.com eller googlemail.com och omdirigerar användaren till Google.

  4. Inlösningsprocessen kontrollerar om användaren har en befintlig personlig Microsoft-konto (MSA) för JIT-inlösning (Just-In-Time), men inte för inlösning av e-postlänk för inbjudan. Om användaren redan har ett befintligt MSA loggar de in med sitt befintliga MSA.

  5. När användarens arbetskatalog har identifierats skickas användaren till motsvarande identitetsprovider för att logga in.

  6. Om steg 1 till 4 inte kan hitta en hemkatalog för den inbjudna användaren avgör Azure AD om den inbjudande klienten har aktiverat funktionen för engångslösenord (OTP) för gäster.

  7. Om e-postanvändarkod för gäster är aktiveratskickas ett lösenord till användaren via det inbjudna e-postmeddelandet. Användaren hämtar och anger lösenordet på inloggningssidan för Azure AD.

  8. Om e-post-lösenordet för gäster är inaktiverat kontrollerar Azure AD domänsuffixet för att avgöra om det tillhör ett konsumentkonto. I så fall uppmanas användaren att skapa en personlig Microsoft-konto. Annars uppmanas användaren att skapa ett självbetjäningskonto för Azure AD.

  9. Azure AD försöker skapa ett självbetjäningskonto för Azure AD genom att verifiera åtkomsten till e-postmeddelandet. Verifiering av kontot görs genom att skicka en kod till e-postmeddelandet och be användaren att hämta och skicka den till Azure AD. Men om den inbjudna användarens klientorganisation är federerad eller om fältet AllowEmailVerifiedUsers är inställt på falskt i den inbjudna användarens klientorganisation kan användaren inte slutföra inlösningen och flödet resulterar i ett fel. Mer information finns i Felsöka Azure Active Directory B2B-samarbete.

  10. Användaren uppmanas att skapa ett personligt Microsoft-konto (MSA).

  11. Efter autentisering till rätt identitetsprovider omdirigeras användaren till Azure AD för att slutföra medgivandeupplevelsen.

För JIT-inlösning (just-in-time), där inlösningen är via en klientorganisationsprogramlänk, är steg 8 till och med 10 inte tillgängliga. Om en användare når steg 6 och funktionen E-postlösenord inte är aktiverad, får användaren ett felmeddelande och kan inte lösa in inbjudan. För att förhindra det här felet bör administratörer antingen aktivera e-postlösenord en gång eller se till att användaren klickar på en inbjudningslänk.

När en gäst loggar in för att få åtkomst till resurser i en partnerorganisation för första gången vägleds de genom följande sidor.

  1. Gästen granskar sidan Granska behörigheter som beskriver den inbjudande organisationens sekretesspolicy. En användare måste acceptera användningen av sin information i enlighet med den inbjudande organisationens sekretesspolicy för att fortsätta.

    Skärmbild som visar sidan Granska behörigheter

    Anteckning

    Information om hur du som innehavaradministratör kan länka till din organisations sekretesspolicy finns i Så här lägger du till din organisations sekretessinformation i Azure Active Directory.

  2. Om användningsvillkoren har konfigurerats öppnar gästen och granskar användningsvillkoren och väljer sedan Acceptera.

    Skärmbild som visar nya användningsvillkor

    Du kan konfigurera användningsvillkor i External Identities > Användningsvillkor.

  3. Om inget annat anges omdirigeras gästen till åtkomstpanelen Appar, som visar de program som gästen kan komma åt.

    Skärmbild som visar åtkomstpanelen Appar

Anteckning

Medgivandeupplevelsen visas först efter att användaren har loggar in och inte tidigare. Det finns vissa scenarier där medgivandeupplevelsen inte visas för användaren, till exempel:

I din katalog ändras gästens värde för Inbjudan godkänt till Ja. Om ett MSA skapades visar gästkällan Microsoft-kontot. Mer information om egenskaper för gästanvändarkonto finns i Egenskaper för en Azure AD B2B-samarbetsanvändare. Om du ser ett fel som kräver administratörsmedgivande vid åtkomst till ett program kan du se hur du beviljar administratörsmedgivande till appar.

Nästa steg