Uplatnění pozvánky ke spolupráci B2B v Azure Active Directory

Tento článek popisuje způsoby, jak uživatelé typu host mají přístup k vašim prostředkům, a proces souhlasu, se kterým se budou setkávat. Pokud hostu pošlete e-mail s pozvánkou, obsahuje pozvánka odkaz, který může host uplatnit, aby získal přístup k vaší aplikaci nebo portálu. E-mail s pozvánkou je jen jedním ze způsobů, jak hosté můžou získat přístup k vašim prostředkům. Jako alternativu můžete přidat hosty do adresáře a dát jim přímý odkaz na portál nebo aplikaci, kterou chcete sdílet. Bez ohledu na způsob, který používají, se hosté řídí procesem prvního souhlasu. Tento proces zajistí, že vaši hosté souhlasí s podmínkami ochrany osobních údajů a přijmou všechny podmínky použití , které jste nastavili.

Když do adresáře přidáte uživatele typu host, uživatelský účet typu host má stav souhlasu (zobrazitelný v PowerShellu), který je původně nastavený na PendingAcceptance. Toto nastavení zůstane, dokud host pozvánku přijme a souhlasí s vašimi zásadami ochrany osobních údajů a podmínkami použití. Potom se stav souhlasu změní na Akceptovaný a stránky souhlasu se už hostu nezobrazují.

Důležité

  • Od 12. července 2021 platí, že pokud Azure AD zákazníky B2B nastavují nové integrace Google pro samoobslužnou registraci pro vlastní nebo obchodní aplikace, ověřování s identitami Google nebude fungovat, dokud se ověřování nepřesune do systémových webových zobrazení. Přečtěte si další informace.
  • Od 30. září 2021 google zastaralá podporu přihlašování k vloženým webovým zobrazením. Pokud vaše aplikace ověřují uživatele pomocí vloženého webového zobrazení a používáte federaci Google s Azure AD B2C nebo Azure AD B2B pro pozvánky externích uživatelů nebo samoobslužnou registraci, uživatelé Google Gmailu se nebudou moct ověřit. Přečtěte si další informace.
  • Začali jsme zavádět změnu, která zapne funkci jednorázového hesla e-mailu pro všechny stávající tenanty a ve výchozím nastavení ji povolí pro nové tenanty. Funkci jednorázového hesla e-mailu povolujeme, protože poskytuje bezproblémovou metodu náhradního ověřování pro vaše uživatele typu host. Pokud ale nechcete povolit automatické zapnutí této funkce, můžete ji zakázat. Brzy přestaneme vytvářet nové nespravované ("virální") Azure AD účty a tenanty během uplatnění pozvánky na spolupráci B2B.

Uplatnění a přihlášení prostřednictvím společného koncového bodu

Uživatelé typu host se teď můžou přihlásit k víceklientům nebo aplikacím Microsoftu první strany prostřednictvím společného koncového bodu (URL), například https://myapps.microsoft.com. Dříve běžná adresa URL přesměrovala uživatele typu host na svého domácího tenanta místo tenanta prostředku k ověřování, takže byl vyžadován odkaz specifický pro tenanta (například https://myapps.microsoft.com/?tenantid=<tenant id>). Teď může uživatel typu host přejít na společnou adresu URL aplikace, zvolit možnosti přihlášení a pak vybrat Přihlásit se k organizaci. Uživatel pak zadá název vaší organizace.

Běžné přihlášení ke koncovému bodu

Uživatel se pak přesměruje na váš koncový bod tenanta, kde se může buď přihlásit pomocí e-mailové adresy, nebo vybrat zprostředkovatele identity, kterého jste nakonfigurovali.

Jako alternativu k e-mailu s pozvánkou nebo běžné adrese URL aplikace můžete hostovi poskytnout přímý odkaz na vaši aplikaci nebo portál. Nejdřív musíte přidat uživatele typu host do adresáře prostřednictvím Azure Portal nebo PowerShellu. Pak můžete použít kterýkoli z přizpůsobitelných způsobů nasazení aplikací uživatelům, včetně přímých přihlašovacích odkazů. Když host místo e-mailu s pozvánkou použije přímý odkaz, bude se pořád řídit prostředím pro vyjádření souhlasu při prvním použití.

Poznámka

Přímý odkaz je specifický pro tenanta. Jinými slovy, obsahuje ID tenanta nebo ověřenou doménu, aby se host mohl ověřit ve vašem tenantovi, kde se sdílená aplikace nachází. Tady je několik příkladů přímých odkazů s kontextem tenanta:

  • Přístupový panel aplikací: https://myapps.microsoft.com/?tenantid=<tenant id>
  • Přístupový panel aplikací pro ověřenou doménu: https://myapps.microsoft.com/<;verified domain>
  • Azure Portal:https://portal.azure.com/<tenant id>
  • Jednotlivá aplikace: Podívejte se, jak používat přímý odkaz pro přihlašování.

