Azure Active Directory B2B コラボレーションの招待の利用

この記事では、ゲスト ユーザーがリソースにアクセスできる方法と実行する同意プロセスについて説明します。 招待メールをゲストに送信する場合、その招待には、ゲストがアプリまたはポータルにアクセスするために利用できるリンクを含めます。 招待メールは、ゲストがリソースにアクセスできる方法の 1 つにすぎません。 別の方法として、ゲストをディレクトリに追加し、共有したいポータルまたはアプリへの直接リンクを提供することができます。 使用する方法に関係なく、ゲストには初回の同意プロセスが示されます。 このプロセスにより、ゲストは確実にプライバシー条項に同意し、設定された利用規約を承諾することになります。

ゲスト ユーザーをディレクトリに追加すると、そのゲスト ユーザーのアカウントは同意状態 (PowerShell で表示可能) になります。これは、最初は PendingAcceptance に設定されます。 ゲストが招待を受け入れ、プライバシー ポリシーと利用規約に同意するまで、この設定は維持されます。 その後、同意の状態が 承認済み に変わり、同意ページはゲストに表示されなくなります。

重要

共通のエンドポイントを使用した引き換えとサインイン

ゲスト ユーザーは、https://myapps.microsoft.com のような共通のエンドポイント (URL) を介して、マルチテナント アプリまたは Microsoft のファーストパーティ アプリにサインインできるようになりました。 これまで、ゲスト ユーザーは認証のために共通 URL によって、リソース テナントではなくホーム テナントにリダイレクトされていたため、テナント固有のリンク (例: https://myapps.microsoft.com/?tenantid=<tenant id>) が必要でした。 現在、ゲスト ユーザーはアプリケーションの共通 URL にアクセスして、 [サインイン オプション] を選択し、 [Sign in to an organization](組織にサインイン) を選択できます。 次に、ユーザーは組織の名前を入力します。

共通のエンドポイントへのサインイン

その後、ユーザーはテナント エンドポイントにリダイレクトされます。このエンドポイントでは、メール アドレスを使用してサインインするか、構成済みの ID プロバイダーを選択することができます。

招待メールまたはアプリケーションの共通 URL の代わりに、アプリまたはポータルへの直接リンクをゲストに提供することができます。 まず、Azure portal または PowerShell を介して、ゲスト ユーザーをディレクトリに追加する必要があります。 その後、直接サインオン リンクを含む、ユーザーにアプリケーションをデプロイするためのカスタマイズ可能な方法のいずれかを使用できます。 ゲストには、招待メールではなく直接リンクを使用する際にも、初回の同意エクスペリエンスが示されます。

注意

直接リンクはテナント固有です。 つまり、共有アプリが配置されている、テナントでゲストを認証できるように、テナント ID または確認済みドメインが含まれています。 テナント コンテキストを含む直接リンクの例をいくつか以下に示します。

  • アプリ アクセス パネル: https://myapps.microsoft.com/?tenantid=<tenant id>
  • 確認済みドメインのアプリ アクセス パネル: https://myapps.microsoft.com/<;verified domain>
  • Azure portal: https://portal.azure.com/<tenant id>
  • 個々のアプリ: 直接サインオン リンクの使用方法を参照してください

直接リンク経由の招待メールが推奨されるケースがいくつかあります。 このような特殊なケースが組織にとって重要な場合は、引き続き招待メールを送信する方法を使用してユーザーを招待することをお勧めします。

  • ユーザーが Azure AD、MSA、あるいはフェデレーション組織のメール アカウントを持っていません。 ワンタイム パスコード機能を使用していない場合は、ゲストは、MSA の作成手順が示される招待メールを利用する必要があります。
  • 連絡先オブジェクト (Outlook の連絡先オブジェクトなど) と競合するため、招待されたユーザー オブジェクトにメール アドレスを持っていないことがあります。 この場合、ユーザーは招待メールの利用 URL をクリックする必要があります。
  • ユーザーは、招待されたメール アドレスの別名でサインインすることができます (エイリアスは、メール アカウントに関連付けられた追加のメール アドレスです)。この場合、ユーザーは招待メールの利用 URL をクリックする必要があります。

招待メールによる利用

Azure portal を使用してディレクトリにゲスト ユーザーを追加すると、そのプロセスで招待メールがゲストに送信されます。 ゲスト ユーザーをディレクトリに追加するために PowerShell を使用する際に、招待メールを送信するように選択することもできます。 以下は、メールのリンクを利用する場合のゲストのエクスペリエンスの説明です。

  1. ゲストは、Microsoft Invitations から送信される 招待メールを受け取ります。
  2. ゲストは、電子メールで [招待の承諾] を選択します。
  3. ゲストは、自分の資格情報を使用してディレクトリにサインインします。 ゲストがディレクトリにフェデレーションできるアカウントを持っておらず、電子メール ワンタイム パスコード (OTP) 機能が有効になっていない場合、ゲストは個人用 MSA または Azure AD セルフサービス アカウントを作成するように求められます。 詳細については、「招待の引き換えフロー」を参照してください。
  4. ゲストには、以下に説明されている同意エクスペリエンスが示されます。

連絡先オブジェクトの競合による引き換えの制限

招待された外部ゲスト ユーザーのメール アドレスルが既存の連絡先オブジェクトと競合しているために、ゲスト ユーザーが proxyAddress なしで作成される場合があります。 これは既知の制限であり、ゲスト ユーザーは次のことを行えなくなります。

連絡先オブジェクトの競合が原因で招待を引き換えることができないユーザーのブロックを解除するには、これらの手順に従います。

  1. 競合する連絡先オブジェクトを削除します。
  2. Azure portal でゲスト ユーザーを削除します (ユーザーの "招待が受け入れられました" プロパティが保留状態である必要があります)。
  3. ゲスト ユーザーを再度招待します。
  4. ユーザーが招待を引き換えるまで待ちます。
  5. ユーザーの連絡先の電子メールを、Exchange と、それらが含まれている必要がある DL に再度追加します。

招待の引き換えフロー

ユーザーが 招待メール[招待の承諾] リンクをクリックすると、Azure AD では下の画像のように、引き換えフローに基づいて招待が自動的に引き換えられます。

引き換えフローを図解したスクリーンショット