V některých případech se e-mail s pozvánkou doporučuje přes přímý odkaz. Pokud jsou pro vaši organizaci důležité tyto zvláštní případy, doporučujeme pozvat uživatele pomocí metod, které e-mail s pozvánkou stále posílají:

  • Uživatel nemá Azure AD účet, MSA ani e-mailový účet ve federované organizaci. Pokud nepoužíváte funkci jednorázového hesla, musí host uplatnit e-mail s pozvánkou, aby provedl kroky pro vytvoření MSA.
  • Někdy pozvaný objekt uživatele nemusí mít e-mailovou adresu kvůli konfliktu s objektem kontaktu (například objekt kontaktu aplikace Outlook). V takovém případě musí uživatel kliknout na adresu URL uplatnění v e-mailu s pozvánkou.
  • Uživatel se může přihlásit pomocí aliasu e-mailové adresy, která byla pozvána. (Alias je další e-mailová adresa přidružená k e-mailovému účtu.) V takovém případě musí uživatel kliknout na adresu URL uplatnění v e-mailu s pozvánkou.

Uplatnění prostřednictvím e-mailu s pozvánkou

Když do adresáře přidáte uživatele typu host pomocí Azure Portal, odešle se hostovi v procesu e-mail s pozvánkou. Pokud k přidání uživatelů typu host do adresáře používáte PowerShell , můžete také posílat e-maily s pozvánkou. Tady je popis prostředí hosta při uplatnění odkazu v e-mailu.

  1. Host obdrží e-mail s pozvánkou odeslanou z pozvánek Microsoftu.
  2. Host vybere pozvánku v e-mailu.
  3. Host použije své vlastní přihlašovací údaje k přihlášení k vašemu adresáři. Pokud host nemá účet, který je možné federovat do vašeho adresáře a funkce jednorázového hesla (OTP) e-mailu není povolená; Host se zobrazí výzva k vytvoření osobního účtu MSA nebo Azure AD samoobslužného účtu. Podrobnosti najdete v toku uplatnění pozvánky .
  4. Host vás provede prostředím pro vyjádření souhlasu popsaného níže.

Omezení uplatnění s konfliktním objektem kontaktu

Někdy může být pozvaný e-mail externího uživatele typu host v konfliktu s existujícím objektem Kontakt, což vede k vytvoření uživatele typu host bez proxyAddress. Jedná se o známé omezení, které uživatelům typu host brání v uplatnění pozvánky prostřednictvím přímého odkazu pomocí SAML/WS-Fed IdP, účtů Microsoft, Federace Google nebo Email One-Time účtů hesla.

Následující scénáře by ale měly i nadále fungovat:

Pokud chcete odblokovat uživatele, kteří nemůžou uplatnit pozvánku kvůli konfliktní objektu kontaktu, postupujte takto:

  1. Odstraňte konfliktní objekt kontaktu.
  2. Odstraňte uživatele typu host v Azure Portal (vlastnost Pozvánka přijata uživatelem by měla být ve stavu čekání).
  3. Znovu pozvěte uživatele typu host.
  4. Počkejte, až uživatel uplatní pozvánku.
  5. Přidejte e-mail kontaktu uživatele zpět do Exchange a všechny adresy URL, které by měly být součástí.

Tok uplatnění pozvánky

Když uživatel klikne na odkaz Přijmout pozvánku v e-mailu s pozvánkou, Azure AD pozvánku automaticky uplatní na základě toku uplatnění, jak je znázorněno níže:

Snímek obrazovky znázorňující diagram toku uplatnění