"*ユーザーのユーザー プリンシパル名 (UPN) が既存の Azure AD と個人用 MSA アカウントの両方と一致する場合、ユーザーは引き換えるアカウントを選択するように求められます。 "

  1. Azure AD ではユーザー基準の検出が実行され、既存の Azure AD テナントにユーザーが存在するかどうかが判断されます。

  2. 管理者が SAML/WS-Fed IdP フェデレーションを有効にしている場合、Azure AD では、ユーザーのドメインのサフィックスと構成されている SAML/WS-Fed ID プロバイダーのドメインが一致するかどうかを確認し、あらかじめ構成されている ID プロバイダーにユーザーをリダイレクトします。

  3. 管理者が Google フェデレーションを有効にしている場合、Azure AD では、ユーザーのドメイン サフィックスが gmail.com か googlemail.com であるかどうかが確認され、ユーザーが Google にリダイレクトされます。

  4. 引き換えプロセスでは、Just-In-Time (JIT) 引き換えの場合、ユーザーに既存の個人用 Microsoft アカウント (MSA) があるかどうかが確認されます (ただし、招待メール リンクの引き換えの場合は除外)。 ユーザーに既存の MSA がある場合は、既存の MSA でサインインします。

  5. ユーザーの ホーム ディレクトリ が確認されると、ユーザーはサインインするため、それに対応する ID プロバイダーの元に送られます。

  6. 手順 1 から 4 によって招待したユーザーのホーム ディレクトリを見つけられない場合、Azure AD によって、招待元のテナントがゲスト用の電子メール ワンタイム パスコード (OTP) を有効にしているかどうかが判断されます。

  7. ゲスト用の電子メール ワンタイム パスコードが有効になっている場合、招待メール経由でパスコードがユーザーに送信されます。 ユーザーはこのパスコードを取得し、Azure AD サインイン ページで入力します。

  8. ゲスト用の電子メール ワンタイム パスコードが無効になっている場合、Azure AD によって、ドメイン サフィックスがチェックされ、コンシューマー アカウントに属しているかどうかが判断されます。 該当する場合、ユーザーは、個人用 Microsoft アカウントを作成するように求められます。 該当しない場合、Azure AD セルフサービス アカウントを作成するように求められます。

  9. Azure AD では、メールへのアクセスを確認することで、Azure AD セルフサービス アカウントの作成が試行されます。 アカウントの確認は、コードをメールに送信し、ユーザーにそのコードを取得させ、Azure AD に送信させることで行われます。 ただし、招待されたユーザーのテナントがフェデレーションされているか、または招待されたユーザーのテナントで AllowEmailVerifiedUsers フィールドが false に設定されている場合、ユーザーは引き換えを完了できず、フローは結果的にエラーになります。 詳細については、「Azure Active Directory B2B コラボレーションのトラブルシューティング」を参照してください。

  10. ユーザーは、個人用 Microsoft アカウント (MSA) を作成するように求められます。

  11. 該当する ID プロバイダーに対して認証を行った後、同意エクスペリエンスを完了するため、ユーザーは Azure AD にリダイレクトされます。

テナント化されたアプリケーションのリンク経由で引き換える Just-In-Time (JIT) 引き換えについては、手順 8 から 10 までを利用できません。 ユーザーが手順 6 に到達したとき、電子メール ワンタイム パスコード機能が有効になっていない場合、ユーザーはエラー メッセージを取得し、招待を引き換えることができません。 このエラーを防ぐには、管理者が電子メール ワンタイム パスコードを有効にするか、ユーザーが招待リンクを確実にクリックするようにします。

ゲストがサインインし、初めてパートナー組織のリソースにアクセスすると、以下のページが示されます。

  1. ゲストは、招待元の組織のプライバシーに関する声明について説明されている [アクセス許可の確認] ページを確認します。 ユーザーは、操作を続行するために、招待元の組織のプライバシー ポリシーに従って情報を使用することに 同意する 必要があります。

    [アクセス許可の確認] ページのスクリーンショット

    注意

    テナント管理者として組織のプライバシー ステートメントにリンクする方法については、Azure Active Directory に組織のプライバシー情報を追加する方法に関するページを参照してください。

  2. 利用規約が構成されている場合、ゲストはその利用規約を開き、確認してから、 [同意] を選択します。

    新しい利用規約を示すスクリーンショット

    [外部 ID] > [使用条件]使用条件を構成できます。

  3. 特に指定されていない限り、ゲストはアプリ アクセス パネルにリダイレクトされます。そこには、ゲストがアクセスできるアプリケーションがリスト表示されています。

    アプリ アクセス パネルを示すスクリーンショット

注意

同意エクスペリエンスは、ユーザーがサインインした後にのみ表示され、前には表示されません。 同意エクスペリエンスがユーザーに表示されないシナリオがあります。次に例を示します。

ディレクトリでは、ゲストの [招待が受け入れられました] の値が [はい] に変わります。 MSA が作成された場合、ゲストの [ソース] には Microsoft アカウント が示されます。 ゲスト ユーザー アカウントのプロパティの詳細については、Azure AD B2B コラボレーション ユーザーのプロパティに関するページを参照してください。 アプリケーションへのアクセス中に管理者の同意を要求するエラーが表示される場合は、アプリに管理者の同意を付与する方法に関するページを参照してください。

次のステップ