*Pokud se hlavní název uživatele (UPN) shoduje s existujícím Azure AD i osobním účtem MSA, zobrazí se uživateli výzva k výběru účtu, u kterého účtu chcete uplatnit. Pokud je povolené Email jednorázové heslo, budou stávající nespravované "virální Azure AD" účty ignorovány (viz krok 9).

  1. Azure AD zjišťování na základě uživatele určí, jestli uživatel existuje v existujícím tenantovi Azure AD.

  2. Pokud správce povolil federaci SAML/WS-Fed IdP, Azure AD zkontroluje, jestli přípona domény uživatele odpovídá doméně nakonfigurovaného zprostředkovatele identity SAML/WS-Fed a přesměruje uživatele na předem nakonfigurovaného zprostředkovatele identity.

  3. Pokud správce povolil federaci Google, Azure AD zkontroluje, jestli je přípona domény uživatele gmail.com nebo googlemail.com a přesměruje uživatele na Google.

  4. Proces uplatnění zkontroluje, jestli má uživatel stávající osobní účet Microsoft (MSA) pro uplatnění za běhu (JIT), ale ne pro uplatnění e-mailového odkazu s pozvánkou. Pokud už má uživatel existující msA, přihlásí se pomocí existujícího msA.

  5. Po identifikaci domovského adresáře uživatele se uživatel odešle příslušnému zprostředkovateli identity, aby se přihlásil.

  6. Pokud se kroky 1 až 4 nepodaří najít domovský adresář pozvaných uživatelů, Azure AD určí, jestli tenant pozvánky povolil funkci jednorázového hesla (OTP) e-mailu pro hosty.

  7. Pokud je povolené jednorázové heslo pro hosty e-mailem, odešle se uživateli heslo prostřednictvím pozvaných e-mailů. Uživatel načte a zadá toto heslo na přihlašovací stránce Azure AD.

  8. Pokud je jednorázové heslo pro hosty zakázané, Azure AD zkontroluje příponu domény a určí, jestli patří do účtu příjemce. Pokud ano, zobrazí se uživateli výzva k vytvoření osobního účtu Microsoft. Pokud ne, zobrazí se uživateli výzva k vytvoření Azure AD samoobslužného účtu.

  9. Azure AD se pokusí vytvořit Azure AD samoobslužný účet ověřením přístupu k e-mailu. Ověření, že se účet provádí odesláním kódu do e-mailu a načtením a odesláním uživatele do Azure AD. Pokud je však tenant pozvaného uživatele federovaný nebo pokud je pole AllowEmailVerifiedUsers nastavené na hodnotu false v tenantovi pozvaného uživatele, uživatel nemůže dokončit uplatnění a tok způsobí chybu. Další informace najdete v tématu Řešení potíží se spolupráci B2B ve službě Azure Active Directory.

  10. Uživateli se zobrazí výzva k vytvoření osobního účtu Microsoft (MSA).

  11. Po ověření správného zprostředkovatele identity se uživatel přesměruje na Azure AD k dokončení prostředí pro vyjádření souhlasu.

Pro uplatnění za běhu (JIT), kde je uplatnění prostřednictvím odkazu na aplikaci tenanta, nejsou kroky 8 až 10 k dispozici. Pokud uživatel dosáhne kroku 6 a funkce jednorázového hesla Email není povolená, zobrazí se uživateli chybová zpráva a pozvánku se nedá uplatnit. Aby se zabránilo této chybě, měli by správci buď povolit jednorázové heslo e-mailu , nebo zajistit, aby uživatel klikl na odkaz na pozvánku.

Když se host poprvé přihlásí k prostředku v partnerské organizaci, zobrazí se mu následující prostředí pro vyjádření souhlasu. Tyto stránky souhlasu se hostovi zobrazí až po přihlášení a nezobrazí se vůbec, pokud je uživatel už přijal.

  1. Host zkontroluje stránku Oprávnění Ke kontrole popisující prohlášení o zásadách ochrany osobních údajů organizace s pozváním. Uživatel musí přijmout používání svých informací v souladu se zásadami ochrany osobních údajů organizace, aby mohli pokračovat.

    Snímek obrazovky se stránkou Zkontrolovat oprávnění

    Poznámka

    Informace o tom, jak můžete jako správce tenanta propojit prohlášení o zásadách ochrany osobních údajů vaší organizace, najdete v tématu Postupy: Přidání informací o zásadách ochrany osobních údajů vaší organizace v Azure Active Directory.

  2. Pokud jsou nakonfigurované podmínky použití, host se otevře a zkontroluje podmínky použití a pak vybere Přijmout.

    Snímek obrazovky zobrazující nové podmínky použití

    Podmínky použití můžete nakonfigurovat vpodmínkách použitíexterních> identit.

  3. Pokud není uvedeno jinak, host se přesměruje na přístupový panel Aplikace, který uvádí aplikace, ke kterým má host přístup.

    Snímek obrazovky s přístupovým panelem Aplikace

V adresáři se hodnota pozvánky hosta změní na Ano. Pokud byl vytvořen účet MSA , zdroj hosta zobrazí účet Microsoft. Další informace o vlastnostech uživatelského účtu typu host naleznete v tématu Vlastnosti uživatele spolupráce B2B Azure AD B2B. Pokud se při přístupu k aplikaci zobrazí chyba, která vyžaduje souhlas správce, podívejte se, jak udělit souhlas správce aplikacím.

Další kroky